Prototipo Corregido

PRE-DISEÑO

SOLUCIÓN INFORMÁTICA

Aplicación Web

Una aplicación web es un conjunto de páginas que interactúan unas con otras y con diversos recursos en un servidor web, incluidas bases de datos. Esta interacción permite implementar características en su sitio como catálogos de productos virtuales y administradores de noticias y contenidos. Adicional-mente podrá realizar consultas a bases de datos, registrar e ingresar información, solicitudes, pedidos y múltiples tipos de información en línea en tiempo real.

Nuestros desarrollos se llevan a cabo bajo parámetros y ambientes de última generación garantizando un funcionamiento óptimo. En Sur On Line contamos con una amplia variedad de módulos-web que le permitirán mantener su Sitio interactivo y actualizado de una forma rápida y segura. Estos módulos pueden además personalizarse de acuerdo a las necesidades, por lo que nuestros clientes reciben exactamente lo que necesitan con una inversión mínima y al ser implementadas en plataformas web usted no debe adquirir ningún tipo de equipos o software adicional.

Como funcionan las aplicaciones web

Los administradores de contenidos vía web almacenan los datos en BASES DE DATOS (BD). Estas BD están formadas por un número variable de tablas que contienen columnas y filas, estas tablas se componen del contenido que ha sido previamente cargado en ellas a través de formularios.

En estas tablas llamamos al nombre de cada columna CAMPO. Y a cada fila REGISTRO. AMBOS EN EL SISTEMA POSEEN NUMEROS DE ID (identificación) QUE SON ÚNICOS PARA CADA UNO DE ELLOS.

Las páginas que se generan a partir de esos contenidos son llamadas dinámicas. En este contexto el término dinámico no indica movimiento o animación, sino que hace referencia al hecho de que las páginas dinámicas de un sitio web se generan a partir de una SOLICITUD o CONSULTA que realiza una máquina CLIENTE a un SERVIDOR WEB (en este caso). Se podría decir que la página dinámica no existe hasta que no es solicitada por el navegante. Cuando el navegante la solicita oprimiendo alguno de los comandos disponibles se dispara la consulta a la BASE DE DATOS, y el sistema MUESTRA una página web con el contenido que este programado en la consulta.

CICLO, FACES, O PASOS DE LA METODOLOGÍA

Ciclo y fases de la metodologia AUP

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Al final de cada uno de ellos se obtiene una versión final del producto, que no sólo satisface ciertos casos de uso, sino que está lista para ser entregada y puesta en producción. En caso de que fuese necesario publicar otra versión, deberían repetirse los mismos pasos a lo largo de otro ciclo.

Como se es sabido cada ciclo se compone de varias fases, y dentro de cada una de ellas, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones, con sus incrementos resultantes. Cada fase termina con un hito, determinado por la disponibilidad de un conjunto de artefactos, modelos o documentos.

En AUP se establecen cuatro fases que transcurren de manera consecutiva y que acaban con hitos claros alcanzados:

• Inception(Concepción): El objetivo de esta fase es obtener una comprensión común cliente-equipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo.

• Elaboración: El objetivo es que el equipo de desarrollo profundice en la comprensión de los requisitos del sistema y en validar la arquitectura.

• Construcción: Durante la fase de construcción el sistema es desarrollado y probado al completo en el ambiente de desarrollo.

• Transición: el sistema se lleva a los entornos de preproducción donde se somete a pruebas de validación y aceptación y finalmente se despliega en los sistemas de producción. 

Las disciplinas se llevan a cabo de manera sistemática, a la definición de las actividades que realizan los miembros del equipo de desarrollo a fin de desarrollar, validar, y entregar el software de trabajo que responda a las necesidades de sus interlocutores. Las disciplinas son:

1. Modelo. El objetivo de esta disciplina es entender el negocio de la organización, el problema de dominio que se abordan en el proyecto, y determinar una solución viable para resolver el problema de dominio.

2. Aplicación. El objetivo de esta disciplina es transformar su modelo (s) en código ejecutable y realizar un nivel básico de las pruebas, en particular, la unidad de pruebas.

3. Prueba. El objetivo de esta disciplina consiste en realizar una evaluación objetiva para garantizar la calidad. Esto incluye la búsqueda de defectos, validar que el sistema funciona tal como está establecido, y verificando que se cumplan los requisitos.

4. Despliegue. El objetivo de esta disciplina es la prestación y ejecución del sistema y que el mismo este a disposición de los usuarios finales.

5. Gestión de configuración. El objetivo de esta disciplina es la gestión de acceso a herramientas de su proyecto. Esto incluye no sólo el seguimiento de las versiones con el tiempo, sino también el control y gestión del cambio para ellos.

