4.1.

El Enfoque Estructurado
En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de
Datos) como principal herramienta para entender al sistema antes de
plasmarlo a cdigo fuente. DFD es un diagrama en el que participan procesos
(mtodos), flujo de datos (argumentos) y archivos (Base de datos). Hay de
diferentes niveles dependiendo la complejidad del sistema que se analiza,
hablando de lenguajes tiene muchas diferencia con la orientada a objetos, un
mnimo cambio en el cdigo puede llegar alterar al resto del programa cosa
que en la orientada a objetos eso no sucede lo cual es una ventaja porque as
no se pierde tiempo en arreglar cosas ya hechas. Una desventaja es que una
porcin de cdigo en lenguaje estructurado es difcil que pueda servir en
otros proyectos, esto si es habitual en lenguaje orientada a objetos, con solo
importar clases ya hechas se escribe menos cdigo y se ahorra tiempo.

Diagrama de Flujo de Datos

Un diagrama de flujo de datos (DFD) es un modelo lgico-grfico para

representar el funcionamiento de un sistema en un proyecto software.

Diccionario de Datos

El diccionario de datos es un listado organizado de todos los datos que

pertenecen a un sistema.

El objetivo de un diccionario de datos es dar precisin sobre los datos

que se manejan en un sistema, evitando as malas interpretaciones o
ambigedades.

Diseo de Mdulo
Un modelo de datos es un lenguaje orientado a describir una Base de Datos.
Tpicamente un Modelo de Datos permite describir:

Las estructuras de datos de la base: El tipo de los datos que hay en la

base y la forma en que se relacionan.

Las restricciones de integridad: Un conjunto de condiciones que

deben cumplir los datos para reflejar correctamente la realidad
deseada.

Operaciones de manipulacin de los datos: Operaciones de agregado,

borrado, modificacin y recuperacin de los datos de la base.

Otro enfoque es pensar que un modelo de datos permite describir los

 elementos de la realidad que intervienen en un problema dado y la
forma en que se relacionan esos elementos entre s.

Proceso
Conjunto de tareas lgicamente relacionadas que existen para obtener un
resultado definido dentro de un negocio o proyecto.

NOTA: REFERENCIA FUTURA PARA COMPLEMENTAR EL TEXTO

Enfoque Estructurado

Diagrama de Flujo de Datos

Un diagrama de flujo de datos (DFD) es una representacin grfica de los
procesos que se realizan con los datos en su organizacin, con el uso de tan
solo cuatro smbolos, se puede crear una descripcin grafica de los procesos
que, con el tiempo, contribuirn a desarrollar una slida documentacin del
sistema.

En seguida mencionan las ventajas sobre las explicaciones

descriptivas en relacin con la forma en que los datos se mueven a
travs del sistema:
Libertad para emprender la implementacin tcnica del sistema en las
primeras etapas.
Comprensin ms profunda de la interrelacin entre sistemas y subsistemas.
Comunicacin con los usuarios sobre el conocimiento del sistema actual
mediante diagramas de flujos de datos.
Anlisis de un sistema propuesto para determinar si se han definido los datos
y procesos necesarios.

La ventaja ms grande es la libertad conceptual para utilizar los

cuatro smbolos, los DFDs hacen nfasis en el procesamiento o la
transformacin conforme estos pasan por una variedad de procesos.
En los DFDs lgicos no hay distincin entre procesos manuales o
automatizados. Los procesos tampoco se representan grficamente
en orden cronolgico. En vez de ello, se agrupan solo si el anlisis
detallado dicta que tiene sentido hacerlo. Los procesos manuales se
agrupan, y los procesos automatizados tambin se pueden agrupar.
Diccionario de Datos
El diccionario de datos surge de la necesidad de catalogar los procesos, flujos
almacenes estructuras y elementos de datos. Los nombres que se usan son
muy importantes. Cuando se tiene la oportunidad de asignar nombre a los
componentes de los sistemas orientados a datos, es necesario trabajar en la
creacin de un nombre significativo pero diferente al de otros componentes
de datos existentes.

Se ha propuesto el diccionario de datos como gramtica casi formal para

describir el contenido de los objetos definidos durante el anlisis
estructurado. Esta notacin ha sido definida de la siguiente forma por
Yourdon en 1989:

El diccionario de datos es un listado organizado de todos los elementos de

datos que son pertinentes para el sistema, con definiciones precisas y
rigurosas que permiten que el usuario y el analista del sistema tenga una
misma comprensin de las entradas, salidas, de los componentes de los
almacenes y tambin los clculos intermedios. [2]

Muchos sistemas de administracin de base de datos estn

equipados con un diccionario de datos automatizado. Estos
diccionarios pueden ser complejos o sencillos, algunos diccionarios
de datos computarizados catalogan automticamente los elementos
de datos cuando se hace la programacin; otros simplemente
proporcionan una plantilla para motivar a la persona que llene el
diccionario a que lo haga de una manera uniforme para cada
entrada.

A pesar de la existencia de los diccionarios de datos automatizados,

entender qu datos conforman un diccionario de datos, las
convenciones usadas en estos ltimos y cmo se desarrolla un
diccionario de datos, son problemas que el analista de sistemas debe
tener siempre presentes durante el esfuerzo de sistemas. Entender el
proceso de compilar un diccionario de datos puede ayudar al
analista de sistemas a visualizar el sistema y su
funcionamiento. Adems de proporcionar documentacin y eliminar
la redundancia, el diccionario datos se podra usar para:

Validar la integridad y exactitud del diagrama de flujo de datos.

Proporcionar un punto de partida para desarrollar pantallas e

informes.

Determinar el contenido de los datos almacenados en archivos.

 Desarrollar la lgica para los procesos del diagrama de flujo de datos.

Diseo de Mdulo

El concepto de modularidad se ha ido exponiendo desde hace casi cinco

dcadas en el software de computadora. La arquitectura de computadora
expresa la modularidad; es decir, el software se divide en componentes
nombrados y abordados por separado, llamados frecuentemente mdulos,
que se integran para satisfacer los requisitos del problema.

Se ha afirmado que La modularidad es el nico atributo del software que

permite gestionar un programa intelectualmente. El software monoltico (es
decir, un programa grande formado por un nico modulo) no puede ser
entendido fcilmente por el lector. La cantidad de rutas de control, la
amplitud de referencias, la cantidad de variables y la complejidad global har
que el entendimiento este muy cerca de ser imposible. Para ilustrar este
punto, tomemos en consideracin el siguiente argumento basado en
observaciones humanas sobre la resolucin de problemas.

Enfoque y Diseo Estructurado

El Enfoque se refiere al "extremo inicial" de un proyecto de

desarrollo de sistemas, durante el tiempo en que los requisitos del
usuario son definidos y documentados.

El Enfoque estructurado introduce el uso de las herramientas de

documentacin grficas para producir un tipo diferente de
especificacin funcional: "la especificacin estructurada".

Conceptos que se relacionan con el Enfoque Estructurado

Smbolos grficos; iconos y convenciones para

identificar y describir los componentes de un sistema
junto con las relaciones entre estos componentes.
Diccionario de datos; descripciones de todos los datos
utilizados en el sistema.
Descripciones de procesos y
procedimientos; declaraciones formales que emplean
tcnicas y lenguajes que permiten a los analistas describir
actividades importantes que forman parte del sistema.
Reglas; estndares para describir y documentar el
sistema en forma correcta y completa.

Fase de Diseo

En esta fase, el diseo esctructurado produce el modelo de diseo con

los siguientes elementos:
Diseo de datos. Transforma el modelo de dominio de la
informacin creado durante el anlisis, en las estructuras de datos
necesarias para implementar el software. Los objetos de datos y las
relaciones definidas en el diagrama entidad-relacin y el contenido
detallado de datos del diccionario de datos constituyen la base para el
diseo de datos.
Diseo arquitectnico. Define la relacin entre los principales
elementos estructurales del programa. Se obtiene a partir del modelo
de anlisis y de la interaccin de subsistemas definidos dentro del
modelo de anlisis.
Diseo de interfaz. Describe como se comunica el software
consigo mismo, con los sistemas que operan con l y con los
operadores que lo emplean. Los diagramas de flujo de datos y control
proporcionan la informacin necesaria para el diseo de la interfaz.
Diseo procedimental. Transforma elementos estructurales de la
arquitectura del programa en una descripcin procedimental de los
componentes del software. Se obtiene a partir de la especificacin del
proceso, la especificacin del control y el diagrama de transicin de
estados

