WebLogic

Iniciar un proceso en background.

http://rodrigobitsbytes.wordpress.com/2010/06/10/iniciar-un-proceso-en-background/

How to start oracle weblogic as non root

http://www.webspheretools.com/sites/webspheretools.nsf/docs/How%20to%20start%20oracle%20weblogic%20as%20non%20root

 

http://gerardnico.com/wiki/weblogic/administration_server
http://docs.oracle.com/cd/E23943_01/core.1111/e10105/start.htm
http://docs.oracle.com/cd/E13222_01/wls/docs103/jdbc/programming.html

http://docs.oracle.com/cd/E15051_01/wls/docs103/jdbc_admin/config.html
http://weblogicserveradministration.blogspot.com/2010/10/start-stop-weblogic-servers.html
http://support.sas.com/documentation/cdl/en/bisag/64088/HTML/default/viewer.htm#a003150768.htm
http://jianmingli.com/wp/?p=4056
http://jianmingli.com/wp/?p=5159
http://dirknachbar.blogspot.com/2012_08_01_archive.html
http://go2kavinkumar.wordpress.com/2012/08/03/how-to-start-weblogic-managed-servers-without-manually-entering-the-password/

XP Programacion extrema

http://www.extremeprogramming.org/

http://es.scribd.com/doc/100747197/Desarrollo-de-Aplicaciones-Con-Programacion-Extrema
Las Historias de usuario son escritas por los clientes, comolos requerimientos que el cliente necesita que el sistema realice por el. Deben descritas con un formato de dos o tres líneas de texto,hechas por el mismo cliente usando su propia terminología sintérminos técnicos.Cuando llega la hora de implementar una historia de usuario, elcliente y los desarrolladores se reúnen para concretar y detallar loque tiene que hacer dicha historia. El tiempo de desarrollo ideal parauna historia de usuario es entre 01 y 03 semanas.Estas deben proporcionar solo el detalle suficiente como para poderhacer razonable la estimación de cuánto tiempo requiere laimplementación de la historia. Difiere de los casos de uso porque sonescritos por el cliente, no por los programadores, empleandoterminología del cliente. Las historias de usuario son mas

“amigables” que “formales”

http://es.scribd.com/doc/95706115/XP-PROGRAMACION-EXTREMA
4. Proceso de desarrollo.

La programación extrema parte del caso habitual de una compañía que desarrolla software,normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño) , uno dedesarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan elsoftware y clientes es totalmente diferente al que se ha producido en las metodologías tradicionales,que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase devalidación posterior al mismo.
Interaccion con el cliente:
Se elimina lafase inicial de recopilación de requerimientos, y se permite que éstos se vayan cogiendo a lo largodel proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiandode opinión sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar lasdudas del equipo de desarrollo.“

Historia de usuario
”. Se trata de una lista decaracterísticas que el cliente necesita que existan en el producto final. Estas constan de dos fases.
En la primera fase, el cliente describe con sus propias palabras las características y, es elresponsable del equipo, el encargado de informarlo de las dificultades técnicas de cada unade ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjuntode historias y las ordena en función de la prioridad que tienen pera él. De esta manera ya es posible definir unas fechas aproximadas para ellos.
En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá entrabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo dedesarrolladores, esto dará como resultado una planificación más exacta. Este método serepetirá para cada historia.A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente elencargado de escribir los documentos con las especificaciones de lo que realmente quiere, como undocumento de requisitos de usuario.En esta fase, el equipo técnico será el ‘encargado de catalogar las historias del cliente y asignarlesuna duración. La norma es que cada historia de usuario tiene que poder ser realizable en un espacioentre una y tres semanas de programación. Las que requieran menos tiempo serán agrupadas, y lasque necesiten más serán modificadas o divididas.Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que facilitará que elcliente pueda especificar la importancia relativa entre las diferentes historias de usuario

Capas lógicas de aplicación web

http://www.dosideas.com/cursos/mod/resource/view.php?id=10
Arquitectura de 3 capas
Las aplicaciones Java EE deben seguir una arquitectura de 3 capas (también conocida como Modelo 2).

  • Capa de presentación
  • Capa de lógica de negocio
  • Capa de acceso a datos

http://code.google.com/p/uda/wiki/Arquitectura
La arquitectura conceptual definida debe facilitar el proceso de desarrollo de aplicaciones web, aumentando al máximo la productividad de los desarrolladores. Tratamos además de reutilizar, de mantener las cosas simples, no limitar la evolución e independizar la solución de las tecnologías en la medida de lo posible. En definitiva estamos describiendo un sistema basado en componentes reutilizables que unidos a generadores de código nos permitan producir software de calidad con poco esfuerzo.

Fomentar la Productividad del desarrollador, reutilización de código, rendimiento, escalabilidad, fiabilidad, disponibilidad, extensibilidad, mantenibilidad, fácil manejo, y seguridad.
Utilizaremos estándares en forma de patrones de diseño (facade, value object, etc.)

Se han establecido capas lógicas con el objeto de dividir la complejidad de la arquitectura en módulos más manejables.