6. Gestión de proyectos. El objetivo de esta disciplina es dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestión de riesgos, la dirección de personas (la asignación de tareas, el seguimiento de los progresos, etc), coordinación con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto.

7. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuerzos por garantizar que el proceso sea el adecuado, la orientación (normas y directrices), y herramientas (hardware, software, etc) estén disponibles para el equipo según sea necesario.

METODOLOGÍA SELECCIONADA POR EL DISEÑO Y DESARROLLO DE LA SOLUCIÓN INFORMÁTICA

PROCESO UNIFICADO AGIL (AUP)

El Proceso Unificado Agil o Agile Unified Process (AUP) en inglés es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Agil, Gestión de Cambios Agil, y Refactorización de Base de Datos para mejorar la productividad.

El proceso unificado (Unified Process o UP) es un marco de desarrollo software iterativo e incremental. A menudo es considerado como un proceso altamente ceremonioso porque especifica muchas actividades y artefactos involucrados en el desarrollo de un proyecto software. Dado que es un marco de procesos, puede ser adaptado y la más conocida es RUP (Rational Unified Process) de IBM.

AUP se preocupa especialmente de la gestión de riesgos. Propone que aquellos elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. Para ello, se crean y mantienen listas identificando los riesgos desde etapas iníciales del proyecto. Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables durante la base de elaboración del producto, donde se demuestre la validez de la arquitectura para los requisitos clave del producto y que determinan los riesgos técnicos.

El proceso AUP establece un Modelo más simple que el que aparece en RUP por lo que reúne en una única disciplina las disciplinas de Modelado de Negocio, Requisitos y Análisis y Diseño. El resto de disciplinas (Implementación, Pruebas, Despliegue, Gestión de Configuración, Gestión y Entorno) coinciden con las restantes de RUP. 

Justificación del Uso del Proceso Unificado Ágil como Modelo de Desarrollo:

Un modelo de ciclo de vida de software es una vista de las actividades que se llevan a cabo durante el desarrollo de éste, e intenta determinar el orden de las etapas involucradas y proporcionar unos criterios para avanzar de unas a otras. Por tanto, definir un ciclo de vida permite llevar un mayor control sobre las tareas, evitando que estas se vayan eligiendo y realizando de manera desordenada, según parezca que van surgiendo necesidades, que podrían ser puntuales y fácilmente evitables.

Uso del Proceso Unificado de Desarrollo

Debido al carácter relativamente investigador de este proyecto, y a la necesidad de modificar los requisitos que surgirían según se fueran evaluando y probando las distintas posibilidades con las que se cuenta para desarrollarlo, un modelo pesado no se ajusta de manera adecuada.

Sin embargo, un modelo puramente ágil necesita de un equipo de desarrollo con experiencia para ser llevado a cabo de manera satisfactoria, por lo que éste tampoco es el caso más adecuado para su aplicación. Es por ello que se ha optado por un modelo que combina características de ambas orientaciones, proporcionando un enfoque iterativo e incremental: el Proceso Unificado de Desarrollo propuesto por Rumbaugh, Booch y Jacobson.

Características del Proceso Unificado de Desarrollo

Al igual que con cualquier otro modelo de desarrollo, del Proceso Unificado también se pueden destacar ciertas características.

Dirigido por los casos de uso:

Un sistema software se crea para servir a sus usuarios por lo que, para construir un sistema exitoso, se debe conocer qué es lo que quieren y necesitan. El término “usuario” no se refiere solamente a los usuarios humanos sino también a otros sistemas, es decir, representa a algo o alguien que interactúa con el sistema a desarrollar.

En el Proceso Unificado, los casos de uso se utilizan para capturar los requisitos funcionales y para definir los objetivos de las iteraciones. En cada una, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso.

Centrado en la arquitectura:

El concepto de arquitectura del software involucra los aspectos estáticos y dinámicos más significativos del sistema, y actúa como vista del diseño, dando una perspectiva completa y describiendo los elementos más importantes. La arquitectura surge de los propios casos de uso, sin embargo, también está influenciada por muchos otros factores, como la plataforma en la que se ejecutará, el uso de estándares, la existencia de sistemas heredados (aunque éste no sea el caso que nos ocupa) o los requisitos no funcionales.

Puesto que la arquitectura y los casos de uso están relacionados, por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura, y ésta debe ser lo bastante flexible para realizar todos los casos de uso, hoy y en el futuro. De palabras de los propios creados del Proceso Unificado, es un problema semejante al del “huevo y la gallina”. En la realidad, arquitectura y casos de uso deben evolucionar en paralelo.

Enfocado en los riesgos:

