¡Descarga Comparación de Metodologías Tradicionales y Ágil para Desarrollo Web y más Apuntes en PDF de Aplicaciones Informáticas solo en Docsity!
Metodologías Tradicionales de Desarrollo de Software: Proceso de Desarrollo Web Desarrollo de Software Tradicional: Es el proceso de desarrollo de software utilizado para diseñar y desarrollar software simple. Básicamente se utiliza cuando la seguridad y muchos otros factores del software no son muy importantes. Los utilizan los principiantes para desarrollar software simple. Consta de cinco fases globales:
- Análisis de Requisitos
- Diseño
- Implementación
- Codificación y pruebas
- Mantenimiento Fases especificas Recopilación de requisitos y documentación Diseño de sistemas Codificar y pruebas unitarias Pruebas del sistema o Pruebas de aceptación del usuario Corrección de errores Entrega del producto Desarrollo de software ágil: Es el proceso de desarrollo de software utilizado para diseñar software complicado y algo robusto. Se utiliza cuando la seguridad es muy importante. Consta de tres fases globales:
- Inicio del proyecto
- Planificación del Sprint
- Demostraciones La gestión de proyectos tradicional es una metodología establecida en la que los proyectos se ejecutan en un ciclo secuencial. Sigue una secuencia fija: inicio, planificación, ejecución, seguimiento y cierre. El enfoque de gestión de proyectos tradicional pone especial énfasis en los procesos lineales, la documentación, la planificación inicial y la priorización. Según el método tradicional, el tiempo y el presupuesto son variables y los requisitos son fijos, por lo que a menudo se enfrentan a problemas de presupuesto y cronograma. Para cada paso, existen herramientas y técnicas definidas por la metodología estándar PMBOK6O que son seguido por los jefes de proyecto El manifiesto ágil tiene 4 valores muy importantes
- Más enfoque en las personas y las interacciones que en los procesos y las herramientas.
- El software funcional es más importante que la documentación completa.
- La colaboración con el cliente es más vital que la negociación.
- El proceso debe responder al cambio en lugar de seguir ciegamente un plan. Beneficios de la metodología Tradicional
- Objetivos claramente definidos.
- Procesos controlables.
- Documentación clara.
- Más responsabilidad. Beneficios de la gestión ágil de proyectos
- Priorización flexible
- Entrega anticipada y predecible
- Costos y horarios predecibles
- Mejora la calidad
- Más transparencia Tipos de Pruebas Testing tradicional Pruebas de recepción y aceptación funcional. Pruebas de sistema/funcionales. Pruebas de integración de sistemas. Pruebas de rendimiento (stress, carga, rendimiento, capacidad). Pruebas de procesos de negocio (E2E). Pruebas de seguridad. Pruebas de usabilidad. Pruebas de regresión. Testing Agil Pruebas de Unidad — Pruebas Técnicas Pruebas Funcionales — Pruebas de Negocio Pruebas de Exploratorias, Usabilidad y Aceptación - Critica de Producto de Cara a Negocio Pruebas Desempeño, Carga y Seguridad — Pruebas que critican el Producto
PMBOK (Project Management Body of Knowledge) Guía de los
fundamentos para la dirección de proyectos
Procesos de la Dirección de Proyectos por Grupo Iniciación Planifivcación Ejecución Monitoreo y Control Cierre
'Agile' está orientada a la entrega de producto en funcionamiento, con utilidad para los usuarios, y que permita obtener un 'teedback' temprano de los consumidores. ‘Lean’ se centra en lograr un proceso capaz de entregar el mayor valor posible al cliente con la mejor calidad. Metodología Agile Metodología Lean Colaborar con clientes potenciales en la negociación de resultados de proyectos. Responder al cambio con un plan. Interacción entre individuos con sus herramientas y procesos. La producción debe basarse en la demanda y no en la oferta. Se trata simplemente de hacer algo cuando alguien lo quiere y lo ordena, en lugar de hacerlo sus antes de que alguien lo necesite y esperando que esto suceda. La producción mejora y es más eficiente si se realiza en lotes pequeños para explotar economías de escala. Tomarse el tiempo necesario para concentrarse en la calidad también aumenta la producción y la eficiencia. Kanban Taiichi Ohno desarrolló este marco de referencia para Toyota en el seguimiento de las demandas de trabajo, hace referencia a una estrategia visual de gestión de proyectos, donde el trabajo se muestra en una vista tipo tablero con columnas que representan las etapas del trabajo. En un tablero Kanban, las tareas individuales progresan por diferentes etapas hasta que se finalizan. Kanban consiste en visualizar el trabajo, limitar el trabajo en curso y maximizar la eficiencia (o el flujo). Los equipos de Kanban se centran en reducir el tempo que se tarda en llevar un proyecto (o historia de usuario) del principio al fin del proceso. Para ello, utilizan un tablero de Kanban y mejoran continuamente su flujo de trabajo. Kanban ayuda a visualizar el trabajo, a limitar el trabajo en curso y a avanzar rápidamente del trabajo "en progreso" al "terminado". resulta ideal para equipos que tienen muchas solicitudes entrantes con prioridades y tamaños variables. Mientras que los procesos de Scrum requieren un gran control sobre lo que está dentro del alcance, Kanban te permite dejar que todo fluya.
Scrum Inicialmente, Hirotaka Takeuchi e Ikujiro Nonaka utilizaron el término “Scrum” en el desarrollo de productos en su artículo de 1986 de Harvard Business Review, en el articulo presentan el maco Scrum: Las empresas se están dando cada vez mas de que el antiguo enfoque secuencial para el desarrollo de nuevos productos simplemente no sirve. En cambio, las empresas de Japón y Estados Unidos están utilizando un método holístico, como en el rugby, la pelota se pasa dentro del equipo a medida que este se mueve como una unidad por el campo de juego”. Scrum consta de historias de usuarios, tareas, punto y Sprints. Las tareas y las historias de los uysuatios se estiman con puntos y, en base a esa estimación, se dividen en Sprints con un plazo y un objetivo claros. La dirección del Sprint la determina un propietario del producto que representa a la empresa o cliente y un Scrum Master que gestiona el proceso de trabajo, el equipo de Scrum y todos los Stakeholders. El corazón de scrum es el Backlog (lista de tareas), que es muy parecido a una larga lista de tareas pendientes que consta de todas las tareas, características e historias de usuario necesarias para entregar un producto o servicio. Scrum avanza con rapidez, con sprints de entre dos y cuatro semanas como máximo, con fechas claras de inicio y finalización. Este plazo tan breve obliga a dividir las tareas complejas en historias mas pequeñas, y ayuda a tu equipo a aprender con rapidez. Una de las preguntas clave es: ¿puede tu equipo lanzar código utilizable con semejante rapidez? Los sprints se acotan mediante la planificación de los sprints, la revisión de los sprints y las reuniones de retrospectiva, y se aderezan con reuniones diarias de scrum (reuniones rápidas). Estas ceremonias de scrum son ligeras y se llevan a cabo de forma continuada. Arquitectura de Software La arquitectura de software de un sistema describe la organización o estructura del sistema y proporciona una explicación de cómo se comporta. Un sistema representa la colección de componentes que cumplen una función específica o un conjunto de funciones. En otras palabras, proporciona una base solida sobre la que se puede construir el software. Incluyendo varios factores que contribuyen, como la estrategia empresarial, los atributos de calidad, la dinámica humana, el diseño y el entorno de TI.
los contenidos que alberga sean más fáciles de encontrar por los usuarios. ambigüedad intrínseca al lenguaje, porque sino el usuario puede que abandone la página porque no encuentra lo que necesita. Las etiquetas pueden ser textuales o icónicas. Es recomendable que cuando usemos una imagen, vaya acompañada siempre de texto. se pueden identificar las relaciones entre los contenidos y donde se encuentra en ese momento, y permitiendo la navegación entre esos contenidos concreta. Patrones de Diseño Gor (Gang of Four) Design Patterns: Elements of Reusable Object-Oriented Software (1994) es un libro de Ingenieria de Software «que describe los patrones de diseño de software. El libro fue escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. El libro está dividido en dos partes, los dos primeros capítulos exploran las capacidades y las trampas de la Programación Orientada a Objetos, y los capítulos restantes describen 23 patrones clásicos de diseño de software. Pattern Creational -— Patrón Creacional. Los patrones de creación son los que crean objetos, en lugar de tener que instanciar objetos directamente. Esto le da al programa la flexibilidad para decidir que objetos deben crearse por un caso dado. Tenemos: Abstract Factory , agrupa fábricas de objetos que tiene un tema común Builder , construye objetos complejos separando la construcción y la representación. Factory Method , el método de fabrica crea objetos sin especificar la clase exacta a crear Prototype , crea objetos clonando un objeto existente. Singleton , restringe la creación de objetos para una clase a una sola instancia. Pattern Strcutural – Patrón estructural.
Estos se refieren a la composición de clases y objetos. Utilizan la herencia para componer interfaces y definir formas de componer objetos para obtener nuevas funcionalidades. Tenemos: Adapter , permite que las clases con interfaces incompatibles trabajen juntas envolviendo su propia interfaz alrededor de la de una clase ya existente. Bridge , desacopla una atracción de su implementación para que los dos puedan variar de forma independiente. Composite , compone cero o más objetos similares para que puedan manipularse como un solo objeto. Decorator , agrega/anula dinámicamente el comportamiento en un método existente de un objeto. Facade , proporciona una interfaz simplificada para un gran cuerpo de código. Flyweight , redice el costo de crear y manipular una gran cantidad de objetos similares. Proxy , proporciona un marcador de posición para otro objeto para controlar el acceso, reducir el costo y reducir la complejidad. Pattern Behavioral – Patrón de comportamiento La mayoría de estos patrones de diseño se refieren específicamente a la comunicación entre objetos. Tenemos: Chain of responsibility , delega comandos a una cadena de objetos de procesamiento. Command , crea objetos que encapsulan acciones y parámetros. Interpreter , implementa un lenguaje especializado. Herator, accede a los elementos de un objeto secuencialmente sin exponer su representación subyacente. Mediator , permite in acoplamiento flexible entre clases al ser la única clase que tiene un conocimiento detallado de sus métodos. Memento , proporciona la capacidad de restaurar un objeto a su estado anterior(deshacer). Observer , es un patrón de publicación / suscripción, que permite que varios objetos observadores vean un evento. State, permite que un objeto altere su comportamiento cuando cambia su estado interno.
