UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA

VICERECTORADO ACADEMICO
INGENIERICA EN INFORMATICA
DESARROLLO WEB.

Profesor. Integrantes.
Oscar Rodriguez Franklin Gutiérrez.
Ángel Jaramillo.

PUERTO ORDAZ, MAYO DEL 2019.

Tabla de contenido
METODOLOGIAS DE DESARROLLO DE SOFTWARE. ........................................... 3
MÉTODO LÍNEA O MÉTODO CASCADA. ................................................................... 3
METODOLOGIA EN PROTOTIPADO. .......................................................................... 3
METODOLOGICA INCREMENTAL. ............................................................................. 4
METODOLOGÍA ÁGIL .................................................................................................... 5
Xp. (Programación extrema.) ............................................................................................. 5
METODOLOGIA SCRUM................................................................................................ 7
METODOLOGIA UWE. ................................................................................................... 8
PREGUNTAS PARA EL CUESTIONARIO. .................................................................. 11
REFERENCIAS BIBLIOGRAFICAS. ............................................................................ 13
 METODOLOGIAS DE DESARROLLO DE SOFTWARE.
Se identifica como el conjunto de procedimientos, técnicas y soporte documental
utilizados para el diseño de sistemas de información. En ingeniería de software cuando se
hace referencia al desarrollo de software, se está hablando del desarrollo de programas,
los cuales deben cumplir una serie de etapas o fases, para poder funcionar con otros
métodos ya establecidos en otras disciplinas de ingeniería. Muestra los pasos a seguir para
realizar un sistema o aplicación de manera ordenada y estandarizada, usando protocolos y
herramientas tipificadas.

MÉTODO LÍNEA O MÉTODO CASCADA.

Dicta una manera secuencial, sistemática, para el desarrollo de un software que se
pueden ver como niveles (de allí el nombre de cascada.) que son Análisis, diseño, código,
prueba y mantenimiento.

 Análisis. Es el proceso de reunión de requisitos para comprender el comportamiento

y la funcionalidad de la aplicación que se va a construir.

 Diseño. Es un proceso de muchos pasos que se centra en 4 atributos: Estructura de

datos, arquitectura de software, representaciones de interfaz y detalle procedimental
del algoritmo según los datos del análisis.

 Código. Es el proceso de materializar el diseño en una forma legible para la

máquina.

 Prueba. El proceso de pruebas se centra en los procesos lógicos del código,

certificando que funcione de manera correcta el sistema.

 Mantenimiento. Este proceso trata de corregir errores y adaptar la aplicación en

detalles en el sistema.

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:

 Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos

globales, se identifican los requisitos conocidos y las áreas donde es obligatorio más
definición.
 Construir y revisar la maqueta (prototipo).
 El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del
software.
Tipo De Modelos De Prototipos.

 Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente

nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es
desarrollado mediante un nuevo prototipo.
 Modelo de Prototipos reutilizable: También conocido como "Evolutionary
Prototyping"; no se pierde el esfuerzo efectuado en la construcción del prototipo
pues sus partes o el conjunto pueden ser utilizados para construir el producto real.
 Modelo de Prototipos Modular: También conocido como Prototipado Incremental
(Incremental prototyping); se añaden nuevos elementos sobre el prototipo a medida
que el ciclo de diseño progresa.
 Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de aspectos
y funciones, pero la mayoría no son operativas. Resulta muy útil para evaluar el
alcance del producto, pero no su uso real.
 Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de
funciones operativas. Resulta muy útil para evaluar el uso real sobre una pequeña
parte del producto.
 Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lápiz,
emulando la función del producto real sin mostrar el aspecto real del mismo. Resulta
muy útil para realizar tests baratos.
 Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma más
cercana posible al diseño real en términos de aspecto, impresiones, interacción y
tiempo.

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:

 Los incrementos son pequeños.

 Permite una fácil administración de las tareas en cada iteración.
  La inversión se materializa a corto plazo.
 Es un modelo propicio a cambios o modificaciones.
 Se adapta a las necesidades que surjan.
El modelo de gestión incremental no es un modelo necesariamente rígido, es decir, que
puede adaptarse a las características de cualquier tipo de proyecto, existen al menos 7
fases que debemos tener en cuenta a la hora de implementarlo:
1. Requerimientos: son los objetivos centrales y específicos que persigue el proyecto.
2. Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el
siguiente paso es hacer una lista de tareas y agruparlas en las iteraciones que
tendrá el proyecto. Esta agrupación no puede ser aleatoria. Cada una debe
perseguir objetivos específicos que la definan como tal.
3. Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será
la evolución del producto en cada una de ellas. Cada iteración debe superar a la
que le ha precedido. Esto es lo que se denomina incremento.
4. Desarrollo del incremento: posteriormente se realizan las tareas previstas y se
desarrollan los incrementos establecidos en la etapa anterior.
5. Validación de incrementos: al término de cada iteración, los responsables de la
gestión del proyecto deben dar por buenos los incrementos que cada una de ellas
ha arrojado. Si no son los esperados o si ha habido algún retroceso, es necesario
volver la vista atrás y buscar las causas de ello.
6. Integración de incrementos: una vez son validados, los incrementos dan forma a lo
que se denomina línea incremental o evolución del proyecto en su conjunto. Cada
incremento ha contribuido al resultado final.
7. Entrega del producto: cuando el producto en su conjunto ha sido validado y se
confirma su correspondencia con los objetivos iniciales, se procede a su entrega
final.

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.