Para disminuir la posibilidad de fallo en las iteraciones o incluso la de cancelación del proyecto, se deben llevar a cabo sucesivos análisis de riesgos durante todo el desarrollo. Por supuesto, los riesgos principales deben ser identificados en una etapa temprana del ciclo de vida, y además, los resultados de cada iteración deben seleccionarse en un orden que asegure que estos son considerados primero.

PLANILLAS

ONTROL DE ASISTENCIA DE LAS ASESORIAS

PNF Informática – Proyecto Socio-Tecnológico

TUTOR: T.S.U Luis Mata
Trayecto: II	Trimestre: V	Fecha:23/10/2013	Semana:
Nombre del Proyecto: Desarrollo de una aplicación web para el control de citasmedicas en el centro de Rehabilitación Integral Mundo de Sonrisas-Heres ubicadoen la parroquia Catedral de Ciudad Bolívar Municipio Heres del Estado Bolívar.

Recomendaciones	Observaciones
Utilizar Metodología AUP, por ser una parte ágil y por su aplicación en cuanto a proyectos pequeños. Investigar fases de esta metodología y ejemplos.	El grupo selecciono una metodología la cual es buena, sin embargo para trabajar de una forma mas eficaz se cambia la metodología para una mas ágil.

Nro.	Apellidos y Nombres	Cédula	Firma
	Jésus Espinoza	21,262,171
	Jaciel Alcala	24,193,923
	Andreina Rodriguez	21,008,616

Firma del Tutor: CI: ____________________

PNF EN INFORMATICA
PROYECTO SOCIO-TECNOLOGICO II
VISITA AL TUTOR TECNICO
GRUPO NRO:12 SECCION:1M TURNO:Mañana TRAYECTO II TRIMESTRE V

FECHA: 23/10/13

SOLUCION INFORMATICA: Aplicación web para el control de citas medicas en el el centro de rehabilitacion integral “Mundo De Sonrisas - Heres”

MOTIVO DE LA TUTORIA:Seleccion de la metodologia

METODOLOGIA SELECCIONADA:Proceso Unificado Agil (AUP)

OBSERVACIONES:Cambio de metodologia para una mas eficaz.

PROXIMO ENCUENTRO CON EL GRUPO:

__________________________________

FIRMA TUTOR TECNICO

VISITA A UN CENTRO DE GESTION PARROQUIAL

VISITA A UN CENTRO DE GESTION PARROQUIAL

SECCION  1M    GRUPO Nº 12  FECHA  15/10/2013        

NOMBRE DEL  CENTRO DE GESTION PARROQUIAL

 U.E.E. “JOSÉ LUIS AFANADOR”

UBICACIÓN

CALLE O AVENIDA: AV. SAN SALVADOR – EN FRENTE DE GRANITOS BOLIVAR

PARROQUIA: LA SABANITA    

COMUNIDAD: LOS ACEITICOS   

PERSONAL ENCARGADO

LICDO. EDGAR BOLÍVAR

FECHA DE SU INAUGURACION   NOVIEMBRE DEL 2004   

HORARIOS: DE 2:00PM A 6:00PM

PROMEDIO DE USUARIOS  DIARIOS QUE ATIENDE   10   

ACTIVIDADES QUE SE REALIZAN EN ESTE CENTRO:

 TALLERES DE COMPUTACIÓN

 OFICINA DE LA MISIÓN RIBAS

REQUISITOS PARA USAR EL C.G.P.

 ESTAR REGISTRADO EN C.G.P

OBJETIVO DEL C.G.P.

PROMOVER LAS NUEVAS TECNOLOGIAS

ORGANISMOS QUE APOYAN AL CENTRO DE GESTION PARROQUIAL: 

 MISIÓN RIBAS

INVENTARIO

1.- EQUIPO DE COMPUTACION:

 MARCA: IBM

MODELO: PENTIUM 4

NUMERO EXISTENTE:   15                  OPERATIVOS: 15

2.- PROCESADOR: 

MARCA: INTEL PENTIUM 4

VELOCIDAD DE TRABAJO: 2.80GHz

3.- MEMORIA RAM: 

MARCA: 

ALMACENAMIENTO DE TRABAJO: 240MB

4.-TARJETA MADRE: 

MARCA:

MODELO:

5.- DISCO DURO: 

MARCA:

CAPACIDAD DE ALMACENAMIENTO: 40GB

VELOCIDAD DE TRABAJO:

6.- UNIDADES: 

 DISQUETERAS: FLOPPY.

LECTORA O QUEMADOR: UNIDAD DE CD SOLO LECTURA.

7.- TECLADO: 

MARCA: IBM

ESTANDAR: SI     OTRO:

8.- RATON:

 MARCA: IBM

MECANICO: SI         OPTICO.

9.- MONITOR:

 MARCA: IBM

 TIPO:   

LCD:                

 CRT: SI

