Documente Academic
Documente Profesional
Documente Cultură
VICERECTORADO ACADEMICO
INGENIERICA EN INFORMATICA
DESARROLLO WEB.
Profesor. Integrantes.
Oscar Rodriguez Franklin Gutiérrez.
Ángel Jaramillo.
METODOLOGIA EN PROTOTIPADO.
Permite que todo el sistema, o algunos de sus partes, se construyan rápidamente
para comprender con facilidad y aclarar ciertos aspectos mostrando partes del sistema, en
los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que
se necesita, así como también la solución que se propone para dicha necesidad. Este
modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir
de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance
del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de
objetivos generales para el software a desarrollarse sin delimitar detalladamente los
requisitos de entrada procesamiento y salida, es decir cuando el responsable no está
seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que
interactúa el hombre y la máquina.
El paradigma de construcción de prototipos tiene tres pasos:
METODOLOGICA INCREMENTAL.
El modelo incremental tiene como objetivo un crecimiento progresivo de la
funcionalidad. Es decir, el producto va evolucionando con cada una de las entregas
previstas hasta que se amolda a lo requerido por el cliente o destinatario.
La principal diferencia del modelo incremental con los modelos tradicionales es que
las tareas están divididas en iteraciones, es decir, pequeños lapsos en los cuales se trabaja
para conseguir objetivos específicos. Con los modelos tradicionales no pasaba esto; era
necesario esperar hasta el final del proceso.
Sin embargo, no se trata de iteraciones independientes. Por el contrario, están vinculadas
de forma que cada una suponga un avance con respecto a la anterior. Otras características
esenciales de este modelo son:
METODOLOGÍA ÁGIL
Las metodologías ágiles tienen como idea priorizar el tiempo de entrega, uno de
sus puntos fuertes la adaptación a cualquier cambio en un proyecto para aumentar sus
posibilidades de éxito.
Una metodología ágil tiene varios principios:
La mano de obra y sus interacciones son más importantes que los procesos y las
herramientas.
El software que funciona es más importante que la documentación exhaustiva.
Colaboración con el cliente en lugar de negociación de contratos.
No hay que seguir un plan cerrado, sino adaptarse al cambio.
Retroalimentación.
Proceso continuo en lugar de por bloques.
Propiedad intelectual compartida.
Entendimiento compartido.
Retroalimentación
Diseño simple: el mejor programa será aquel que cumpla con los requisitos y sea
más simple. Cumpliendo con las necesidades del cliente.
Metáfora: expresa la visión evolutiva del proyecto y define los objetivos del sistema
mediante una historia.
Propiedad colectiva del código: el código tiene propiedad compartida. Nadie es
propietario de nada, ni siquiera de lo que ha desarrollado. Todos los programadores
son "dueños" de todo el código.
Estándar de programación: define las reglas para escribir y documentar código,
además de cómo se comunican las diferentes piezas de código desarrolladas por
diferentes equipos. El objetivo de esto es que parezca que el código ha sido escrito
por una única persona.
Historias de usuarios: Son tarjetas físicas en las cuales se anota una descripción de
una funcionalidad del sistema, en una oración, se le da un número y un título para
ser identificada.
Casos de prueba de aceptación: Son tarjetas que se elaboran para realizar las
pruebas de cada historia de usuario.
Tarea de ingeniería: Son tarjetas que se elaboran para ayudar y simplificar la
programación de una historia de usuario.
METODOLOGIA SCRUM.
Scrum es una metodología ágil que trabaja mediante prácticas colaborativas se
minimizan todo tipo de riesgos en la elaboración de un proyecto. Ésta tiene su origen en
equipos de alta productividad. En Scrum no se entrega proyecto final, sino que se van
haciendo de forma regular entregas parciales, de forma que esto es lo que más beneficia
al receptor del proyecto. Por ello, Scrum está especialmente indicado para entornos
complejos, donde los cambios se producen como mucha frecuencia y sobre la marcha y
donde la rapidez, la flexibilidad, la adaptabilidad y la competencia juegan un papel
fundamental.
El procedimiento en Scrum
Scrum se ejecuta en bloques temporales que son cortos y periódicos, denominados
Sprints, que por lo general de entre 2 hasta 4 semanas, que es el plazo para feedback y
reflexión.
Cada Sprint es una entidad en sí misma, esto es, proporciona un resultado completo,
una variación del producto final que ha de poder ser entregado al cliente con el menor
esfuerzo posible cuando éste lo solicite.
El proceso tiene como punto de partida una lista de objetivos/requisitos que
conforman el plan de proyecto. Es el cliente del proyecto el que prioriza estos objetivos
teniendo en cuenta un balance del valor y el coste de los mismos, es así como se
determinan las iteraciones y consecuentes entregas.
El Sprint
Son reuniones cortas donde se organiza el equipo y se conversa que se realizará ese día
El primer día del Sprint, éste se divide en dos partes:
1. La selección de requisitos (con una duración de 4 horas máximo): el cliente
determina la lista de requisitos, los cuales son aceptados por el equipo para realizar la
iteración.
2. La planificación de la iteración (con una duración de 4 horas máximo): el equipo
elabora la lista de tareas a realizar en la iteración para la consecución de los requisitos a
los que se ha comprometido.
Cada día el equipo realiza un Sprint Meeting (con una duración máxima de 15
minutos): en ella cada miembro del equipo realiza una supervisión del trabajo realizado por
los demás para ver si es necesario realizar alguna adaptación que permita cumplir con el
compromiso adquirido.
El último día del Sprint, se realiza una revisión, que tiene dos partes:
1. Demostración (4 horas máximo): el equipo presenta los requisitos completados de
la iteración, en forma de producto mejorado, realizado con el mínimo esfuerzo.
El cliente realizará un examen objetivo de la iteración, ya desde la primera vez,
determinando un replanteamiento del proyecto.
2. Retrospectiva (4 horas máximo): el equipo determina y presenta cuáles son los
obstáculos que se ha ido encontrando, siempre con el objetivo de mejorar la productividad.
El Scrum Master se encargará de eliminar dichos obstáculos.
METODOLOGIA UWE.
UWE está basado en estándares de la OMG como UML,Model Driven Architecture
de OMG (MDA), Object Constraint Language (OCL) y eXtensible Markup Language (XML),
asegurando su seguimiento mediante guías y especificaciones para el uso de tecnologías
orientadas a objetos.
El principal objetivo del enfoque UWE es proporcionar: un lenguaje de modelado
específico del dominio basado en UML; una metodología dirigida por modelos; herramientas
de soporte para el diseño sistemático; y herramientas de soporte para la generación semi-
automática de Aplicaciones Web.
La notación de UWE se define como una ligera extensión de UML, proporcionando
un perfil UML para el dominio específico de la web.
Modelos de UWE
El método UWE consiste en la construcción de seis modelos de análisis y diseño.
Dicha construcción se realiza dentro del marco de un proceso de diseño iterativo e
incremental. Las actividades de modelado abarcan: el análisis de requerimientos, diseño
conceptual, modelo de usuario, diseño de la navegación, de la presentación y diseño de la
adaptación.
Los principales artefactos que produce el método de diseño de UWE son los siguientes:
• Un Modelo de Requerimientos que captura los requerimientos del sistema.
• Un Modelo Conceptual para el contenido (modelo de contenido).
• Un Modelo de Usuario.
• UN Modelo de Navegación que comprende la estructura de la navegación.
• Un Modelo de Presentación que abarca modelos estáticos y dinámicos (modelo de
estructura de la presentación, modelo del flujo de la presentación, modelo de interface
abstracta de usuario, y modelo de ciclo de vida del objeto).
• Un modelo de adaptacion.
Modelo de Requerimientos
El primer paso para el desarrollo de un sistema web que se especificará con UWE,
es realizar la identificación de los requerimientos y plasmarlos en un modelo de
requerimientos.
Los requerimientos pueden ser documentados en diferentes niveles de detalle, para
este caso, UWE propone dos niveles de granularidad. En primera instancia se deben
describir detalladamente las funcionalidades del sistema, las cuales son modeladas con
casos de uso UML. Como segundo paso, se debe elaborar una descripción de los casos de
uso más detallada, por ejemplo, realizando diagramas de actividad UML donde se delimiten
las responsabilidades y acciones de los actores involucrados.
Los casos de uso fueron propuestos por el Proceso de Desarrollo de Software
Unificado (RUP) para capturar los requerimientos del sistema. Es una técnica centrada en
el usuario que obliga a definir quiénes son los usuarios (actores) de la aplicación y ofrece
una forma intuitiva de representar la funcionalidad que una aplicación tiene que cumplir para
cada actor.
UWE distingue tres tipos de casos de uso: navegación, proceso, y casos de uso
personalizados.
Los casos de uso de navegación, se distinguen con el estereotipo <<navigation>>
(0) y se utilizan para modelar el comportamiento típico del usuario cuando interactúa con
una aplicación web, tal como navegar a través del contenido de la WebApp o buscar
información por medio de palabras claves.
Los casos de uso de proceso, se utilizan para describir las tareas del negocio que
los usuarios finales realizarán con el sistema,
tales como acciones transaccionales sobre la Base de Datos. No se denota con
ningún estereotipo específico, por lo tanto, se utiliza en este caso la notación pura de UML.
Los casos de usos personalizados, implican la personalización de un sistema web,
la cual es desencadenada por el comportamiento del usuario. Estos casos de uso se
denotan con el estereotipo <<personalized>>
Modelo de Contenido (Conceptual) y Modelo de Usuario
El diseño conceptual se basa en el modelo de análisis e incluye los objetos
involucrados en las actividades típicas que los usuarios realizan con la aplicación.
El propósito del modelo de contenido es proporcionar una especificación visual de
la información relevante para el dominio del sistema web, que comprende principalmente el
contenido de la aplicación Web.
Modelo de Navegación:
El modelo de estructura de navegación define la estructura de nodos y links de una
WebApp mostrando cómo se puede realizar la navegación utilizando elementos de acceso
tales como índices, visitas guiadas, consultas y menús.
Los elementos de modelado son:
• Clases de navegación, que se denotan con (0), representan los nodos navegables
de la estructura de hipertexto.
• Links de navegación, que muestran el vínculo directo entre las clases de
navegación.
• Caminos de navegación alternativos, los cuales son visualizados con el estereotipo
<<menu>> ( ).
• Primitivas de acceso, las cuales se utilizan ya sea para llegar a múltiples instancias
de una clase de navegación(<<index>> o <<guided tour>> ) o para seleccionar ítems
(<<query>> ).
• Clases de procesos ( ), las cuales modelan los puntos de entrada y de salida de los
procesos de negocio. Cada clase de proceso está asociada a un caso de uso de proceso.
• Links de procesos, que representan el vínculo entre las clases de proceso y de
navegación.
El modelo de estructura de navegación se representa mediante diagramas de clases
UML estereotipados con las clases de navegación y procesos, menús y primitivas de
acceso y así también los links de navegación y proceso.
Modelo de Presentación
El modelo de presentación proporciona una vista abstracta de la interfaz de usuario
(UI) de la aplicación web. Se basa en el modelo de navegación y describe qué elementos
(por ejemplo texto, elementos, links, formularios) se utilizarán para presentar los nodos de
navegación.
Los elementos básicos del modelo de presentación son:
• Clases de presentación, las cuales se basan directamente en los nodos del modelo
de navegación. Una clase de presentación ( ) está compuesta por elementos de UI tales
como, texto (<<text>> ), vinculo (<<anchor>> ), botón (<<button>> ), imagen (<<image>> ),
formulario (<<form>> ), y colección de vínculos (<<anchored collection>> )
• Páginas web (<<page>>), que se utilizan para modelar la información proveniente
de varios nodos de navegación y que se presentan en una misma página web.
• Grupo de presentación (<<presentation group>>), el cual es un contenedor de
clases de presentación, y a su vez de otros grupos de presentación
Modelo de Requerimientos
Modelo Conceptual.
Modelo de Usuario.
Modelo de Navegación
Modelo de Presentación
Modelo de adaptación.
https://www.obs-edu.com/int/blog-project-management/metodologias-
agiles/caracteristicas-y-fases-del-modelo-incremental
https://geekytheory.com/programacion-extrema-que-es-y-principios-basicos
https://www.pokytools.cl/blog/archivo/305
https://www.ecured.cu/Modelo_de_prototipos
http://ith-gabriel.blogspot.com/
http://gestionrrhhusm.blogspot.com/2011/05/modelo-de-prototipo.html