Segn el Modelo Estructurado

El enfoque Estructurado, fue seleccionado como tcnica de investigacin

de requerimientos, ya que permite al analista conocer el sistema o
proceso en una forma lgica y manejable, al mismo tiempo que
proporciona la base para asegurar que no se omite ningn detalle. Este
es un mtodo para el anlisis de sistemas manuales o automatizados,
que conduce al desarrollo de especificaciones para sistemas nuevos o
para efectuar modificaciones a los ya existentes. Aunado a ello y por ser
considerados como una herramienta capaz de describir y analizar el
movimiento de los datos a travs de un sistema, la representacin
grfica de los procesos del sistema estar a cargo de los Diagramas de
Flujos de Datos (DFD).
4.2. El Enfoque Orientado a Objetos
El contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad
que encapsula datos (atributos) y acciones o
funciones que los manejan (mtodos). Tambin para el EOO un objeto se
define como una instancia o particularizacin de una
clase.

Los objetos de inters durante el desarrollo de software no slo son tomados

de la vida real (objetos visibles o tangibles),
tambin pueden ser abstractos. En general son entidades que juegan un rol
bien definido en el dominio del problema. Un libro,
una persona, un carro, un polgono, son apenas algunos ejemplos de objeto.

Cada objeto puede ser considerado como un proveedor de servicios utilizados

por otros objetos que son sus clientes. Cada
objeto puede ser a al vez proveedor y cliente. De all que un programa pueda
ser visto como un conjunto de relaciones entre
proveedores clientes. Los servicios ofrecidos por los objetos son de dos tipos:

1. Los datos, que llamamos atributos.

2. Las acciones o funciones, que llamamos mtodos.

Fundamentos del Enfoque Orientado a Objeto

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen
la base de todo desarrollo orientado a objetos.
Estos principios son: la Abstraccin, el Encapsulamiento, la Modularidad y la
Herencia.
Otros elementos a destacar (aunque no fundamentales) en el EOO son:
Polimorfismo, Enlace dinmico (o binding),
Concurrencia y Persistencia.

*****************

El anlisis orientado a objetos (AOO) y el diseo orientado a objetos (DOO)

constituyen un enfoque distinto de desarrollo de sistemas. Estas tcnicas se
basan en los conceptos de la programacin orientada a objetos, que han sido
codificados en UML (Lenguaje Unificado de Modelacin), un lenguaje
estandarizado de modulacin en el cual los objetos generados no solo
incluyen cdigo referente a los datos sino tambin instrucciones acerca de las
operaciones que se realizaran sobre los datos.

EL Paradigma Orientado a Objetos es una disciplina de ingeniera de

desarrollo y modelado de software que permite construir ms fcilmente
sistemas complejos a partir de componentes individuales.

Objetos + Mensajes = Programa

El proceso Orientado a Objetos se mueve a travs de una espiral evolutiva

que comienza con la comunicacin con el usuario. Es en esta parte donde se
define el dominio del problema y se identifican las clases bsicas del
problema. La planificacin y el anlisis de riesgos establecen una base para el
plan de proyecto OO. El trabajo tcnico asociado con la ingeniera del
software OO sigue las siguientes tareas:

1. Identificar clases candidatas

2. Buscar clases en biblioteca

3. Extraer nuevas clases si existen

4. Desarrollar las clases sino existen

5. Aadir las nuevas clases a la biblioteca

6. Construir n-esima iteracin del sistema

La ingeniera de software hace hincapi en la reutilizacin. Por lo tanto las

clases se buscan en una biblioteca (de clases existentes) antes de construirse

Las Caractersticas del Enfoque Orientado a Objetos son:

a) Objeto: Los datos estn cuantificados en entidades discretas y
distinguibles llamadas objetos.

b) Clase: Significa que los objetos con la misma estructura de datos

(atributos) y comportamiento (operaciones) se agrupa para formar una clase.

c) Atributo: Describen la clase o el objeto de alguna manera

d) Mensajes: Medio por el cual interactan los objetos

e) Polimorfismo: Significa que una misma operacin puede comportarse de

modos distintos en distintas clases.

f) Herencia: Compartir atributos y operaciones entre clases tomando como

base una relacin jerrquica.

Enfoque y Diseo Orientado a

Objetos (ADOO)

Es un mtodo de Enfoque que examina los

requerimientos desde la perspectiva de clase y
objetos encontrada en el vocabulario original del
problema. Se fundamenta en un conjunto de cinco
principios bsicos:
Modelar el dominio de la informacin.
Describir la funcin del mdulo.
Representar el comportamiento del modelo.
Dividir el modelo para mostrar ms detalles.
En este tipo de anlisis los modelos iniciales
representan la esencia del problema, mientras que
los ltimos aportan detalles de la implementacin.

Caractersticas del Enfoque Orientado a Objetos

Identidad: Los datos estn cuantificados en

entidades discretas y distinguibles denominadas
objetos. Estos pueden ser tangibles o intangibles.
Clasificacin: Los objetos con la misma
estructura de datos (atributos) y comportamiento
(operaciones) se agrupan para formar una misma
clase, se dice que cada objeto es una instancia de su
propia clase, y una clase es una abstraccin que
describe propiedades importantes para una
aplicacin y se olvida del resto.
Polimorfismo: Significa que una misma
operacin puede comportarse de modos distintos
en distintas clases, una operacin es una accin o
transformacin que se aplica a un objeto.
Herencia: Comparte atributos y operaciones
entre clases tomando como base una relacin
jerrquica, es decir que se puede definir una clase
que despus producir subclases, sabiendo que
todas las subclases adquirirn todas y cada una de
las propiedades de su super-clase y le agrega
adems sus propiedades exclusivas.

Fase de Diseo

Para los sistemas orientados a objetos es posible

definir un diseo en pirmide con las siguientes
cuatro capas:
Subsistema. Contiene una representacin de
cada uno de los subsistemas que le permiten al
software conseguir los requisitos definidos por el
cliente e implementar la infraestructura tcnica que
los soporta.
Clases y Objetos. Contiene las jerarquas de
clases que permiten crear el sistema utilizando
generalizaciones y especializaciones mejor
definidas incrementalmente. Tambin contiene
representaciones de diseo para cada objeto.
Mensajes. Contiene los detalles que permiten a
cada objeto comunicarse con sus colaboradores.
Establece las interfaces externas e internas para el
sistema.
Responsabilidades. Contiene las estructuras de
datos y el diseo algortmico para todos los
atributos y operaciones de cada objeto.

Tabla de Diferencias

Enfoque y Diseo Enfoque y Diseo

Estructurado Orientado a Objetos

Se consideran los Se consideran los

elementos o conceptos bsicos como
perspectivas bsicas del el Objeto y el Atributo, el
anlisis (Entrada- todo y sus partes
Proceso-Salida), en (software), clases y
funcin del Software. miembros. Modela los
objetos que son parte de
l.

Utiliza el diagrama Utiliza el diagrama

estructurado como orientado a objetos como
represetacin grfica del representacin grfica
sistema. del sistema.
Consta de 5 Fases Consta de 4 Fases
(Anlisis, Diseo, (Anlisis, Diseo,
Codificacin, Pruebas e Evolucin y
Integracin). Modificacin).

No enfoca Une a los usuarios y a los

apropiadamente el diseadores. Permite
diseo de familias de proporcionar una
programas. Asume una descripcin completa del
progresin relativa problema, legible y
uniforme de pasos de revisable por las partes
elaboracin. interesadas y verificable
contra la realidad.

No acomoda el tipo de Si estn correctamente