10: SISTEMA OPERATIVO:

CANAIMA 3.0 (RORAIMA).

   
galería fotográfica

.  

VISITA A LA BIBLIOTECA VIRTUAL " MANUEL CARLOS PIAR"

VISITA A  LA BIBLIOTECA VIRTUAL

SECCION 1M GRUPO Nº 12   FECHA 14-10-2013

NOMBRE DEL INFOCENTRO

Fundación Biblioteca virtual “Manuel Carlos Piar”

UBICACIÓN: Edificio Casalta

CALLE O AVENIDA: Paseo orinoco

PARROQUIA:  Catedral

COMUNIDAD: Casco Historico

PERSONAL ENCARGADO

Directora: Licda Andrea Figuera

FECHA DE SU INAUGURACION:  12 de enero del 2009

HORARIOS: De 8:30am a 12:00pm y de 2:00pm a 4:00pm

PROMEDIO DE USUARIOS  DIARIOS QUE ATIENDE: 30 personas aproximadamente

ACTIVIDADES QUE SE REALIZAN EN ESTE INFOCENTRO:

·        Cursos y talleres de informática (hardware y software)

·        Proyectos de aprendizaje en colegios

·        Atención al cliente

REQUISITOS PARA USAR EL INFOCENTRO:

·        Cedula de identidad

OBJETIVO DEL INFOCENTRO:

·        ]Promover el software libre

·        Desarrollar las capacidades y habilidades para el aprovechamiento de las TIC en la elaboración, formulación, seguimiento y ejecución de proyectos que beneficien el desarrollo comunitario.

·        Dar a conocer los principios éticos, morales, políticos, culturales, sociales y legales que sustentan la apropiación social del conocimiento en la Republica Bolivariana de Venezuela.

ORGANISMOS QUE LOS APOYAN

·        Gobernación del Estado Bolívar

·        Zona Educativa

·         

DECRETO PRESIDENCIAL Nº 825:

El decreto 825 (Firmado en Mayo del 2000) Declara el acceso y el uso de Internet como política prioritaria para el desarrollo cultural, económico, social y político de la República Bolivariana de Venezuela. Desarrollando lo previamente establecido en el Plan Nacional de Telecomunicaciones sobre el desarrollo de una Sociedad de la Información. Igualmente, el Decreto dispone las directrices que deberán seguir los órganos de la Administración Pública Nacional para la inserción de esta tecnología de información en todos los ámbitos de la nación.

1.- EQUIPO DE COMPUTACION: 80 EQUIPOS

 MARCA: SIRAGON, SONEVIEW

MODELO: VARIADOS

NUMERO EXISTENTE: 80                  

OPERATIVOS: 80

2.- PROCESADOR: INTEL

MARCA: INTEL CELERON

VELOCIDAD DE TRABAJO: 2.53 GHz

3.- MEMORIA RAM:

MARCA: DDR 400, DDR 2

ALMACENAMIENTO DE TRABAJO: 512 MB

4.-TARJETA MADRE: FOXCONN

MARCA: FOXCONN

MODELO: 100 M LAN

5.- DISCO DURO:

MARCA: WESTERN DIGITAL

CAPACIDAD DE ALMACENAMIENTO: 80 GB

VELOCIDAD DE TRABAJO: 7200 RPM

6.- UNIDADES:

 DISQUETERAS: 3 1/2

LECTORA O QUEMADOR: LG

7.- TECLADO:

MARCA: SONEVIEW, SIRAGON, GENIUS

ESTANDAR: SI      OTRO:

8.- RATON:

 MARCA: SONEVIEW

MECANICO:             OPTICO: SI

9.- MONITOR: SIRAGON

 MARCA: SIRAGON

 TIPO: 

LCD:              

 CRT: SI

10: SISTEMA OPERATIVO:

 GNU/LINUX: Canaima 3.0

WINDOWS SERVICE PACK 3

galería fotográfica 

Visita a un Infocentro

VISITA UN INFOCENTRO

SECCIÓN 1M GRUPO Nº 12   FECHA 14-10-2013

NOMBRE DEL INFOCENTRO

Fundación Biblioteca virtual “Manuel Carlos Piar”

UBICACIÓN: Edificio Casalta

CALLE O AVENIDA: Paseo orinoco

PARROQUIA:  Catedral

COMUNIDAD: Casco Historico

PERSONAL ENCARGADO

Directora: Licda Andrea Figuera

FECHA DE SU INAUGURACION:  12 de enero del 2009

HORARIOS: De 8:30am a 12:00pm y de 2:00pm a 4:00pm

PROMEDIO DE USUARIOS  DIARIOS QUE ATIENDE: 30 personas aproximadamente

ACTIVIDADES QUE SE REALIZAN EN ESTE INFOCENTRO:

Cursos y talleres de informática (hardware y software)

Proyectos de aprendizaje en colegios

Atención al cliente

REQUISITOS PARA USAR EL INFOCENTRO:

Cédula de identidad

OBJETIVO DEL INFOCENTRO:

]Promover el software libre

Desarrollar las capacidades y habilidades para el aprovechamiento de las TIC en la elaboración, formulación, seguimiento y ejecución de proyectos que beneficien el desarrollo comunitario.

Dar a conocer los principios éticos, morales, políticos, culturales, sociales y legales que sustentan la apropiación social del conocimiento en la Republica Bolivariana de Venezuela.

ORGANISMOS QUE LOS APOYAN

·         Gobernación del Estado Bolívar

·         Zona Educativa

·          

DECRETO PRESIDENCIAL Nº 825:

El decreto 825 (Firmado en Mayo del 2000) Declara el acceso y el uso de Internet como política prioritaria para el desarrollo cultural, económico, social y político de la República Bolivariana de Venezuela. Desarrollando lo previamente establecido en el Plan Nacional de Telecomunicaciones sobre el desarrollo de una Sociedad de la Información. Igualmente, el Decreto dispone las directrices que deberán seguir los órganos de la Administración Pública Nacional para la inserción de esta tecnología de información en todos los ámbitos de la nación.

1.- EQUIPO DE COMPUTACION: 80 EQUIPOS

 MARCA: SIRAGON, SONEVIEW

MODELO: VARIADOS

NUMERO EXISTENTE: 80                  

OPERATIVOS: 80

2.- PROCESADOR: INTEL

MARCA: INTEL CELERON

VELOCIDAD DE TRABAJO: 2.53 GHz

3.- MEMORIA RAM:

MARCA: DDR 400, DDR 2

ALMACENAMIENTO DE TRABAJO: 512 MB

4.-TARJETA MADRE: FOXCONN

MARCA: FOXCONN

MODELO: 100 M LAN

5.- DISCO DURO:

MARCA: WESTERN DIGITAL

CAPACIDAD DE ALMACENAMIENTO: 80 GB

VELOCIDAD DE TRABAJO: 7200 RPM

6.- UNIDADES:

 DISQUETERAS: 3 1/2

LECTORA O QUEMADOR: LG

7.- TECLADO:

MARCA: SONEVIEW, SIRAGON, GENIUS

ESTANDAR: SI      OTRO:

8.- RATON:

 MARCA: SONEVIEW

MECANICO:             OPTICO: SI

9.- MONITOR: SIRAGON

 MARCA: SIRAGON

 TIPO: 

LCD:              

 CRT: SI

10: SISTEMA OPERATIVO:

 GNU/LINUX: Canaima 3.0

WINDOWS SERVICE PACK 3

galería fotográfica 

METODOLOGÍA UWE

Metodología UWE

UWE es un proceso del desarrollo para aplicaciones Web enfocado sobre el diseño sistemático, la personalización y la generación semiautomática de escenarios que guíen el proceso de desarrollo de una aplicación Web. UWE describe una metodología de diseño sistemática, basada en las técnicas de UML, la notación de UML y los mecanismos de extensión de UML.

Es una herramienta que nos permitirá modelar aplicaciones web, utilizada en la ingeniería web, prestando especial atención en sistematización y personalización (sistemas adaptativos). UWE es una propuesta basada en el proceso unificado y UML pero adaptados a la web. En requisitos separa las fases de captura, definición y validación. Hace además una clasificación y un tratamiento especial dependiendo del carácter de cada requisito.

En el marco de UWE es necesario la definición de un perfil UML (extensión) basado en estereotipos con este perfil se logra la asociación de una semántica distinta a los diagramas del UML puro, con el propósito de acoplar el UML a un dominio específico, en este caso, las aplicaciones Web. Entre los principales modelos de UWE podemos citar: el modelo lógico-conceptual, modelo navegacional, modelo de presentación, visualización de Escenarios Web y la interacción temporal, entre los diagramas: diagramas de estado, secuencia, colaboración y actividad.

UWE define vistas especiales representadas gráficamente por diagramas en UML. Además UWE no limita el número de vistas posibles de una aplicación, UML proporciona mecanismos de extensión basados en estereotipos. Estos mecanismos de extensión son los que UWE utiliza para definir estereotipos que son lo que finalmente se utilizarán en las vistas especiales para el modelado de aplicaciones Web. De esta manera, se obtiene una notación UML adecuada a un dominio en específico a la cual se le conoce como Perfil UML.

 UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial hincapié en características de personalización, como es la definición de un modelo de usuario o una etapa de definición de características adaptativas de la navegación en función de las preferencias, conocimiento o tareas de usuario.

