UT1- DESARROLLO DE SOFTWARE - IES Laguna de Joatzel

UT1- DESARROLLO DE SOFTWARE Entornos de desarrollo Curso 2024-2025 IES laguna de joatzel ¿Qué es el software? Conjunto de programas informáticos Cargados en un ordenador, para que se pueda interactuar con él, mediante dispositivos hardware (periféricos → ¿qué perifér...

UT1- DESARROLLO DE SOFTWARE Entornos de desarrollo Curso 2024-2025 IES laguna de joatzel ¿Qué es el software? Conjunto de programas informáticos Cargados en un ordenador, para que se pueda interactuar con él, mediante dispositivos hardware (periféricos → ¿qué periféricos conocéis?) Distintos tipos de software: SOFTWARE SOFTWARE DE SISTEMA OPERATIVO APLICACIONES PROGRAMACION  TIPOS DE SOFTWARE De Sistemas De Programación De Aplicaciones Objetivo Objetivo Objetivo Liberar al usuario de los detalles Proporcionar herramientas al del hardware que usa y su gestión. Permitir al usuario realizar una o usuario para el desarrollo de Proporciona una interfaz de alto varias tareas específicas programas informáticos nivel, cómoda para el usuario Incluye Incluye Incluye Editores de texto Sistemas Operativos Compiladores Aplicaciones Ofimáticas Controladores de dispositivos Interpretes Software Educativo Utilidades Enlazadores Bases de datos Depuradores Videojuegos Entornos Integrados de Desarrollo Software de diseño asistido (CAD) (IDE)  ¿Qué es en realidad un ordenador y cómo nos ayuda a ejecutar software?  Ordenador = conjunto de hardware  ¿Qué elementos hardware conocéis? ¿Qué es en realidad un ordenador y cómo nos ayuda a ejecutar software?  Un conjunto de dispositivos físicos (hardware) que lo hacen funcionar  Simplificando, los ordenadores siguen una arquitectura hardware basada en la establecida en 1946 por el húngaro John Von Neumann:  Estructura funcional de un ordenador Unidad de control: se Memoria: memoria Unidad Aritmético Registros: unidades Buses: vías de Dispositivos de E/S encarga de recolectar de trabajo de la CPU. Lógica o ALU: mínimas de comunicación que (Entrada/Salida): por las instrucciones a Suele utilizarse RAM encargada de realizar almacenamiento para permiten mover la donde podremos ver ejecutar, (Random Access las operaciones operar directamente información entre los la salida descodificarlas y Memory) y es el matemáticas y de con la ALU en las distintos elementos (típicamente, ejecutar las dispositivo de lógica. operaciones. de la arquitectura. monitores) o instrucciones del almacenamiento de introducir comandos programa las instrucciones y los (típicamente, datos que necesitará teclados). la CPU. Muy próxima a ella, es la más veloz.  ¿Y cómo llega un ordenador a ejecutarse? 1. Generar código ejecutable Código fuente en Código objeto Código IDE o editor lenguaje de (binario NO ejecutable / programación ejecutable) máquina 2. Ejecutar el programa sobre el ordenador Salida Instrucciones RAM Monitor Código ejecutable / máquina Datos Teclado CPU Entrada Lenguajes de programación Sistema de signos que utiliza una comunidad para ¿Qué es un lenguaje? comunicarse oralmente o por escrito. Lenguaje de programación → Conjunto de símbolos y normas que se aplican para obtener un código que el hardware del ordenador pueda entender y llevar a cabo. Es el instrumento que nos permite plasmar lo que queremos que haga el programa. Posee: alfabeto, sintaxis, semántica…  Clasificación de lenguajes de programación  Según su  Según su paradigma  Según si son  Según su tipado proximidad o  Estructurados (C, interpretados,  Fuertemente lejanía al lenguaje Pascal) compilados… tipados (Java) y razonamiento  Orientados a  Compilados (C,  No tipados humano Objetos (Java, C++…) (Javascript, C#, Kotlin, C++…)  Alto nivel (Java)  Interpretados PHP…)  Lógicos (PROLOG) (Javascript, PHP  Bajo nivel (Código máquina,  Funcionales  Híbridos(Java, ensamblador) (Haskell) C#, Python…)  Multiparadigma (Lisp, Python, Javascript…) Lenguajes de alto nivel VS bajo nivel https://medium.com/@brettschules/high-level-and-low-level-languages-62776d0b89f0 Paradigmas de programación https://medium.com/@Loopa/paradigmas-de-programaci%C3%B3n-programaci%C3%B3n-imperativa-y-programaci%C3%B3n-declarativa-4c4a4182fd87 Compilados, interpretados, intermedios… https://ed.team/blog/lenguaje s-de-programacion-compilados- vs-interpretados  Diferencias entre https://www.youtube.com/ watch?v=I1f45REi3k4 compilados, interpretados Fuertemente tipados, débilmente tipados https://ed.team/comunidad /lenguajes-tipados-vs-no- tipados ¿Qué lenguaje de programación usar?  Depende de las características de tu problema, o de la necesidad que tengas.  O de la velocidad con la que quieres que se ejecute (si es algo crítico)  Depende de cuánto lo controles o si quieres probar algo nuevo  Y en el mundo real casi siempre depende de factores ajenos:  Si tu empresa o cliente tiene más productos con ese lenguaje para favorecer el mantenimiento  Si tu cliente te lo impone y punto  Los sistemas que vayan a alojar ese software  Si el lenguaje está ya en vías de extinción o en auge  Si el lenguaje tiene una comunidad fuerte o débil detrás Tipos de lenguajes según la forma de ejecución  Lenguajes compilados:  Compilador: convierte el código fuente en código objeto.  Enlazador: une el código objeto del programa con el código objeto de las librerías necesarias para producir el programa ejecutable. “programa.exe”  Lenguajes interpretados:  Ejecutan las instrucciones secuencialmente y en tiempo real, sin que se genere código objeto.  Programa intérprete.  Lenguajes virtuales:  Multiplataforma  Se pasa de código fuente a bytecode.  El bytecode es ejecutado por la máquina virtual  Más lento Código fuente VS código Objeto VS Código ejecutable  Código fuente: conjunto de instrucciones escritas en un lenguaje de programación determinado. Es el código en el que nosotros escribimos nuestro programa.  Código objeto: el código objeto es el código resultante de compilar el código fuente. Si se trata de un lenguaje de programación compilado, el código objeto será código máquina, mientras que si se trata de un lenguaje con máquina virtual (por ej: Java), será código bytecode.  Código ejecutable: resultado obtenido de enlazar nuestro código objeto con las librerías.  Este código ya es nuestro programa ejecutable, programa que se ejecutará directamente en nuestro sistema o sobre una máquina virtual en el caso de los lenguajes de programación virtuales. Código fuente VS código Objeto VS Código ejecutable  Aunque al proceso de obtener nuestro código ejecutable pase tanto por un compilador como por un enlazador, se suele llamar al proceso completo “compilación” JAVA Virtual Machine  Los programas compilados en Java son multiplataforma gracias a que los programas los ejecuta la Máquina Virtual de Java (JVM, Java Virtual Machine).  La principal desventaja de los lenguajes basados en máquina virtual es que son más lentos que los completamente compilados, debido a la sobrecarga que genera tener una capa de software intermedia.  La ventaja es que son más portables (es decir, se programa y compila 1 vez y se ejecuta en N) ¿Qué pinta tiene un.class? Ciclo de Vida del Software ¿Qué PASOS pensáis que se siguen para crear un programa grande? ¿Cuántas personas o perfiles están involucradas en un desarrollo? ¿Qué problemas puede haber durante el desarrollo? ¿Qué creéis que pasa al entregar ese software al usuario? ¿Qué pasa cuando lo empieza a usar?  Inicial → ¿ES VIABLE? ¿CUÁNTO CUESTA? Análisis → ¿QUÉ ES LO QUE HACE ESTO? Fases del Diseño → ¿CÓMO SE LLEVA A CABO? desarrollo de Codificación → VAMOS A CONSTRUIRLO una Pruebas → ¿FUNCIONA? ¿HACE LO QUE YO QUERÍA? aplicación (Documentación) → VAMOS A HACER ALGO EN PAPEL PARA QUE NO SE OLVIDE QUÉ HACE, CÓMO SE USA O CÓMO SE ESTRUCTURA Explotación/Implantación → VAMOS A PONERLO ONLINE Mantenimiento → VAMOS A CORREGIR BUGS Y MEJORARLO MIENTRAS LA GENTE LO USA Análisis  Proceso por el que extraemos información de qué tiene que hacer el sistema.  Normalmente se analizan y descomponen los requisitos de la aplicación, y volcamos la información en documentos y en diagramas que representan la funcionalidad.  Documento de Requisitos  Casos de uso  Diagramas de flujo  Etc.  Es una fase importantísima ¿Por qué es tan importante un buen análisis?  1º: Es IMPORTANTE saber qué es lo que debe hacer el sistema  De cara a la satisfacción final del cliente / usuario  2º: Es IMPORTANTE que los desarrolladores sepan con exactitud qué es lo que tienen que hacer.  Si no, se quedarán dando vueltas o parados, tendrán muchas dudas  3º: Cualquier cambio en los REQUISITOS durante el desarrollo o después del desarrollo cuesta mucho dinero €€€€€€€ y genera mucha frustración Condiciones que tienen que cumplir los requisitos  Pueden ser implementados de manera práctica (son viables)  Son válidos a nivel de funcionalidad y dominio del software  No son ambiguos  No son incompletos  Se pueden(o podrán) probar/comprobar La importancia de saber bien qué se quiere Tipos de requisitos  Requisitos funcionales: Describen con detalle las funciones que realiza el sistema, qué hace ante determinadas entradas, cómo se comporta en situaciones particulares,…  Requisitos no funcionales: Tratan sobre las características del sistema, como puede ser la fiabilidad, rendimiento, mantenibilidad, sistema operativo, plataforma hardware, restricciones, limitaciones,… Requisitos Funcionales VS Requisitos No Funcionales Requisitos Funcionales Requisitos No Funcionales El usuario puede agregar un nuevo contacto La aplicación debe funcionar en sistemas operativos Linux y Windows El usuario puede ver una lista con todos los El tiempo de respuesta a consultas, altas, bajas y contactos modificaciones ha de ser inferior a 5 segundos A partir de la lista de contactos el usuario puede Utilizar un sistema gestor de base de datos Oracle acceder a un contacto por compatibilidad con el resto de las aplicaciones del cliente El usuario puede eliminar un contacto o varios de Utilizar un lenguaje multiplataforma para el la lista desarrollo de la aplicación El usuario puede modificar los datos de un La interfaz de usuario es a través de ventanas, contacto seleccionado de la lista debe ser intuitiva y fácil de manejar El usuario puede imprimir la lista de contactos Espacio libre en disco, mínimo 1GB. Mínima cantidad de memoria 2GB Cómo dejarlo todo bien escrito  Para representar los requisitos se utilizan diferentes técnicas:  Diagramas de flujo de datos, DFD.  Diagramas de flujo de control, DFC.  Diagramas de transición de estados, DTE.  Diagrama Entidad/Relación, DER.  Diccionario de datos, DD.  Todo lo realizado en esta fase debe quedar reflejado en el Documento de Requisitos del Sistema (DRS). Diseño  Se traducen los requisitos funcionales y no funcionales en una representación de software  Es una especificación más técnica de la solución  Posibilidad de realizar documentos de diseño de la solución:  Documento de Arquitectura técnica  Diagrama de clases  Diagrama de Tablas Relacional (Base de Datos)  Diseño de las Interfaces (con el usuario, con otros sistemas…)  Etc… Diseño Diseño Codificación/Implementación  Proceso de construcción de la funcionalidad del programa utilizando  Lenguajes de programación  Entornos de desarrollo  La documentación elaborada en las fases anteriores  Muchos cafés  Cuanto más elaborado y exhaustivo hayan sido el proceso de análisis y diseño, más fluida y mejor será la fase de codificación  El número de cambios y la magnitud de éstos a implementar será de menor impacto para el desarrollo del proyecto. Codificación/Implementación  En un proyecto de >1 persona, tienen que establecerse ciertas convenciones y normas de codificación:  Forma de nombrar las clases  Forma de nombrar los métodos  Cómo organizar los paquetes de código  Formateo del código  Localización de  Constantes  Métodos de utilidad  Ficheros de configuración  Documentación de entornos y credenciales (wiki) Pruebas  Objetivo: comprobar y asegurar que el software es acorde a la especificación y no tiene errores (o los menos posibles)  Se realizan tareas de:  Validación:  ¿Estamos construyendo el producto correcto?  Comprueba que el software construido se ajusta a los requisitos.  Verificación:  ¿Estamos construyendo el producto correctamente?  Se comprueba que el software implementa correctamente las funciones especificadas.  Se realizan casos de prueba  Con datos de entrada válidos y esperados  Y todo lo contrario: también no válidos e inesperados  NORMA FUNDAMENTAL Un programador debe evitar Pruebas probar sus propios programas ¿Por qué? Pruebas Suelen usarse 2 técnicas (pruebas de caja blanca y pruebas de caja negra)  Caja blanca: validan la estructura interna del programa (necesitan conocer lo que hay dentro)  Caja negra: validan los requisitos sin fijarse en el funcionamiento interno Documentación  Objetivo de la documentación:  Medio de comunicación entre TODO el equipo del proyecto  Repositorio de información para personal de MANTENIMIENTO  Indicar cómo usar y administrar el sistema  Principalmente se crean 2 tipos de documentación.  Documentación técnica/de sistema: describe todo el sistema, desde el análisis hasta la implantación.  Documentación de usuario: información para los usuarios y los administradores del software construido. Explotación/Implantación  Una vez se ha desarrollado y testeado la aplicación, se pone en producción.  Venta y/o distribución.  Se puede distribuir en un formato cloud accesible desde internet.  Ejemplo: aplicaciones web  Soporte físico de almacenamiento: discos ópticos, tarjetas de memoria, etc… Mantenimiento  Fase de corrección (bugs) y evolutivos (nuevas funcionalidades o mejoras)  Ejemplo: actualizaciones de Windows, DLCs de videojuegos, etc…  Se recurre a versionado de la aplicación para indicar las evoluciones/correcciones:  X.Y.Z  El primero (X) se le conoce como versión mayor y nos indica la versión principal del software. Ejemplo: 1.0.0, 3.0.0  El segundo (Y) se le conoce como versión menor y nos indica nuevas funcionalidades. Ejemplo: 1.2.0, 3.3.0  El tercero (Z) se le conoce como revisión y nos indica que se hizo una revisión del código por algún fallo. Ejemplo: 1.2.2, 3.3.4 Roles típicos en un proyecto Análisis  Analista  Arquitecto/Diseñador Software Diseño  Analista Programador Codificación  Programador  QA o Tester Pruebas  Personal de Sistemas o de Explotación  Jefe de Proyecto Implantación Gestión Roles típicos en un proyecto repasar mas adelante  Analista: Responsable de captar los requisitos del sistema, es el intermediario entre el equipo de desarrollo y el cliente.  Arquitecto/Diseñador: Evolución del analista, define las tecnologías que se van a utilizar en el proyecto. Es el encargado de planificar la arquitectura software y hardware en la que se va a implementar la aplicación.  Analista programador: Rol intermedio entre el analista y el programador, en la práctica suele ser un programador con amplia experiencia.  Programador: Se encarga exclusivamente de desarrollar el código fuente de la aplicación siguiendo las indicaciones que el analista, diseñador y arquitecto le proporcionan. Además, puede hacer testing unitario.  QA o Tester: personal específico para las pruebas del proyecto.  Personal de Sistemas o Explotación: persona o personas encargadas de la explotación del producto en los sistemas correspondientes.  Jefe de proyecto: Encargado de firmar el presupuesto del proyecto y planificar la temporalización de este en forma de fechas de entrega y seguimiento. Ciclo de vida del SW  Periodo de vida que transcurre:  Desde que es concebido  Hasta que se retira o deja de estar disponible  Dividido en etapas o fases  Las que hemos visto previamente (análisis, diseño, codificación, pruebas, implantación, mantenimiento)  Los ciclos de vida más utilizados son:  Cascada/Waterfall  Evolutivos  Iterativo Incremental  Espiral Ciclo de vida del SW: Cascada  Fases del ciclo de vida realizadas de manera lineal  Cada fase una única vez  El inicio de una fase no comienza hasta que termina la fase anterior  Si durante el mantenimiento hay que hacer una mejora, se empezará desde arriba del todo bajando cada una de las fases  Ciclo de vida del SW: Iterativo incremental  Iterativo: hay iteraciones de tiempo o ciclos  Incremental: se va añadiendo funcionalidad al producto  Cada ciclo es un mini cascada: Ciclo de vida del SW: Iterativo incremental  Ejemplo: procesador de textos. En cada ciclo se desarrolla una funcionalidad nueva:  1) Gestión de archivos y producción de documentos  2) Funciones gramaticales y corrección  3) Funciones de paginación y formateo  Etc.. Ciclo de vida del SW: Iterativo incremental  Ventajas:  No hace falta conocer todos los requisitos de inicio  Permite la entrega temprana de partes operativas  Inconvenientes:  Difícil estimar esfuerzo y coste final  No recomendable para sistemas con alto índice de riesgos  ¿Cuándo usarla?  Requisitos no completamente definidos y posibilidad de cambios  Se están probando o introduciendo nuevas tecnologías Ciclo de vida del SW: Espiral  Combina el Modelo en Cascada con el modelo iterativo incremental  Tiene más en cuenta el concepto de riesgo que aparece debido a las incertidumbres e ignorancias de los requerimientos Ciclo de vida del SW: Espiral  4 actividades principales en cada ciclo de la espiral:  Determinar objetivos: identificar objetivos y restricciones.  Análisis de riesgo: evaluación de los objetivos y limitaciones. Identificación de riesgos y manera de resolverlos. Riesgos: requisitos no comprendidos, mal diseño, errores en implementación…  Desarrollar y probar: desarrollar la solución al problema y verificar que es aceptable.  Planificación: revisar y evaluar todo lo que se ha hecho, y decidir si se continúa. Si es así, planificar las fases del ciclo siguiente. Ciclo de vida del SW: Espiral  Ventajas:  No requiere definición completa de los requisitos  Se analiza el riesgo en todas las etapas  Se reducen los riesgos  Inconvenientes:  El costo del proyecto aumenta a medida que se aumentan iteraciones  Más idóneo para proyectos grandes. En proyectos pequeños sería muy ineficiente.  Complicado de llevar a cabo  ¿Cuándo usarla?  Proyectos grandes y con constantes cambios.  Proyectos donde sea importante el factor riesgo.  ¿Os suena? Metodologías ¿Conocéis algún método ágiles de trabajo ágil? ¿Qué entendéis por ágil? Metodología ágil: Scrum  Scrum es muy usado hoy en día  Se basa en un ciclo iterativo incremental  Se supone que los proyectos salen mejor  Alinea al cliente con el equipo de Desarrollo  Flexibilidad frente a cambios (ágil)  Productividad y calidad  Feedback constante  Mejora el trabajo en equipo y la colaboración  Se descompone la funcionalidad de historias de usuario  Son tareas de alto nivel que aportan valor al usuario o a la aplicación.  Después se descomponen en tareas de desarrollo  En cada ciclo (sprint) se seleccionan qué historias de usuario se abordarán Metodología ágil: Scrum  Ideas principales  Que el cliente se una al equipo (Product Owner)  Elabora las historias de usuario  Esto hace que esté más implicado y defina mejor  Que cada sprint se saque funcionalidad nueva y se muestre a todos (Demo/Sprint Review) →Los sprint suelen ser 2-4 semanas  Cada día se hace una reunión breve (Daily meeting – 10 min)  Se ven bloqueos  Se comparte qué tarea se van a hacer ese día  Al final de cada sprint se analizan cosas que fueron bien, que necesitan mejorar, bloqueos… (Retrospectiva)