Xp. (Programación extrema.)

Es una metodología de desarrollo ágil que tiene como objetivo aumentar la
productividad a en momento de desarrollar un proyecto software. Reduciendo la
burocracia que pueda existir en el entorno de trabajo.
 La efectividad de XP se consigue a través de diversas técnicas aplicadas. El
objetivo principal de XP es entregar un software de calidad controlado por las
necesidades del cliente en corto tiempo haciendo sentir al cliente involucrado. Consigue
esté objetivo administrando la complejidad. Ésta es un arma poderosa ya que las
metodologías tradicionales suelen seguir la curva de forma que el coste de modificación
del software incrementa exponencialmente a medida que se invierte más tiempo en todas
las fases del desarrollo.
La metodología tiene como base la simplicidad y como objetivo principal la satisfacción
del cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales:

 Retroalimentación.
 Proceso continuo en lugar de por bloques.
 Propiedad intelectual compartida.
 Entendimiento compartido.
Retroalimentación

 Principio de pruebas: lo primero que se debe hacer es establecer un período de

pruebas de aceptación del programa, en el cual se definirán las entradas y salidas
del sistema. Básicamente se define lo que debe hacer el software desarrollado
 Planificación: el cliente (o su representante) escribirá sus necesidades para definir
concretamente las actividades que el sistema debe realizar. En esta fase se creará
un documento que contendrá historias de usuario que forman el plan de liberación,
el cual define los tiempos de entrega de la aplicación para poder recibir feedback
por parte del cliente.
 Cliente in-situ: el cliente (o su representante) deberá formar parte del equipo de
desarrollo. Se le dará poder para determinar los requisitos de la aplicación, definir
la funcionalidad y dar prioridad a determinadas cosas. Gracias a esto, habrá una
fuerte interacción con los programadores, disminuyendo así el tiempo de
comunicación y la cantidad de documentación a redactar. El cliente estará con el
equipo durante todo el proceso de desarrollo del proyecto.
 Pair-programming: este punto junto con el anterior son los más radicales de esta
metodología. Consiste en escribir código en parejas compartiendo una sola
máquina. Según los experimentos ya realizados sobre este método, se producen
mejores y más consistentes aplicaciones a igual o menor coste.
Proceso Continuo En Lugar De Por Bloques

 Integración continua: consiste en implementar progresivamente las nuevas

características del software. En lugar de crear versiones estables en función de una
planificación previamente realizada, los programadores reúnen su código y
reconstruyen el proyecto varias veces al día si hace falta.
 Refactorización: mediante la constante eliminación de código duplicado y/o
ineficiente los equipos de programación mejoran el diseño del sistema. El código se
evalúa continuamente para ofrecer la mayor calidad posible.
 Entregas pequeñas: el producto es evaluado en un ambiente real mediante la
colocación de un sistema sencillo en producción el cual se actualizará rápidamente,
es decir, cada 2 semanas (3 como máximo) el software será puesto en producción.
Entendimiento Compartido

 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.

Bienestar Del Programador

 Semana de 40 horas: los programadores cansados escriben peor código. Es

importante minimizar las horas extras y mantener a los programadores frescos y
descansados. De esta manera, se generará mejor código. Si es necesario hacer
horas extras, quiere decir que el proyecto está mal planificado.
Herramientas de la XP

 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.

 Tarjetas CRC: Describen las clases utilizadas en la programación de una historia.

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

PREGUNTAS PARA EL CUESTIONARIO.

1. ¿Qué son metodologías para el desarrollo de software?
R. Se identifica como el conjunto de procedimientos, técnicas y soporte documental
utilizados para el diseño de sistemas de información.

2. ¿Cuáles son los valores de la metodología de XP?

R.
o Retroalimentación.
o Proceso continuo en lugar de por bloques.
o Propiedad intelectual compartida.
o Entendimiento compartido.

3. ¿Cuáles son los modelos de diseño de UWE?

R.

 Modelo de Requerimientos
 Modelo Conceptual.
 Modelo de Usuario.
 Modelo de Navegación
 Modelo de Presentación
 Modelo de adaptación.

4. ¿Qué metodología es mejor?

 R. Ninguna, cualquier metodología funciona para un caso específico y estructura
de trabajo que se acomode la empresa, organización o grupo.
5. ¿Paradigma de construccion del modelado de prototipos?
R.
 Escuchar al cliente
 Construir y revisar la maqueta (prototipo).
 El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del
software.
 REFERENCIAS BIBLIOGRAFICAS.

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