Fases de la metodología UWE: 

1) Captura, análisis y especificación de requisitos: En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y especifican las características funcionales y no funcionales que deberá cumplir la aplicación web.

   Trata de diferente forma las necesidades de información, las necesidades de navegación, las necesidades de adaptación y las de interfaz de usuario, así como algunos requisitos adicionales. Centra el trabajo en el estudio de los casos de uso, la generación de los glosarios y el prototipado de la interfaz de usuario.

2) Diseño del sistema: Se basa en la especificación de requisitos producido por el análisis de los requerimientos (fase de análisis), el diseño define cómo estos requisitos se cumplirán, la estructura que debe darse a la aplicación web.

3) Codificación del software: Durante esta etapa se realizan las tareas que comúnmente se conocen como programación; que consiste, esencialmente, en llevar a código fuente, en el lenguaje de programación elegido, todo lo diseñado en la fase anterior.

4) Pruebas: Las pruebas se utilizan para asegurar el correcto funcionamiento de secciones de código.

5) La Instalación o Fase de Implementación: es el proceso por el cual los programas desarrollados son transferidos apropiadamente al computador destino, inicializados, y, eventualmente, configurados; todo ello con el propósito de ser ya utilizados por el usuario final.

Esto incluye la implementación de la arquitectura, de la estructura del hiperespacio, del modelo de usuario, de la interfaz de usuario, de los mecanismos adaptativos y las tareas referentes a la integración de todas estas implementaciones.

6 )El Mantenimiento: es el proceso de control, mejora y optimización del software ya desarrollado e instalado, que también incluye depuración de errores y defectos que puedan haberse filtrado de la fase de pruebas de control.

El modelo que propone UWE está compuesto por etapas o sub-modelos:

•   Modelo de Casos de Uso

•   Modelo de Contenido

•   Modelo de Usuario

•   Modelo de estructura

•   Modelo Abstracto

•   Modelo de Adaptación

•   modelo de flujo de presentación.

•   modelo de ciclo de vida del objeto.

METODOLOGIA AUP

El Proceso Unificado (UP) y Proceso Unificado Relacional (RUP):

El Proceso Unificado (UP) es un producto de software marco de ingeniería de procesos (un caso de uso impulsada por la arquitectura centrada en el riesgo, iterativo e incrementa  en paralelo, la lucha, orientado a objetos, y el componente de enfoque). También es conocido como el Proceso Unificado de Desarrollo de Software (USDP). Ha sido desarrollado por Grady Booch, James Rumbaugh, e Ivar Jacobson (los Tres Amigos). La UP ofrece una infraestructura para la ejecución de proyectos de software de ingeniería de productos, un marco integrado de los hitos principales y secundarias y de disciplinas.

El Rational Unified Process (RUP) es un producto de proceso desarrollado y comercializado por IBM Rational Software. El RUP proporciona los detalles necesarios para la ejecución de proyectos de uso de la UP, incluyendo directrices, plantillas y asistencia de la herramienta.

La UP surgió como la unificación de Rational Rational Software Corporation enfoque y el proceso de Objectory AB, cuando Rational Software Corporation adquirió Objectory AB en 1995. El Rational Software Corporation, desarrolló el enfoque racional como resultado de diversas experiencias de los clientes. Ivar Jacobson creó el proceso de Objectory principalmente como resultado de su experiencia con Ericsson en Suecia. Rational Software Corporation fue adquirida por IBM a finales de 2002.

 El Proceso Unificado Ágil (AUP):

La UP es un software producto ingeniería marco de proceso que puede abordarse mediante tres perspectivas, incluyendo colaboraciones, contexto y las interacciones que se centran en un ciclo de vida de compuesto por fases, disciplinas y iteraciones.

En la siguiente figura se muestra una vista conceptual de los elementos esenciales que constituyen la UP y AUP.

Figura: AUP vs RUP

Una colaboración implica una interacción dentro de un contexto. En la UP, una colaboración captura quién hace qué actividades (cómo) sobre lo que funcionan los productos. Por lo tanto, establece los elementos de un proyecto. Colaboraciones implican a trabajadores (funciones), actividades y productos (artefactos) de trabajo. En el AUP, colaboraciones se centrarán en colaboradores (colaboradores y confirmantes), metas y objetivos y resultados. Un contexto se hace hincapié en el aspecto estructural o estático de una colaboración, los elementos que colaboran y su conglomerado o las relaciones espaciales. En la UP, un contexto captura cuando y donde estas actividades deben ser hechas, trabajo, productos (artefactos) producidos y consumidos. Por lo tanto, establece el marco para un proyecto. Contextos implican ciclos de desarrollo y fases, iteraciones y disciplinas. Las fases de la UP incluyen principio, diseño, construcción y transición. Disciplinas de la UP incluyen Business Modeling, requisitos, análisis y diseño, prueba, implementación, configuración y administración de cambios, gestión de proyectos y medio ambiente. En el AUP, contextos centrarán en objetivos.