desarrollo evolutivo. No definidas las jerarquas
enfoca los posibles de clase, hacer
modos futuros de modificaciones no es tan
desarrollo de software. costoso como en el caso
de programacin
tradicional. Slo hay que
entrar en la parte de
Evolucin para hacer
modificaciones.

El Diseo inicia una vez El Diseo inicia an antes

que ha culminado la fase de concluir con la etapa
de anlsis de sistema. de anlisis. Se
recomienda analizar un
poco y disear. Esta etapa
debe concluir una vez que
se establecieron claves y
mecanismos
importantes.

En este anlisis se llega Un programa que se usa

solo a la fase de en un ambiente real
integracin y no toma en necesariamente debe
consideracin los cambiar. Los cambios
cambios que ocurren difieren un poco de los
dentro del sistema en el requeridos en evolucin,
proceso de anlisis y pues contemplan la
diseo de sistemas. introduccin de nuevas
funcionalidades no
previstas en el problema
original.

Las herramientas Las herramientas

utilizadas son: utilizadas son: Diagramas
Diagrama de Flujo de de Clases, Diagrama de
Datos, Diagramas de Objetos, Diagramas de
Entidad-Relacin, Mdulos, Diagramas de
Diagrama de Transicin Procesos, Diagramas de
de Estados. Transicin de Estados,
Diagramas de Tiempo.

El anlisis est El anlisis est orientado

orientado a los Procesos a los Objetos.
del sistema.

Requiere traducir el Es una forma de pensar

dominio del problema acerca de un problema en
en una serie de trminos del mundo real
funciones y en vez de en trminos de
subfunciones. El un ordenador. El AOO
analista debe permite analizar mejor el
comprender primero el dominio del problema,
dominio del problema y sin pensar en trminos de
a continuacin implementar el sistema
documentar las en un ordenador. El AOO
funciones y permite pasar
subfunciones que debe directamente el dominio
proporcionar el sistema. del problema al modelo
No existe un mecanismo del sistema.
para comprobar si la
especificacin del
sistema expresa con
exactitud los requisitos
del sistema.

Este enfoque se adapta El concepto OO es ms

bien al uso de sistemas simple y est menos
informticos para relacionado con la
implementar el sistema, informtica que el
 pero no es nuestra concepto de flujo de
forma habitual de datos. Esto permite una
pensar. La mejor comunicacin
comunicacin entre el entre el analista y el
analista y la experto en el dominio del
Organizacin est problema (es decir, el
limitada, por las fases. cliente).

La relacin entre los Los objetos encapsulan

modelos es muy dbil, y tanto atributos como
hay muy poca influencia operaciones. Debido a
de un modelo en otro. esto, el AOO reduce la
En la prctica, los distancia entre el punto
modelos de procesos y de vista de los datos y el
de datos de un mismo punto de vista del
sistema se parecen muy proceso, dejando menos
poco. En muchos casos lugar a inconsistencias o
son visiones disparidades entre ambos
irreconciliables, no del modelos.
mismo sistema, sino de
dos puntos de vista
totalmente diferentes de
organizar la solucin.

Segn el Modelo Orientado a Objetos

James Martn, en su libro enfoque y diseo de un sistema,

Orientado a Objetos, seala que en el mundo orientado a
objetos, el analisis se realiza al estudiar los objetos en un
ambiente y los eventos que interactuan con dichos objetos.
Por tal razon, hace referencia que una herramienta util para
la descripcion de tales eventos son los Diagramas de flujo de
Objetos (DFO), porque permiten mostrar las actividades que
interactuan con otras en un sistema cualquiera. Los DFO a
diferencia de los DFD permiten mostrar no solo la
transferencia de datos, si no tambien representar cualquier
cosa que se transfiera de una actividad a otra; es decir,
indicar los objetos que se producen y las actividades que
producen e intercambian.
 Aplicacin web

Aplicacin web

Aplicacin web. En
la Ingeniera de
software se
denomina aplicacin
web a aquellas
aplicaciones que los
usuarios pueden
utilizar accediendo a
un Servidor web a
travs de Internet o
de una intranet
mediante un Concepto Aplicaciones que los usuarios pueden
navegador. En otras : utilizar accediendo a un Servidor web a
palabras, es una travs de Internet o de una intranet
aplicacin mediante un navegador.
(Software) que se
codifica en un lenguaje soportado por los navegadores web en la que se
confa la ejecucin al navegador.
Las aplicaciones web son populares debido a lo prctico del navegador web
como Cliente ligero, a la independencia del Sistema operativo, as como a la
facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar
software a miles de usuarios potenciales.

Es importante mencionar que una Pgina Web puede contener elementos

que permiten una comunicacin activa entre el usuario y la informacin. Esto
permite que el usuario acceda a los datos de modo interactivo, gracias a que
la pgina responder a cada una de sus acciones, como por ejemplo rellenar
y enviar formularios, participar en juegos diversos y acceder a gestores de
base de datos de todo tipo.

Contenido
[ocultar]

1 Historia
 2 Interfaz

3 Consideraciones tcnicas

4 Estructura de las aplicaciones web

5 Uso empresarial

6 Ventajas y desventajas

o 6.1 Ventajas

o 6.2 Desventajas

7 Diferencia entre aplicacin web y aplicacin de internet enriquecida

(RIA)

8 Lenguajes de programacin

9 Fuentes

Historia
En un principio la Web era sencillamente una coleccin de pginas estticas,
documentos, etc., para su consulta o descarga. El paso inmediatamente
posterior en su evolucin fue la inclusin de un mtodo para elaborar pginas
dinmicas que permitieran que lo mostrado tuviese carcter dinmico (es
decir, generado a partir de los datos de la peticin). Este mtodo fue
conocido como CGI ("Common Gateway Interface") y defina un mecanismo
mediante el que se poda pasar informacin entre el servidor y ciertos
programas externos.

Los CGIs siguen utilizndose ampliamente; la mayora de los servidores web

permiten su uso debido a su sencillez. Adems, dan total libertad para elegir
el lenguaje de programacin que se desea emplear.

El funcionamiento de los CGIs tena un punto dbil: cada vez que se reciba
una peticin, el servidor deba lanzar un proceso para ejecutar el programa
CGI. Como la mayora de CGIs estaban escritos en lenguajes interpretados,
como Perl o Python, o en lenguajes que requeran "run-time environment",
como Java o VisualBasic, el servidor se vea sometido a una gran carga. La
concurrencia de mltiples accesos al CGI poda comportar problemas graves.

Por eso se empiezan a desarrollar alternativas a los CGIs que solucionaran el

problema del rendimiento. Las soluciones llegan bsicamente por 2 vas: 1)
se disean sistemas de ejecucin de mdulos mejor integrados con el
servidor, que evitan la instanciacin y ejecucin de varios progrmas, y 2) se
dota a los servidores un intrprete de algn lenguaje de programacin que
permita incluir el cdigo en las pginas de forma que lo ejecute el servidor,
reduciendo el intervalo de respuesta.

Entonces se experimenta un aumento del nmero de arquitecturas y

lenguajes que permiten desarrollar aplicaciones web. Todas siguen alguna de
estas vas. Las ms tiles y las ms utilizadas son las que permiten mezclar
los 2 sistemas: un lenguaje integrado que permita al servidor interpretar
comandos "incrustados" en las pginas HTML y, adems, un sistema de
ejecucin de programas mejor enlazado con el servidor, que no implique los
problemas de rendimiento propios de los CGIs.

Una de las ms potentes es la seguida por Sun Microsystems con su Java,

integrado por 2 componentes; un lenguaje que permite la incrustacin de
cdigo en las pginas HTML que el servidor convierte en programas
ejecutables, JSP ("Java Server Pages" o "Pginas de Servidor de Java"), y
un mtodo de programacin muy ligado al servidor, con un rendimiento
superior a los CGIs, denominado "Java Servlet".

Otra tecnologa de xito y una de las ms utilizadas es el lenguaje PHP. Se

