Você está na página 1de 7

Semana 1.

Ciclo de vida del software

A lo largo de la historia, se han propuesto diferentes paradigmas o ciclos de vida para el


software: desde el ciclo en cascada, pasando por el modelo en espiral, y recientemente ciclos
de vida con orientacin gil.

CICLO DE VIDA DEL SOFTWARE:

Por ciclo de vida, se entiende la sucesin de etapas por las que pasa el software desde que un
nuevo proyecto es concebido hasta que se deja de usar.

Implementacin, es la fase donde se genera el producto ncleo del proyecto: el cdigo.


Despliegue, es la fase donde se instala y configura los archivos que constituyen la aplicacin as
como se prepara el entorno donde se ejecutar.

La ELECCION del modelo de ciclo de vida de un proyecto depende de la naturaleza de este.

METODOLOGIA TRADICIONAL : CASCADA, ESPIRAL, ETC.

Es SECUENCIAL
SI EXISTE UN PROBLEMA SE VUELVE A LOS PASOS ANTERIORES Y LUEGO SE VUELVE
NUEVAMENTE PASO X PASO.

METODOLOGIA AGIL:

Adaptable al cambio
Cliente y desarrolladores deben trabajar juntos DIARIAMENTE durante el Project.
Conversacin cara a cara entre equipo de trabajo para mejor Comunicacin.
Software funcionando es la medida primaria de progreso, preferible tener una parte
bsica funcionando del proyecto que solo tener BD construida o solo interfaces.

4 IDEAS FUNDAMENTALES PARA EMPEZAR A UTILIZAR METODOLOGIAS AGILES

1. INTERACCION ENTRE PERSONA ES MEJOR QUE CUALQUIER HERRAMIENTA Q SE


PUEDE UTILIZAR PARA DESARROLLAR
2. ES MEJOR TENER SW FUNCIONANDO QUE TENER DOCUMENTACION COMPRENSIVA

3. PREFERIBLE INTERACTUAR CON EL CLIENTE PARA CAMBIOS QUE TENER UN


CONTRATO DE NEGOCIO DE REQUERIMIENTOS

4. PODER JUGAR CON EL ALCANCE, NEGOCIANDO LOS PRODUCTOS DE ENTREGA

SCRUM

Es un FRAMEWORK - MARCO DE TRABAJO, TE DICE QUE HACER PERO NO


COMO
TIEMPO - COSTO - ALCANCE --------- EN SCRUM UN ESCENARIO IDEAL para
JUGAR CON EL ALCANCE(NO FIJO).

roles scrum:

Product Owner: Normalmente cliente


Scrum Master: NO es jefe, es un gua

Conceptos:
User stories: que debera hacer el SW? quien afecta? quien necesita?
Task: Cada una de las tareas en que se divide una User Story ,tareas ms
tcnicas, create tables, class
Story Point: no es medida de tiempo, Medida de esfuerzo para completar un
Task o User Story.
Spike: son como user stories que sirven como aprendizaje (spike mybatis -
frameworks)
Sprint: Ciclo de desarrollo.
Sprint Planning: Reunin donde se crea y define el alcance de un Sprint.
Sprint Backlog: Lista de User Stories que se desarrollarn en un Sprint.
Daily Meeting: Reuniones diarias.
Sprint Review (Demo): Revisin y validacin al final del Sprint.
Retrospective: Reunin de autoevaluacin y retroalimentacin.

KANBAN
TABLERO QUE MUESTRAS TAREAS PENDIENTES, EN PROGRESO, TERMINADO
MUESTRA AL EQUIPO EN QUE ESTADO ESTAN LOS MODULOS DE PROGRAMACION
QUE SE ESTAN REALIZANDO
DA UN ENFOQUE MAS VIVO A LOS PROGRAMADORES
TRATA DE MOSTRAR AL EQUIPO DE TRABAJO COMO ESTA EL ESTADO DEL PROYECTO
TRATA DE CONTROLAR LAS ACCIONES DEL PROYECTO, ELIMINANDO LO QUE NO SE
NECESITA o RETRASA AL PROYECTO
Semana 2. Arquitectura de una aplicacin Web Java

Una buena arquitectura determina una buena calidad y duracin al Sistema.

Arquitectura es una abstraccin de un sistema, define sus elementos y cmo interactan.

VISTAS

La arquitectura de una aplicacin puede representarse a travs de vistas. Una vista


arquitectnica representa distintas partes de la arquitectura

Lgica. Es el modelo de objetos de diseo


como interactan las clases entre ellas (diag clases, etc UML)
procesos. Captura aspectos de concurrencia y sincronizacin del diseo.
Diagrama BPMN
Desarrollo. Describe la organizacin esttica del SW
Diagrama de secuencia
Fsica. Mapeos de SW con respecto del HW
(tiempo de ejecucin)

Factores que definen la arquitectura de un proyecto:

Experiencia
Alcance Proyecto
Equipo de desarrollo
Proyecto y sus restricciones
Requerimientos No funcionales

CAPAS

Son abstracciones que permiten agrupar mdulos o secciones de funcionalidad de un sistema.

El nmero de capas depender de las caractersticas del sistema, las capas ayudan al
MANTENIMIENTO y DESARROLLO de diferentes secciones de una aplicacin.

PRESENTACION NEGOCIO - ACCESOS A DATOS


Presentacin, comunica al cliente con nuestra aplicacin (IU)

Negocio, Brinda funcionalidad ncleo de los procesos realizados por nuestra aplicacin

Acceso a datos, comunica a nuestra aplicacin con las diferentes fuentes de datos.

Disea para la Evolucin, para futuro, un sistema cambia con el tiempo, la arquitectura debe
ADAPTARSE a dichos cambios.

Diagrama para comunicar, nuestros diagramas sobre la arquitectura deben entenderse


fcilmente por las personas que trabajaran con el sistema para que puedan respetarla.

Modelo para controlar riesgos, se debe modelar una arquitectura teniendo en cuenta los riesgos
que puede tener el sistema

Asume decisiones crticas, Se debe definir una arquitectura tomando decisiones que involucren
las caractersticas que requiere el SW, as eso implique una debilidad en algn aspecto del
sistema, p.e. a ms seguridad menos tiempo de respuesta

Patrones de diseo

Builder.

Como Patrn de diseo, el patrn builder (Constructor) es usado para permitir la creacin de
una variedad de objetos complejos desde un objeto fuente (Producto), el objeto fuente se
compone de una variedad de partes que contribuyen individualmente a la creacin de cada
objeto complejo a travs de un conjunto de llamadas a interfaces comunes de la clase Abstract
Builder.
Builder
- Interfaz abstracta para crear productos.

Concrete Builder
- Implementacin del Builder.
- Construye y rene las partes necesarias para construir los productos

Director
- construye un objeto usando el patrn Builder.

Producto
- El objeto complejo bajo construccin

Ventajas:
Reduce el acoplamiento - Permite un mayor control en el proceso de creacin del objeto.

Decorator.
El patrn Decorator responde a la necesidad de aadir dinmicamente funcionalidad a
un Objeto.
Cundo Utilizarlo?

Cuando la extensin mediante la herencia no es viable


Hay una necesidad de extender la funcionalidad de una clase, pero no hay razones
para extenderlo a travs de la herencia.

Ventajas

Ms flexible que la herencia. Al utilizar este patrn, se pueden aadir y eliminar


responsabilidades en tiempo de ejecucin. Adems, evita la utilizacin de la herencia
con muchas clases y tambin, en algunos casos, la herencia mltiple.
Patrn Estrategia
Cualquier programa que ofrezca un servicio o funcin determinada, que pueda ser realizada
de varias maneras, es candidato a utilizar el patrn estrategia.
Puede haber cualquier nmero de estrategias y cualquiera de ellas podr ser intercambiada
por otra en cualquier momento, solo cambiando de Instancia, incluso en tiempo de
ejecucin.
Este patrn PERMITE que un solo mtodo tenga VARIOS algoritmos

Participantes

Contexto (Context) : Es el elemento que usa los algoritmos, por tanto, delega en la jerarqua de
estrategias. Configura una estrategia concreta mediante una referencia (instancia) a la
estrategia necesaria.

Estrategia (Strategy): Declara una interfaz comn para todos los algoritmos soportados. Esta
interfaz ser usada por el contexto para invocar a la estrategia concreta.

EstrategiaConcreta (ConcreteStrategy): Implementa el algoritmo utilizando la interfaz definida


por la estrategia.
Patron Template

Este patrn PERMITE que VARIOS mtodos compartan un MISMO algoritmo (diferencia
primordial con el patrn Strategy)

Porque utilizarlo?

Evitar duplicacin en el cdigo: (Se quiere factorizar cdigo) la estructura general de flujo de
trabajo est implementada una vez en el algoritmo de clase abstracta, y variaciones necesarias
son implementadas en cada de las subclases.

Patron FACTORY METHOD

Propsito: Definir una interface para crear un objeto, dejando a las subclases decidir de que
tipo de clase se realizar la instancia. Reducir el uso del operador new.

Crear objetos en una clase usando un mtodo factory es ms flexible que crear un objeto
directamente. Es posible conectar la generacin de familias de clases que tienen
comportamientos en comn. Elimina la necesidad de estar haciendo binding (casting) hacia
clases especficas dentro del cdigo, ya que este solo se entiende con las clases abstractas.

Aplicacin: Usamos el patrn Factory...

Cuando una clase no puede anticipar que clase de objetos debe crear, esto se sabe durante el
tiempo de ejecucin.

Cuando un mtodo regresa una de muchas posibles clases que comparten caractersticas
comunes a travs de una superclase.

Para encapsular la creacin de objetos