Una interacción enfatiza el aspecto de comportamiento o dinámica de una colaboración, los elementos que colaboran y en su cooperación o la comunicación temporal. En la UP, una interacción captura cuándo y por qué esas actividades se debe hacer y los productos de trabajo (artefactos) producidos y consumidos. Así, establece la ejecución de un proyecto. Interacciones implican requisitos o casos de uso, un sistema y su arquitectura, iteraciones, y el riesgo. En el AUP, las interacciones se centran en los objetivos.

Figura: AUP

El AUP define metas y objetivos donde las colaboraciones se utilizan para lograr resultados. Una colaboración puede ser el trabajo realizado por una persona que puede interactuar con otros usuarios. Una colaboración puede ser un taller en el que participaron varios individuos que interactúan entre sí y pueden interactuar con otros fuera del taller. Objetivos son similares a UP fases en las que se utilizan como puertas que implican las partes interesadas y los usuarios. Objetivos son similares a UP iteraciones en caja el tiempo que implican a los usuarios y dar como resultado un producto de la versión.

El objetivo de iniciar (Concepción) es establecer el producto visión, plan de proyecto, negocios y justificación tecnológica e identificar los riesgos y las oportunidades. Puede haber uno o más objetivos que deben lograrse en alcanzar este objetivo.

• Las partes interesadas se centran en el problema, solución y restricciones (equipo de trabajo visionario).

• Los usuarios se centrarán en sus necesidades y las características de los productos de alto nivel (análisis de requerimientos por parte del equipo de trabajo).

• Las partes interesadas y los usuarios se centrarán en el establecimiento de la justificación del negocio para el producto y el proyecto.

• Los usuarios y el equipo de desarrollo de software se centrarán en el establecimiento de la justificación de tecnología para el producto y el proyecto.

• El equipo (equipo de desarrollo de software, las partes interesadas y los usuarios) se centran en dar prioridad a los riesgos y las oportunidades (labor de planificación por parte del equipo de trabajo).

• El equipo se centra sobre las características de los productos Ejecute (innovación) metas y objetivos en el plan de trabajo del proyecto (labor de planificación por parte del equipo de trabajo).

• El equipo establece la infraestructura de desarrollo.

El objetivo de ejecutar (innovación) es evolucionar el visión de producto, plan de proyecto y justificación de negocio y tecnología; identificar y hacer frente a riesgos; identificar y aprovechar oportunidades mientras diseñar, desarrollar (aplicación y pruebas) y desplegar (integración, construcción y libertad) el producto. Normalmente hay muchos objetivos y metas, cada una resultante de la implementación del producto.

• Estrategias (Definir).

• El equipo considera posibles cambios en el producto y el proyecto y sus ramificaciones, decide aceptar o rechazar los posibles cambios y incorpora los cambios aceptados en el producto y el proyecto (equipo de trabajo y los cambios - consideraciones).

• Las partes interesadas y los usuarios se centran en evolucionar la visión (equipo de trabajo visión y requisitos).

• El equipo se centra en la evolución de los negocios y la justificación de la tecnología para el producto y el proyecto.

• El equipo se centra en la evolución de los riesgos y oportunidades y plan de proyecto (labor de planificación del equipo de trabajo).

• El equipo se centra en la adopción de un pulso del producto y el proyecto en metas y objetivos (talleres de pulso).

• Ejecutar (arquitectos, desarrollar (implementación y pruebas), implementar).

• El equipo se centra en aprovechar oportunidades mientras que enfrentan riesgos en diseñar, desarrollar (aplicación y pruebas) y desplegar (integración, creación y liberación) el producto (talleres de desarrollo de productos).