trata de un lenguaje interpretado que permite la incrustacin de HTML en los
programas, con una sintaxis derivada de C y Perl. El hecho de ser sencillo y
potente ha contribuido a hacer de PHP una herramienta muy apropiada para
determinados desarrollos.

Existen otros mtodos, a menudo vinculados a un Servidor web concreto,

como mod_perl para Apache o RXML para Roxen.

Interfaz
Las interfaces web tienen ciertas limitaciones en las funcionalidades que se
ofrecen al usuario. Hay funcionalidades comunes en las aplicaciones de
escritorio como dibujar en la pantalla o arrastrar-y-soltar que no estn
soportadas por las tecnologas web estndar.

Los desarrolladores web generalmente utilizan lenguajes interpretados

( script) en el lado del cliente para aadir ms funcionalidades, especialmente
para ofrecer una experiencia interactiva que no requiera recargar la pgina
cada vez (lo que suele resultar molesto a los usuarios). Recientemente se
han desarrollado tecnologas para coordinar estos lenguajes con las
tecnologas en el lado del servidor. Como ejemplo, AJAXes una tcnica de
desarrollo web que usa una combinacin de varias tecnologas.

Consideraciones tcnicas
Una ventaja significativa es que las aplicaciones web deberan funcionar
igual independientemente de la versin del sistema operativo instalado en el
cliente. En vez de crear clientes para Windows, Mac OS X, GNU/Linux y
otros sistemas operativos, la aplicacin web se escribe una vez y se ejecuta
igual en todas partes. Sin embargo, hay aplicaciones inconsistentes escritas
con HTML, CSS, DOM y otras especificaciones estndar para navegadores
web que pueden causar problemas en el desarrollo y soporte de estas
aplicaciones, principalmente debido a la falta de adiccin de los navegadores
a dichos estndares web (especialmente versiones de Internet
Explorer anteriores a la 7.0). Adicionalmente, la posibilidad de los usuarios de
personalizar muchas de las caractersticas de la interfaz (tamao y color de
fuentes, tipos de fuentes, inhabilitar Javascript) puede interferir con la
consistencia de la aplicacin web.

Otra aproximacin es utilizar Adobe Flash Player o Java applets para

desarrollar parte o toda la interfaz de usuario. Como casi todos los
navegadores incluyen soporte para estas tecnologas (usualmente por medio
de plug-ins), las aplicaciones basadas en Flash o Java pueden ser
implementadas con aproximadamente la misma facilidad. Dado que ignoran
las configuraciones de los navegadores, estas tecnologas permiten ms
control sobre la interfaz, aunque las incompatibilidades entre
implementaciones Flash o Java puedan crear nuevas complicaciones, debido
a que no son estndares. Por las similitudes con una arquitectura cliente-
servidor, con un cliente "no ligero", existen discrepancias sobre el hecho de
llamar a estos sistemas aplicaciones web; un trmino alternativo es
Aplicacin Enriquecida de Internet.

Estructura de las aplicaciones web

Aunque existen muchas variaciones posibles, una aplicacin web est
normalmente estructurada como una aplicacin de tres-capas. En su forma
ms comn, el navegador web ofrece la primera capa y un motor capaz de
usar alguna tecnologa web dinmica (ejemplo: PHP, Java
Servlets o ASP, ASP.NET, CGI, ColdFusion, embPerl,Pitn (programming
language) o Ruby on Rails) constituye la capa de enmedio. Por ltimo, una
base de datos constituye la tercera y ltima capa. El navegador web manda
peticiones a la capa de enmedio que ofrece servicios valindose de
consultas y actualizaciones a la base de datos y a su vez proporciona una
interfaz de usuario.

Uso empresarial
Una estrategia que est emergiendo para las empresas proveedoras de
software consiste en proveer acceso va web al software. Para aplicaciones
previamente distribuidas, como las aplicaciones de escritorio, se puede optar
por desarrollar una aplicacin totalmente nueva o simplemente por adaptar la
aplicacin para ser usada con una interfaz web. Estos ltimos programas
permiten al usuario pagar una cuota mensual o anual para usar la aplicacin,
sin necesidad de instalarla en el ordenador del usuario.

A esta estrategia de uso se la denomina Software como servicio y a las

compaas desarrolladoras se les denomina Proveedores de Aplicaciones de
Servicio (ASP por sus siglas en ingls), un modelo de negocio que est
atrayendo la atencin de la industria del software.

Ventajas y desventajas
Ventajas
 Ahorra tiempo: Se pueden realizar tareas sencillas sin necesidad de
descargar ni instalar ningn programa.

No hay problemas de compatibilidad: Basta tener un navegador

actualizado para poder utilizarlas.

No ocupan espacio en nuestro disco duro.

Actualizaciones inmediatas: Como el software lo gestiona el propio

desarrollador, cuando nos conectanos estamos usando siempre la ltima
versin que haya lanzado.

Consumo de recursos bajo: Dado que toda (o gran parte) de la

aplicacin no se encuentra en nuestro ordenador, muchas de las tareas
que realiza el software no consumen recursos nuestros porque se
realizan desde otro ordenador.

Multiplataforma: Se pueden usar desde cualquier sistema operativo

porque slo es necesario tener un navegador.

Portables: Es independiente del ordenador donde se utilice (un PC de

sobremesa, un porttil...) porque se accede a travs de una pgina web
(slo es necesario disponer de acceso a Internet). La reciente tendencia
al acceso a las aplicaciones web a travs de telfonos mviles requiere
sin embargo un diseo especfico de los ficheros CSS para no dificultar el
acceso de estos usuarios.

La disponibilidad suele ser alta porque el servicio se ofrece desde

mltiples localizaciones para asegurar la continuidad del mismo.

Los virus no daan los datos porque stos estn guardados en el

servidor de la aplicacin.

Colaboracin: Gracias a que el acceso al servicio se realiza desde una

nica ubicacin es sencillo el acceso y comparticin de datos por parte
de varios usuarios. Tiene mucho sentido, por ejemplo, en aplicaciones
online de calendarios u oficina.
 Los navegadores ofrecen cada vez ms y mejores funcionalidades
para crear aplicaciones web ricas (RIAs).

Desventajas

Habitualmente ofrecen menos funcionalidades que las aplicaciones de

escritorio. Se debe a que las funcionalidades que se pueden realizar
desde un navegador son ms limitadas que las que se pueden realizar
desde el sistema operativo. Pero cada vez los navegadores estn ms
preparados para mejorar en este aspecto. La aparicin de HTML 5
representa un hito en este sentido. Es posible aadir funcionalidades a
estas aplicaciones gracias al uso de Aplicaciones de Internet Ricas.

La disponibilidad depende de un tercero, el proveedor de la conexin a

internet o el que provee el enlace entre el servidor de la aplicacin y el
cliente. As que la disponibilidad del servicio est supeditada al
proveedor.

Diferencia entre aplicacin web y aplicacin de

internet enriquecida (RIA)
Las aplicaciones web se ejecutan nativamente desde el navegador. Pero
existen algunas aplicaciones que funcionan desde el navegador pero adems
requieren la instalacin de un software en el ordenador para poder utilizarse.
Estas aplicaciones se denominan Aplicaciones de Internet Ricas. El motivo
de usar este software adicional es que hay muchas funcionalidades que los
navegadores no pueden ofrecer, y l enriquece a las aplicaciones web
ofreciendo dichas funcionalidades. . Ejemplos de funcionalidades que
pueden ofrecer los programas online gracias al uso de software instalado:

Procesamiento de imgenes

Captura de imgenes

Uso de Webcam Captura de video[1]

Lenguajes de programacin
Existen numerosos lenguajes de programacin empleados para el desarrollo
de aplicaciones web en el servidor, entre los que destacan:

PHP

Java, con sus tecnologas Java Servlets y JavaServer Pages (JSP)

Javascript

Perl

Ruby

Python

HTML

XML

ASP/ASP.NET, aunque no es un lenguaje de programacin en s

mismo, sino una arquitectura de desarrollo web en la que se pueden usar
por debajo distintos lenguajes (por ejemplo VB.NET o C# para ASP.NET
o VBScript/JScript para ASP).