(BUENO) Arquitectura de N-Capas y N-Niveles
http://jtentor.com.ar/post/Arquitectura-de-N-Capas-y-N-Niveles.aspx

La arquitectura en capas es un estilo de programación donde el objetivo principal es separar los diferentes aspectos del desarrollo, tales como las cuestiones de presentación, lógica de negocio y mecanismos de almacenamiento.

Nivel de aplicación (capas de presentación y lógica de negocio) y Nivel de datos (capa de datos)
Se debe diferenciar entre “nivel” y “capa” porque no significan lo mismo. El término capa se utiliza para referenciar a las distintas “partes” en que una aplicación se dividide desde un punto de vista lógico; mientras que “nivel” corresponde a la forma física en que se organiza una aplicación.

La necesidad de contar con porciones de la aplicación que se puedan “intercambiar” sin tener que modificar el resto de la aplicación es lo que impulsa el desarrollo en capas.

Las capas inferiores brindan servicios a las capas superiores (independientemente del nivel en que se encuentren).
Desde la filosofía de arquitectura en capas, esto significa que la capa de lógica de negocios presenta una “interfaz” para brindar servicios a la capa de presentación.
La clave del desarrollo en capas es que una capa solamente debe utilizar lo que la “interfaz” de la o las capas inferiores le brindan, de este modo se puden intercambiar las capas respetando la “interfaz”, que viene a ser como un “contrato entre capas”.

3 capas
La nueva capa, se denomina Capa de Acceso a Datos (o Capa de Persistencia) que no es lo mismo que Capa de Datos.
La capa de acceso a datos es una porción de código que justamente realiza el acceso a los datos. De esta manera cuando es necesario cambiar el motor de base de datos, solamente tendremos que corregir esa capa.
Mientras que la capa de datos (en el nivel de datos) es donde están los datos y se corresponde directamente con la definición de esquemas, tablas, vistas, procedimientos almacenadaos y todo lo que se pueda o deba poner en un motor de base de datos.

Capa de entidades
Los desarrolladores tienen un problema. Resulta que los componentes de la capa de lógica de negocios necesitan referenciar a instancias de las “clases del dominio” (las que representan las entidades del negocio) y los componentes de la capa de acceso a datos también tienen que referenciarlas para poder “rellenar” tales instancias con los datos que obtienen de las capas inferiores.
Los componentes no pueden caer en un ciclo de referencias recursivo y por eso se crea la capa de Entidades que corresponde al dominio de la aplicación.

En esta capa se encuentra la declaración de las entidades de la aplicación, de manera que se pueden referenciar desde otras capas sin entrar en ciclos recursivos de compilación.

Además este esquema permite una total independencia entre la lógica de negocios (Business Model) y las entidades (Domain Model). Por supuesto que ambas partes están relacionadas por los casos de uso y otros requerimientos de la aplicación.

Por otro lado, este esquema facilita la incorporación, en la capa de acceso a datos, de componentes tipo ORM – Objet / Relational Mapping que permiten “mapear” (representar) objetos en un esquema relacional. Esto funciona bién dado que las bases de datos más  utilizadas (por su mejor performance) son las bases de datos relacionales y no las orientadas a objetos (al menos por ahora).

Servicios Web publicados
Las organizaciones requiere que las aplicaciones de software de las distintas organizaciones interactuen unas con otras. El problema es que algunas de ellas no se ejecutan en la misma plataforma o están desarrolladas con marcos de trabajo diferentes. La solución fue presentada como SOA – Service Oriented Architecture, que brinda entre otras cosas una forma estandard de publicar y utilizar servicios, conocidos comunmente como servicios web (web services).

¿Los servicios publicados forman parte de la capa de lógica de negocio?
Se trata de la lógica de la transacción que involucra dos organizaciones diferentes (aplicaciones diferentes), consecuentemente debe existir un mecanismo que permita confirmar la realización de todos los “pasos” que cada una de las organizaciones requiere; esto normalmente se conoce como WorkFlow.
Surje otra capa más, la capa de Servicios Publicados que pueden o no incluir componentes de WorkFlow pero inevitablemente deben estar por arriba de la capa de lógica de negocios.

capasNiveles