• El equipo aborda cuestiones (talleres de resolución de problemas El equipo aborda cuestiones (talleres de resolución de problemas).

• El equipo identifica posibles cambios en el producto y el proyecto.

El objetivo de cerrar (dejar) es retirar el producto y cerrar el proyecto (talleres de cierre). Puede haber uno o mas objetivos que debe lograrse en alcanzar este objetivo.

La visión provee dirección y un enfoque general, esta guía provee dirección específica a través de las metas y las misiones a través de los objetivos, y las colaboraciones establecen intuición, confianza, unidad, y cohesión.

Justificación del Uso del Proceso Unificado Ágil como Modelo de Desarrollo:

Un modelo de ciclo de vida de software es una vista de las actividades que se llevan a cabo durante el desarrollo de éste, e intenta determinar el orden de las etapas involucradas y proporcionar unos criterios para avanzar de unas a otras. Por tanto, definir un ciclo de vida permite llevar un mayor control sobre las tareas, evitando que estas se vayan eligiendo y realizando de manera desordenada, según parezca que van surgiendo necesidades, que podrían ser puntuales y fácilmente evitables.

Uso del Proceso Unificado de Desarrollo

Debido al carácter relativamente investigador de este proyecto, y a la necesidad de modificar

                                                                                               

los requisitos que surgirían según se fueran evaluando y probando las distintas posibilidades con las que se cuenta para desarrollarlo, un modelo pesado no se ajusta de manera adecuada.

Sin embargo, un modelo puramente ágil necesita de un equipo de desarrollo con experiencia para ser llevado a cabo de manera satisfactoria, por lo que éste tampoco es el caso más adecuado para su aplicación. Es por ello que se ha optado por un modelo que combina características de ambas orientaciones, proporcionando un enfoque iterativo e incremental: el Proceso Unificado de Desarrollo propuesto por Rumbaugh, Booch y Jacobson.

 Características del Proceso Unificado de Desarrollo

Al igual que con cualquier otro modelo de desarrollo, del Proceso Unificado también se pueden destacar ciertas características.

 Iterativo e incremental:

El Proceso Unificado es un marco de desarrollo compuesto de cuatro fases:

o Inicio

o Elaboración

o Construcción

o Transición

Cada una de ellas es, a su vez, dividida en una serie de iteraciones que ofrecen como resultado un incremento del producto desarrollado, que añade o mejora las funcionalidades del sistema en desarrollo. Es decir, un “incremento” no implica necesariamente una ampliación de dicho sistema.

Durante cada una de estas iteraciones se realizarán a su vez las actividades definidas en el ciclo de vida clásico: requisitos, análisis, diseño, implementación, prueba e implantación. Aunque todas las iteraciones suelen incluir trabajo en casi todas estas actividades, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. Por ejemplo, en la fase de inicio se centrarán más en la definición de requisitos y en el análisis, y durante la de construcción quedarán relegadas en favor de la implementación y las pruebas.

Si una iteración cumple sus metas, publicando una nueva versión del producto que implemente ciertos casos de uso, el desarrollo continúa con la siguiente. Cuando no las cumple, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.

 Dirigido por los casos de uso:

Un sistema software se crea para servir a sus usuarios por lo que, para construir un sistema exitoso, se debe conocer qué es lo que quieren y necesitan. El término “usuario” no se refiere solamente a los usuarios humanos sino también a otros sistemas, es decir, representa a algo o alguien que interactúa con el sistema a desarrollar.

En el Proceso Unificado, los casos de uso se utilizan para capturar los requisitos funcionales y para definir los objetivos de las iteraciones. En cada una, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso.

Centrado en la arquitectura:

El concepto de arquitectura del software involucra los aspectos estáticos y dinámicos más significativos del sistema, y actúa como vista del diseño, dando una perspectiva completa y describiendo los elementos más importantes. La arquitectura surge de los propios casos de uso, sin embargo, también está influenciada por muchos otros factores, como la plataforma en la que se ejecutará, el uso de estándares, la existencia de sistemas heredados (aunque éste no sea el caso que nos ocupa) o los requisitos no funcionales.

Puesto que la arquitectura y los casos de uso están relacionados, por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura, y ésta debe ser lo bastante flexible para realizar todos los casos de uso, hoy y en el futuro. De palabras de los propios creados del Proceso Unificado, es un problema semejante al del “huevo y la gallina”. En la realidad, arquitectura y casos de uso deben evolucionar en paralelo.

Enfocado en los riesgos:

Para disminuir la posibilidad de fallo en las iteraciones o incluso la de cancelación del proyecto, se deben llevar a cabo sucesivos análisis de riesgos durante todo el desarrollo. Por supuesto, los riesgos principales deben ser identificados en una etapa temprana del ciclo de vida, y además, los resultados de cada iteración deben seleccionarse en un orden que asegure que estos son considerados primero.

 Ciclo de Vida del Proceso Unificado de Desarrollo:

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Al final de cada uno de ellos se obtiene una versión final del producto, que no sólo satisface ciertos casos de uso, sino que está lista para ser entregada y puesta en producción. En caso de que fuese necesario publicar otra versión, deberían repetirse los mismos pasos a lo largo de otro ciclo.

Como se es sabido cada ciclo se compone de varias fases, y dentro de cada una de ellas, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones, con sus incrementos resultantes. Cada fase termina con un hito, determinado por la disponibilidad de un conjunto de artefactos, modelos o documentos. Las iteraciones de cada fase se desarrollan a través de las actividades de identificación de requisitos, análisis, diseño, implementación, pruebas e integración.