Se utilizan para servir los datos adecuados a las necesidades del usuario, en
funcin de como hayan sido definidos por el dueo de la aplicacin. Los
datos se almacenan en alguna base de datos estndar.
Lenguaje unificado de modelado
Collage de diagramas UML.

El lenguaje unificado de modelado (UML, por sus siglas en ingls, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software ms conocido y
utilizado en la actualidad; est respaldado por el Object Management Group (OMG).
Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema.
UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos, funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programacin, esquemas de bases de
datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para
describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje
en el que est descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte
a una metodologa de desarrollo de software (tal como el Proceso Unificado
Racional, Rational Unified Process o RUP), pero no especifica en s mismo qu
metodologa o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de
una utilizacin en un requerimiento. Mientras que programacin estructurada es una
forma de programar como lo es la orientacin a objetos, la programacin orientada a
objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML
solo para lenguajes orientados a objetos.
 UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de
las entidades representadas.

ndice
[ocultar]

1Estandarizacin de UML

2Historia

o 2.1Antes de UML 1.x

o 2.2UML 1.x

o 2.3UML 2.x

3Tipos de diagramas en UML 2.5

o 3.1Estructurales

o 3.2De comportamiento

3.2.1De interaccin

4Vase tambin

5Referencias

6Enlaces externos

Estandarizacin de UML[editar]
Desde el ao 2005, UML es un estndar aprobado por la ISO como
ISO/IEC 19501:2005 Information technology Open Distributed Processing Unified
Modeling Language (UML) Versin 1.4.2.
En el ao 2012 se actualiz la norma a la ltima versin definitiva disponible en ese
momento, la 2.4.1, dando lugar a las normas ISO/IEC 19505-1 e ISO/IEC 19505-2.

Historia[editar]
Antes de UML 1.x[editar]
Despus de que la Rational Software Corporation contratara a James Rumbaugh
de General Electric, en 1994, la compaa se convirti en la fuente de los dos esquemas
de modelado orientado a objetos ms populares de la poca: Object-Modeling
Technique (OMT) de Rumbaugh, que era mejor para anlisis orientado a objetos, y el
Mtodo Booch (de Grady Booch) que era mejor para el diseo orientado a objetos. Poco
despus se les uni Ivar Jacobson, el creador del mtodo de ingeniera de software
orientado a objetos. Jacobson se uni a Rational, en 1995, despus de que su
compaa Objectory AB fuera comprada por Rational. Los tres metodologistas eran
conocidos como los Tres Amigos, porque se saba de sus constantes discusiones sobre
las prcticas metodolgicas.
En 1996 Rational concluy que la abundancia de lenguajes de modelado estaba
alentando la adopcin de la tecnologa de objetos, y para orientarse hacia un mtodo
unificado, encargaron a los Tres Amigos que desarrollaran un "lenguaje unificado de
modelado" abierto. Se consult con representantes de compaas competidoras en el
rea de la tecnologa de objetos durante la OOPSLA '96; eligieron "cajas" para
representar clases en lugar de la notacin de Booch que utilizaba smbolos de "nubes".
Bajo la direccin tcnica de los Tres Amigos (Rumbaugh, Jacobson y Booch) fue
organizado un consorcio internacional llamado UML Partners en 1996 para completar
las especificaciones del UML, y para proponerlo como una respuesta al OMG RFP. El
borrador de la especificacin UML 1.0 de UML Partners fue propuesto a la OMG
en enero de 1997. Durante el mismo mes, la UML Partners form una Fuerza de Tarea
Semntica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las
semnticas de la especificacin y para integrarla con otros esfuerzos de
estandarizacin. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG
en agosto de 1997 y adoptado por la OMG en noviembre de 1997.
UML 1.x[editar]
Como notacin de modelado, la influencia de la OMT domina UML (por ejemplo, el uso
de rectngulos para clases y objetos). Aunque se quit la notacin de "nubes" de Booch,
s se adopt la capacidad de Booch para especificar detalles de diseo en los niveles
inferiores. La notacin de "Casos de Uso" del Objectory y la notacin de componentes
de Booch fueron integrados al resto de la notacin, pero la integracin semntica era
relativamente dbil en UML 1.1, y no se arregl realmente hasta la revisin mayor de
UML 2.0.
Conceptos de muchos otros mtodos orientados a objetos (MOO) fueron integrados
superficialmente en UML con el propsito de hacerlo compatible con todos los MOO.
Adems, el grupo tom en cuenta muchos otros mtodos de la poca, con el objetivo de
asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como
resultado, UML es til en una gran variedad de problemas de ingeniera, desde procesos
sencillos y aplicaciones de solamente un usuario a sistemas concurrentes y distribuidos.
UML 2.x[editar]
UML ha madurado considerablemente desde UML 1.1, varias revisiones menores (UML
1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versin de UML. A estas le
ha seguido la revisin mayor UML 2.0 que fue adoptada por el OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificacin formal, las versiones 2.1.1
y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue
lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de
2011. UML 2.5 fue lanzado en octubre de 2012 como una versin "En proceso" que fue
formalmente liberada en junio de 2015.

Tipos de diagramas en UML 2.5[editar]

Estructurales[editar]
Muestran la estructura esttica de los objetos en un sistema.

Diagrama de clases Los diagramas de clase son, sin duda, el tipo de diagrama
UML ms utilizado. Es el bloque de construccin principal de cualquier solucin
orientada a objetos. Muestra las clases en un sistema, atributos y operaciones de
cada clase y la relacin entre cada clase. En la mayora de las herramientas de
modelado, una clase tiene tres partes, nombre en la parte superior, atributos en el
centro y operaciones o mtodos en la parte inferior. En sistemas grandes con
muchas clases relacionadas, las clases se agrupan para crear diagramas de clases.
Las Diferentes relaciones entre las clases se muestran por diferentes tipos de
flechas.

Diagrama de componentes Un diagrama de componentes muestra la relacin

estructural de los componentes de un sistema de software. Estos se utilizan
principalmente cuando se trabaja con sistemas complejos que tienen muchos
componentes. Los componentes se comunican entre s mediante interfaces. Las
interfaces se enlazan mediante conectores.

Diagrama de despliegue Un diagrama de despliegue muestra el hardware de su

sistema y el software de ese hardware. Los diagramas de implementacin son tiles
cuando la solucin de software se despliega en varios equipos, cada uno con una
configuracin nica.

Diagrama de objetos Los diagramas de objetos, a veces denominados

diagramas de instancia, son muy similares a los diagramas de clases. Al igual que
los diagramas de clases, tambin muestran la relacin entre los objetos, pero usan
ejemplos del mundo real. Se utilizan para mostrar cmo se ver un sistema en un
momento dado. Debido a que hay datos disponibles en los objetos, a menudo se
utilizan para explicar relaciones complejas entre objetos.

Diagrama de paquetes Como su nombre indica, un diagrama de paquetes

muestra las dependencias entre diferentes paquetes de un sistema.

Diagrama de perfiles El diagrama de perfil es un nuevo tipo de diagrama

introducido en UML 2. Este es un tipo de diagrama que se utiliza muy raramente en
cualquier especificacin.

Diagrama de estructura compuesta Los diagramas de estructura compuesta se

utilizan para mostrar la estructura interna de una clase.
De comportamiento[editar]
Muestran el comportamiento dinmico de los objetos en el sistema.

Diagrama de actividades Los diagramas de actividad representan los flujos de

trabajo de forma grfica. Pueden utilizarse para describir el flujo de trabajo
empresarial o el flujo de trabajo operativo de cualquier componente de un sistema. A
veces, los diagramas de actividad se utilizan como una alternativa a los diagramas
de mquina del estado.
 Diagrama de casos de uso Como el tipo de diagrama de diagramas UML ms
conocido, los diagramas de casos de uso ofrecen una visin general de los actores
involucrados en un sistema, las diferentes funciones que necesitan esos actores y
cmo interactan estas diferentes funciones. Es un gran punto de partida para
cualquier discusin del proyecto, ya que se pueden identificar fcilmente los
principales actores involucrados y los principales procesos del sistema.

Diagrama de mquina de estados Los diagramas de mquina de estado son

similares a los diagramas de actividad, aunque las anotaciones y el uso cambian un
poco. En algn momento se conocen como diagramas de estados o diagramas de
diagramas de estado tambin. Estos son muy tiles para describir el
comportamiento de los objetos que actan de manera diferente de acuerdo con el
estado en que se encuentran en el momento.
De interaccin[editar]

Diagrama global de interacciones Los diagramas generales o globales de

interaccin son muy similares a los diagramas de actividad. Mientras que los
diagramas de actividad muestran una secuencia de procesos, los diagramas de
interaccin muestran una secuencia de diagramas de interaccin. En trminos
simples, pueden llamarse una coleccin de diagramas de interaccin y el orden en
que suceden. Como se mencion anteriormente, hay siete tipos de diagramas de
interaccin, por lo que cualquiera de ellos puede ser un nodo en un diagrama de
vista general de interaccin.

Diagrama de comunicacin El diagrama de comunicacin se llam diagrama de

colaboracin en UML 1. Es similar a los diagramas de secuencia, pero el foco est
en los mensajes pasados entre objetos.

Diagrama de secuencia Los diagramas de secuencia en UML muestran cmo

los objetos interactan entre s y el orden en que se producen esas interacciones.
Es importante tener en cuenta que muestran las interacciones para un escenario en
particular. Los procesos se representan verticalmente y las interacciones se
muestran como flechas.

Diagrama de tiempos Los diagramas de sincronizacin son muy similares a los

diagramas de secuencia. Representan el comportamiento de los objetos en un
marco de tiempo dado. Si es solo un objeto, el diagrama es directo, pero si hay ms
de un objeto involucrado, tambin se pueden usar para mostrar interacciones de
objetos durante ese perodo de tiempo.
modelo espiral

DEFINICION
El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de
proceso de software evolutivo donde se conjuga la naturaleza de construccin de prototipos
con los aspectos controlados y sistemticos del MODELO LINEAL y SECUENCIAL.
Proporciona el potencial para el desarrollo rpido de versiones incrementales del software
que no se basa en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.

Durante las primeras iteraciones la versin incremental podra ser un modelo en papel o un
prototipo, durante las ltimas iteraciones se producen versiones cada vez ms completas del
sistema diseado.

EL modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin

llamadas REGIONES DE TAREAS , Cada una de las regiones estn compuestas por un
conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las
caractersticas del proyecto que va a emprenderse en todos los casos se aplican actividades
de proteccin.
Determinar o fijar objetivos

Se identifican objetivos especficos para la fase.

Fijar los productos definidos a obtener: requerimientos, especificaciones,

manual de

Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.

Hay una cosa que solo se hace una vez: planificacin inicial o previa.

Anlisis del riesgo

Riesgos son identificados y se realizan riesgos clave.

e estudian todos los riesgos potenciales y se seleccionan una o varias

alternativas propuestas para reducir o eliminar los riesgos.

Desarrollo, verificar y validar

Se escoge un modelo de desarrollo para el sistema que puede ser cualquiera de

los modelos genricos.

Tareas de la actividad propia se prueban.

Planificar

Se revisa el proyecto y se planifica la siguiente fase de la espiral.

Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con

las fases siguientes y planificamos la prxima actividad.
HISTORIA
El creador del modelo en espiral fue Barry Boehm quien recibi su grado de B.A. de Harvard
en 1957, y sus grados de M.S. y de Ph.D. de UCLA en 1961 y 1964, todo en matemticas.
Barry Boehm era un Programador-Analista en General Dynamics entre 1955 y 1959, sus
intereses actuales de la investigacin incluyen modelar de proceso del software, ingeniera
de requisitos del software, las arquitecturas del software, mtrica del software y los modelos
del coste, los ambientes de la tecnologa de dotacin lgica, y tecnologa de dotacin lgica
basada en el conocimiento. Sus contribuciones al campo incluyen el modelo constructivo del
coste (COCOMO), el modelo espiral del proceso del software, el acercamiento de la teora W
(ganar-gane) a la determinacin de la gerencia y de los requisitos del software y a dos
ambientes avanzados de la tecnologa de dotacin lgica: el sistema y el quntum de la
productividad del software de TRW saltan el ambiente.

TIPOS
El modelo espiral tuvo varias modificaciones que son:

Modelo Original de Boehm.

Modelo Tipico de Seis Regiones.

Modelo WINWIN.

MODELO ORIGINAL DE BOEHM

No hay un nmero definido de iteraciones. Las iteraciones debe decidirlas el equipo de
gestin de proyecto

Cada vuelta se divide en 4 sectores:

Planeacin : determinacin de los objetivos, alternativas y restricciones

Anlisis de riesgo : anlisis de alternativas e identificacin/resolucin de riesgos

Ingeniera : desarrollo del producto hasta "el siguiente nivel".

Evaluacin : valoracin por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteracin su amplitud radial, indica que cada
vez se van construyendo versiones sucesivas del software, cada vez ms completas.

Uno de los puntos ms interesantes del modelo, es la introduccin al proceso de desarrollo a

las actividades de anlisis de los riesgos asociados al desarrollo y a la evaluacin por parte
del cliente de los resultados del software.
MODELO TIPICO DE SEIS REGIONES
A diferencia del modelo de proceso clsico que termina cuando se entrega el software, el
modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora. Una visin alternativa del modelo en espiral puede ser considerada
examinando el eje de punto de entrada en el proyecto.

Las regiones de tareas que componen este modelo son:

Comunicacin con el cliente: las tareas requeridas para establecer comunicacin

entre el desarrollador y el cliente.

Planificacin: las tareas requeridas para definir recursos, el tiempo y otras

informaciones relacionadas con el proyecto. Son todos los requerimientos.

Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras
informaciones relacionadas con el proyecto.

Ingeniera: las tareas requeridas para construir una o ms representaciones de la

aplicacin.

Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario.
 Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente
segn la evaluacin de las representaciones del software creadas durante la etapa
de ingeniera e implementacin durante la etapa de instalacin.

MODELO WINWIN
El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociacin
al principio de casa paso alrededor de la espiral. Ms que una simple actividad de
comunicacin con el cliente se definen las siguientes actividades:

Identificacin del sistema o subsistemas clave de los directivos.

Determinacin de las condiciones de victoria de los directivos.

Negociacin de las condiciones de victoria de los directivos para reunirlas en un

conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto
de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin
que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos
de decisin antes de continuar el proyecto de software.
VENTAJAS

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software

de computadora.

Como el software evoluciona a medida que progresa el proceso, el desarrollador y el

cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele
evolutivos.

El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin

de prototipos en cualquier etapa de evolucin del producto.

El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en

todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos
antes de que se conviertan en problemas.

En la utilizacin de grandes sistemas a doblado la productividad.

DESVENTAJAS

Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es

controlable.

Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas.

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificacin de riesgos

 Modelo cascada

Tambin llamado "modelo clsico", "modelo tradicional" o "modelo lineal

secuencial", tiene su origen en el "Modelo de cascada" ingeniado por
Winston Royce, aunque omite los muchos bucles de este ltimo. El Modelo
Lineal Secuencial sugiere un enfoque sistemtico o ms bien secuencial del
desarrollo de software que comienza en un nivel de sistemas y progresa con
el anlisis, diseo, codificacin, pruebas y mantenimiento.

El modelo en cascada puro difcilmente se utilice tal cual, pues esto implicara un previo y
absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas
subsiguientes libres de errores; ello slo podra ser aplicable a escasos y pequeos
desarrollos de sistemas. En estas circunstancias, el paso de una etapa a otra de las
mencionadas sera sin retorno, por ejemplo pasar del Diseo a la Codificacin implicara un
diseo exacto y sin errores ni probable modificacin o evolucin: "codifique lo diseado que
no habrn en absoluto variantes ni errores". Esto es utpico; ya que intrnsecamente el
software es de carcter evolutivo, cambiante y difcilmente libre de errores, tanto durante su
desarrollo como durante su vida operativa.

El Modelo Lineal Secuencial acompaa las siguientes actividades:

1. Anlisis de los requerimientos del software:

Es la fase en la cual se renen todos los requisitos que debe cumplir el
software. En esta etapa es fundamental la presencia del cliente
que documenta y repasa dichos requisitos.

2. Diseo:
Es una etapa dirigida hacia la estructura de datos, la arquitectura del
software, las representaciones de la interfaz y el detalle procedimental
(algoritmo). En forma general se hace un esbozo de lo solicitado y se
documenta hacindose parte del software.

3. Generacin del cdigo:

Es la etapa en la cual se traduce el diseo para que sea comprensible por la
mquina. Esta etapa va a depender estrechamente de lo detallado del diseo

4. Pruebas:
 Esta etapa se centra en los procesos lgicos internos del software,
asegurando que todas las sentencias se han comprobado, y en la deteccin
de errores.

5. Mantenimiento:
Debido a que el programa puede tener errores, puede no ser del completo
agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios
en su entorno. Esto quiere decir que no se rehace el programa, sino que
sobre la base de uno ya existente se realizan algunos cambios. El Modelo
Lineal Secuencial es el paradigma de desarrollo de software ms antiguo que
existe, sin embargo esto no ha impedido que se haya creado una
desconfianza alrededor de l basada en los siguientes errores reales:

Los proyectos raramente siguen el paradigma secuencial que propone el

proyecto.

A menudo es difcil que el cliente exponga exactamente todos los requisitos.

El cliente debe tener paciencia.

Los responsables del desarrollo de software siempre se retrasan in

necesariamente. Todo lo anteriormente expuesto es cierto pero este
paradigma tiene un lugar bien definido e importante en el trabajo de la
Ingeniera de Software aparte de proporcionar una plantilla en la que se
encuentran mtodos para anlisis, diseo, codificacin, pruebas y
mantenimiento. Con todo y sus errores, sigue siendo el paradigma ms
utilizado en el desarrollo del software, siendo mucho mejor que un enfoque al
azar.

Caractersticas del modelo

Primer modelo empleado (Royce, 1970), tambin denominado ciclo de vida

clsico y modelo lineal secuencial.

Consiste en la ejecucin secuencial de una serie de fases que se suceden, lo

que da nombre al modelo.

Cada fase genera documentacin para la siguiente. Esta documentacin

debe ser aprobada.

Una fase no comienza hasta que la anterior ha terminado.

 Requiere disponer de unos requisitos completos y precisos al principiodel
desarrollo.

Se disponga de unos requisitos completos y consistentes alprincipio del desar

rollo.

Sea un proyecto pequeo, en el que el perodo de congelacin de los

requisitos es corto, o un proyecto con unos requisitos bastante estables.

Ventajas

Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto
es mejor que ninguno.

Facilita la gestin del desarrollo.

Desventajas

En general, establecer todos los requisitos al principio del proceso

de desarrolloes un mito inalcanzable, Los usuarios no pueden imaginarse lo
que quieren hasta que no ven un sistema funcionando.

Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado

cambia, todo cambia.

El usuario debe esperar mucho tiempo hasta ver los resultados

Los errores de anlisis y diseo son costosos de eliminar, y se propagan a las

fases siguientes con un efecto conocido como bola de nieve.

Se genera mucho mantenimiento inicial debido al perodo de congelacin de

requisitos y ste recae, en su mayor parte.

Por qu a veces falla el modelo Lineal?

Los proyectos reales raras veces siguen el modelo secuencial que propone el
modelo.
 A menudo es difcil que el cliente exponga explcitamente todos
los requerimientos.

El cliente debe tener paciencia. Un grave error puede ser desastroso

Cada uno de estos errores es real. Sin embargo el paradigma del ciclo devida
clsico tiene lugar definido e importante trabajo de la ingeniera del software.

Modelo de Prototipos

Modelo de
Prototipos. Modelo de Prototipos
Tambin conocido
como desarrollo
con prototipacin o
modelo de
desarrollo evolutivo,
se inicia con la
definicin de los
objetivos globales
para el software,
luego se identifican
los requisitos
conocidos y las
reas del esquema
en donde es necesaria ms definicin. Este modelo se utilizan para dar
al usuario una vista preliminar de parte del software. Este modelo es
bsicamente prueba y error ya que si al usuario no le gusta una parte del
prototipo significa que la prueba fallo por lo cual se debe corregir el error que
se tenga hasta que el usuario quede satisfecho. Adems el prototipo debe
ser construido en poco tiempo, usando los programas adecuados y no se
debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros
podemos iniciar el verdadero desarrollo del software. Pero eso si al construir
el prototipo nos asegura que nuestro software sea de mejor calidad, adems
 de que su interfaz sea de agrado para el usuario. Un prototipo podr ser
construido solo si con el software es posible experimentar.

Contenido
[ocultar]

1 Etapas

2 Cmo se lleva a cabo

3 Ventajas

4 Para que sea efectivo

5 Desventajas

6 Tipos de Modelo de Prototipos

7 Tipos de prototipos

8 Vase tambin

9 Fuentes

Etapas
Recoleccin y refinamiento de requisitos

Modelado, diseo rpido

Construccin del Prototipo

Desarrollo, evaluacin del prototipo por el cliente

Refinamiento del prototipo

Producto de Ingeniera
Cmo se lleva a cabo
Se comienza elaborando un prototipo del producto final: qu aspecto tendr,
cmo funcionar. Para muchas interfaces de usuario, este modelo puede
resultar tan simple como unos dibujos con lpiz y papel o tan complejo como
el propio cdigo operativo final. Para interfaces de hardware o estaciones de
trabajo, el modelo puede consistir en maquetas de
espuma, caucho, cartn o cartulina. Cuanto ms prximo se encuentre el
prototipo al producto real, mejor ser la evaluacin, si bien se pueden obtener
magnficos resultados con prototipos de baja fidelidad.

Ventajas
No modifica el flujo del ciclo de vida

Reduce el riesgo de construir productos que no satisfagan las necesidades

de los usuarios

Reduce costo y aumenta la probabilidad de xito

Exige disponer de las herramientas adecuadas

Este modelo es til cuando el cliente conoce los objetivos generales para
el software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida.

Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del

software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de
un sistema operativo o de la forma que debera tomar la interaccin humano-
mquina.

Para que sea efectivo

Debe ser un sistema con el que se pueda experimentar

Debe ser comparaticamente barato(menor que el 10%)

 Debe desarrollarse rapidamente

Enfasis en la interfaz de usuario

Equipo de desarrollo reducido

Herramientas y lenguajes adecuadas

Desventajas
Debido a que el usuario ve que el prototipo funciona piensa que este es el
producto terminado y no entienden que recin se va a desarrollar el software.

El desarrolador puede caer en la tentacin de ampliar el prototipo para

construir el sistema final sin tener en cuenta los compromisos de calidad y
mantenimiento que tiene con el cliente

Tipos de Modelo de Prototipos

Modelo de Prototipos rpido: Metodologa de diseo que desarrolla
rpidamente nuevos diseos, los evala y prescinde del prototipo cuando el
prximo diseo es desarrollado mediante un nuevo prototipo.

Modelo de Prototipos reutilizable: Tambin conocido como "Evolutionary

Prototyping"; no se pierde el esfuerzo efectuado en la construccin del prototipo
pues sus partes o el conjunto pueden ser utilizados para construir el producto
real. Mayormente es utilizado en el desarrollo de software, si bien determinados
productos de hardware pueden hacer uso del prototipo como la base del diseo
de moldes en la fabricacincon plsticos o en el diseo de carroceras de
automviles.

Modelo de Prototipos Modular: Tambin conocido como Prototipado

Incremental (Incremental prototyping); se aaden nuevos elementos sobre el
prototipo a medida que el ciclo de diseo progresa.

Modelo de Prototipos Horizontal: El prototipo cubre un amplio nmero de

aspectos y funciones pero la mayora no son operativas. Resulta muy til para
evaluar el alcance del producto, pero no su uso real.
 Modelo de Prototipos Vertical: El prototipo cubre slo un pequeo nmero de
funciones operativas. Resulta muy til para evaluar el uso real sobre una
pequea parte del producto.

Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel

y lpiz, emulando la funcin 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 ms cercana posible al diseo real en trminos de aspecto, impresiones,
interaccin y tiempo.

Tipos de prototipos
Hay dos clases de prototipos el desechable y el evolucionario.

El desechable: nos sirve para eliminar dudas sobre lo que realmente quiere
el cliente adems para desarrollar la interfaz que ms le convenga al cliente.

El evolucionario: es un modelo parcialmente construido que puede pasar de

ser prototipo a ser software pero no tiene una buena documentacin y calidad.

Modelo Incremental

Introduccin:

El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el enfoque
incremental de desarrollocomo una forma de reducir la repeticin del trabajo en el proceso
de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirirexperiencia con el sistema. Este modelo se conoce tambin bajo las siguientes
denominaciones:
 Mtodo de las comparaciones limitadas sucesivas.

Ciencia de salir del paso.

Mtodo de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofa
interactiva de Construccin de Prototipos. Como se muestra en la Figura 1, el modelo
incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en
el calendario. Cada secuencia lineal produce un incremento del software. El primer
incremento generalmente es un producto esencial denominado ncleo.

En una visin genrica, el proceso se divide en 4 partes:

Anlisis

Diseo

Cdigo

Prueba

Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o
Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos
en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se
repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se
reduce considerablemente.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la

entrega de un producto completamente operacional. Este modelo es particularmente til
cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los
pueden realizar un grupo reducido de personas y en cada incremento se aadir personal,
de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos
tcnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes

partes que al final terminar siendo la solucin completa requerida
por el cliente, pero stas partes no se pueden realizar en cualquier
orden, sino que dependen de lo que el cliente este necesitando con
ms urgencia, de los puntos ms importantes del proyecto, los
requerimientos ms bsicos, difciles y con mayor grado de riesgo,
ya que estos se deben hacer al comienzo, de manera que se
disminuya la dificultad y el riesgo en cada versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que podr ser
entregada al cliente para que ste pueda trabajar en ella y el programador pueda considerar
las recomendaciones que el cliente efecte para hacer mejoras en el producto. Estas nuevas
mejoras debern esperar a ser integradas en la siguiente versin junto con los dems
requerimientos que no fueron tomados en cuenta en la versin anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del

sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio
ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez
entregado un incremento, no se realizan cambios sobre el mismo, sino nicamente
correccin de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es
necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las
funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de requisitos
funcionales y ser el cliente quien se encarga de priorizar que funcionalidades son mas
importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de
incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el
sistema entregar. La asignacin de funcionalidades a los incrementos depende de la
prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el
primer incremento.

Caractersticas:
 Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.

El usuario se involucra mas.

Dificil de evaluar el costo total.

Dificil de aplicar a los sistemas transaccionales que tienden a ser integrados y a

operar como un todo.

Requiere gestores experimentados.

Los errores en los requisitos se detectan tarde.

El resultado puede ser positivo.

Ventajas:

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se

implementa la funcionalidad parcial.

Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana

de partes operativas del software.

El modelo proporciona todas las ventajas del modelo en Cascada realimentado,

reduciendo sus desventajas slo al mbito de cada incremento.

Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.

Desventajas:

El modelo incremental no es recomendable para casos de sistemas de tiempo real,

de alto nivel de seguridad, de procesamiento distribuido y/o de alto ndice de riesgos.

Requiere de mucha planeacin, tanto administrativa como tcnica.

Requiere de metas claras para conocer el estado del proyecto.

El Proceso Unificado de Desarrollo Software (USDP) o simplemente Proceso
Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido
por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El
refinamiento ms conocido y documentado del Proceso Unificado es el Proceso
Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos especficos. De la
misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular
del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos
nombres suelen utilizarse para referirse a un mismo concepto.

El nombre Proceso Unificado se usa para describir el proceso genrico que incluye
aquellos elementos que son comunes a la mayora de los refinamientos existentes.
Tambin permite evitar problemas legales ya que Proceso Unificado de
Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software
Corporation en 2003). El primer libro sobre el tema se denomin, en su versin
espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue
publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos
tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde
entonces los autores que publican libros sobre el tema y que no estn afiliados a
Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen
a Rational favorecen el nombre de Proceso Unificado de Rational.

Caractersticas[editar]
Iterativo e Incremental[editar]
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de
cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de
estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir
varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado
un incremento del producto desarrollado que aade o mejora las funcionalidades del
sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos,
Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en
casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo
largo del proyecto.
Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del
proyecto.

Dirigido por los casos de uso[editar]

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones. La idea es que cada
iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a
travs de las distintas disciplinas: diseo, implementacin, prueba, etc. El proceso
dirigido por casos de uso es el rup. Nota: en UP se est Dirigido por requisitos y
riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

Centrado en la arquitectura[editar]
El Proceso Unificado asume que no existe un modelo nico que cubra todos los
aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la
arquitectura de software de un sistema. La analoga con la construccin es clara,
cuando construyes un edificio existen diversos planos que incluyen los distintos
servicios del mismo: electricidad, fontanera, etc.

Enfocado en los riesgos[editar]

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los
riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada
iteracin, en especial los de la fase de Elaboracin deben ser seleccionados en un
orden que asegure que los riesgos principales son considerados primero.

Lenguaje unificado de modelado[editar]

El Lenguaje Unificado de Modelado (UML, por sus siglas en ingls) no es el sucesor de
la oleada de mtodos de anlisis y diseo orientados a objetos que surgi a finales de la
dcada de los 1980 y principios de la siguiente[cita requerida]. El UML unifica, sobre todo, los
mtodos de Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su alcance ha llegado a
formar parte fundamental de la Ingeniera de Software tras su estandarizacin en 1997
con el OMG (Object Management Group, o Grupo de administracin de objetos).

Por qu analizar y disear?[editar]

En resumidas cuentas, la cuestin fundamental del desarrollo del software es la
escritura del cdigo. Despus de todo, los diagramas son solo imgenes bonitas.
Ningn usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es
software que funcione.
("UML Gota a Gota", Addison Wesley, pg. 7).
Por lo tanto, cuando considere usar UML es importante preguntarse por qu lo har y
cmo le ayudar a usted cuando llegue el momento de escribir el cdigo. No existe una
evidencia emprica adecuada que demuestre si estas tcnicas son buenas o malas; pero
lo que s es cierto es que es de considerable ayuda para las etapas de mantenimiento
en proyectos de mediana/avanzada envergadura. [cita requerida]

Fases[editar]
El Proceso Unificado de desarrollo puede ser dividido en cuatro fases para su
mejor desarrollo. Estas fases ayudando tanto a la elaboracin como a la
resolucin de problemas.
Inicio[editar]
En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se
presenta un modelo, visin, metas, deseos del usuario, plazos, costos y
viabilidad.
Elaboracin[editar]
En esta fase se obtiene la visin refinada del proyecto a realizar, la
implementacin iterativa del ncleo de la aplicacin, la resolucin de riesgos
altos, nuevos requisitos y se ajustan las estimaciones.
Construccin[editar]
Esta abarca la evolucin hasta convertirse en producto listo incluyendo
requisitos mnimos. Aqu se afinan los detalles menores como los diferentes
tipos de casos o los riesgos menores.
Transicin[editar]
En esta fase final, el programa debe estar listo para ser probado, instalado y
utilizado por el cliente sin ningn problema. Una vez finalizada esta fase, se
debe comenzar a pensar en futuras novedades para la misma.
Desde el punto de vista Tcnico: el proyecto est formado por los flujos de
trabajo fundamentales: captura de requerimientos, anlisis, diseo,
implementacin y pruebas.
Tantos el punto de vista Gerencial como el Tcnico concuerdan en: La
iteracin .