Figura Nro. 1: Arquitectura de capas y niveles (Referido de http://jtentor.com.ar/post/Arquitectura-de-N-Capas-y-N-Niveles.aspx)

—————————————————————————————–

Las características principales de Java EE son:
•Java EE está construida sobre Java SE (no lo reemplaza)
•Se agregan servicios necesarios en aplicaciones empresariales
•Facilita el desarrollo de aplicaciones multicapa ◦presentation layer
◦obusiness rules layer
◦data access layer

Plataforma para desarrollo de Aplicaciones Empresariales
• Arquitectura Cliente/Servidor
– Modelo Lógico: capas (layers)
• Gestor de Presentación (presentation manager): Muestra la interface de usuario.
• Lógica de Presentación (presentation logic): Establece que se debe mostrar al usuario.
• Lógica de la Aplicación (appplication logic): Funcionalidad de la aplicación.
• Lógica del Negocio (business logic): Funcionalidad de la empresa, común para todas las aplicaciones.
• Lógica de los Datos (data logic): Definición lógica de los datos (tablas, vistas, tipos de datos, claves, etc.)
• Gestor de Datos (data manager): Encargada de escribir y acceder a la base de datos.

http://www.uhu.es/josel_alvarez/NvasTecnProg/recursos/tTema1.pdf

Construcción por Capas de Aplicaciones Java
http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/desarrollo/capa-negocio-aplicaciones-java

Tipos de aplicaciones

http://www.dosideas.com/cursos/mod/resource/view.php?id=10

Ejemplo de aplicacion Java EE 6. Tienda Web con JPA+EJB+JSF

http://ccia.ei.uvigo.es/docencia/SCS/1112/jee/ejemplo-JEE-1112.pdf

La capa de Negocio de la Arquitectura Java EE

http://ocw.uc3m.es/ingenieria-telematica/software-de-comunicaciones/transparencias/6_nivelnegocio.pdf

Arquitectura y Diseño de Aplicaciones Java EE

Notación para el modelado de proceso del negocio (BPMN)

Introducción al
Modelado de Procesos de Negocio
http://www.ugr.es/~mnoguera/collaborative_systems-business_processes_10-11.pdf
ESTRATEGIAS PARA IMPULSAR MADUREZ DE
PROCESOS EN BANCA Y COMPAÑIAS DE
SEGUROS
http://www.expertia.com/expertiapanama/sites/default/files/Presentacion%20BPMS%20Panama%20def.pdf
Un lenguaje de Transformación específico para Modelos de Proceso del Negocio
http://caeti.uai.edu.ar/archivos/279_UN_LENGUAJE_DE_TRANSFORMACION_ESPECIFICO_PARA_MODELOS_DE_PROCESO_DEL_NEGOCIO_-_CLEI_2010.PDF
Procesos de Negocio: Procesos de Software y Gestión del Conocimiento
http://alarcos.inf-cr.uclm.es/doc/psgc/doc/psgc0809_parte4b_pn.pdf

Notación para el Modelado de Proceso de Negocio (BPMN) Poster
https://www.u-cursos.cl/ingenieria/2010/2/IN73J/1/material_docente/bajar?id_material=310376

 

BIZAGI BPMN 2.0 – Ejemplos
http://www.bizagi.com/docs/BPMNbyExampleSPA.pdf

BIzagi BPM SUite
http://www.bizagi.com/docs/BizAgi%20Descripcion%20Funcional.pdf
Business Process Model and Notation (BPMN)
http://www.omg.org/spec/BPMN/2.0/PDF/

Analisis-Estimacion-y-Planificacion-Agil

Revisado el 18/10/2012

Taller para la Gestión Ágil de Proyectos de Software
http://www.sceu.frba.utn.edu.ar/cursosfooter/gestion/taller-para-la-gestion-agil-de-proyectos-de-software-.html

Estimación en un proyecto ágil
http://agilismoatwork.blogspot.com/2011/12/estimacion-en-un-proyecto-agil.html

La Historia de Usuario y el Planning Poker – Grandes herramientas parael desarrollo y la estimación ágil.
http://www.franciscojavierpulido.com/2012/07/la-historia-de-usuario-y-el-planning.html

Mejores libros ágiles
http://www.javiergarzas.com/2012/04/mejores-libros-agiles.html

Lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito
http://www.javiergarzas.com/2012/07/scrum-solo.html
metodologias-agiles
http://www.javiergarzas.com/metodologias-agiles
Puntos de función, de casos de uso
http://www.kybeleconsulting.com/servicios/calidad-gestion-ingenieria-del-software/puntos-funcion/
LECCIÓN 12: Estimación Ágil
http://asier-ares.blogspot.com/2012/05/leccion-12-estimacion-agil.html

Un contrato ágil para Scrum
http://www.proyectosagiles.org/contrato-agil-scrum

Priorización de prácticas ágiles en un proyecto corto – IX y X encuentros ágiles en Barcelona
http://www.proyectosagiles.org/priorizacion-practicas-agiles
Priorización de prácticas ágiles en desarrollo de producto – XI encuentro ágil en Barcelona
http://www.proyectosagiles.org/priorizacion-practicas-agiles-producto
planificacion-agil-vs-planificacion-tradicional

http://www.proyectosagiles.org/planificacion-agil-vs-planificacion-tradicional
Creación de product backlog
http://www.proyectosagiles.org/creacion-product-backlog-tercer-encuentro-agil-barcelona

Revisado en fechas anterior

http://www.proyectosagiles.org/tecnicas-agiles-cmmi-2-proyecto-banca

http://es.scribd.com/doc/88194426/Analisis-Estimacion-y-Planificacion-Agil
http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
http://www.slideshare.net/hhiroshi/estimacin-y-planificacin-gil-9278498
PRÁCTICAS ÁGILES DE ESTIMACIÓN Y PLANIFICACIÓN
http://www.navegapolis.net/content/view/790/58/
http://www.ibm.com/developerworks/ssa/linux/library/l-agile-plan/