1ra Semana

Qu es modelo?
Un modelo es una representacin de un objeto, sistema o idea, de forma
diferente al de la entidad misma. El propsito de los modelos es ayudarnos a
explicar, entender o mejorar un sistema. Un modelo de un objeto puede ser una
rplica exacta de ste o una abstraccin de las propiedades dominantes del
objeto.

El uso de modelos no es algo nuevo. El hombre siempre ha tratado de

representar y expresar ideas y objetos para tratar de entender y manipular su
medio. Un requerimiento bsico para cualquier modelo, es que debe describir
al sistema con suficiente detalle para hacer predicciones vlidas sobre el
comportamiento del sistema. Ms generalmente, las caractersticas del modelo
deben corresponder a algunas caractersticas del sistema modelado. La figura
siguiente muestra el concepto de un modelo de simulacin:

Un modelo se utiliza como ayuda para el pensamiento al organizar y clasificar

conceptos confusos e inconsistentes. Al realizar un anlisis de sistemas, se
crea un modelo del sistema que muestre las entidades, las interrelaciones, etc.
La adecuada construccin de un modelo ayuda a organizar, evaluar y examinar
la validez de pensamientos.

Al explicar ideas o conceptos complejos, los lenguajes verbales a menudo

presentan ambigedades e imprecisiones. Un modelo es la representacin
concisa de una situacin; por eso representa un medio de comunicacin mas
eficiente y efectivo.

Representacin de la realidad por medio de abstracciones. Los modelos

enfocan ciertas partes importantes de un sistema (por lo menos, aquella que le
interesan a un tipo de modelo especfico), restndole importancia a otras.
Los modelos son creados empleando herramientas de modelado.

Que es modelar software

El modelado de sistemas software es una tcnica para tratar con la complejidad
inherente a estos sistemas. El uso de modelos ayuda al ingeniero de software a
"visualizar" el sistema a construir. Adems, los modelos de un nivel de
abstraccin mayor pueden utilizarse para la comunicacin con el cliente. Por
ltimo, las herramientas de modelado y las de Ingeniera de Software
Automatizada. pueden ayudar a verificar la correccin del modelo.

Modelamiento, importancia, caractersticas

Concepto:

1.

Comparacin con otras Formas de Aprendizaje

2.

Efecto del refuerzo

3.

Importancia de las respuestas modeladas

4.

Tipos de Modelamiento

5.

Factores que influyen en el Modelamiento

6.

Retencin

7.

Refuerzo y castigo

8.

Relacin entre el refuerzo vicario y el refuerzo real

9.

Aspectos Especiales del Aprendizaje por Modelamiento

10.

Fuente de informacin

Al Aprendizaje por modelamiento tambin se le llama aprendizaje por observacin, aprendizaje por
imitacin, aprendizaje sin ensayo, aprendizaje vicario, aprendizaje por identificacin y aprendizaje social.
Independientemente del nombre que se le de y del nfasis particular que se haga, la premisa fundamental
del aprendizaje por modelamiento es que una persona o un animal observa el comportamiento de otra (o)
y entonces es capaz de ejecutar en forma parcial o total el comportamiento observado.

Comparacin con otras Formas de Aprendizaje

El Aprendizaje por modelamiento difiere del condicionamiento clsico y del instrumental en varios
aspectos importantes, incluyendo limitaciones propias de la especie, la importancia del refuerzo y la
importancia de la clase de respuesta dadaLimitaciones dadas por la especie
El comportamiento imitativo se limita a algunas especies. Tanto animales como seres humanos, son
capaces de aprendizaje por modelamiento pero en la mayora de los casos slo pueden imitar actividades
que estn dentro del rango de habilidades de su especie y que se adecan a los patrones de
comportamiento de la misma. Existen limitaciones con respecto a los tipos de aprendizaje que el
organismo puede efectuar por condicionamiento clsico e instrumental, pero las limitaciones de los
miembros de una especie con respecto al aprendizaje por imitacin, parecen ser ms rgidas. Unos
cuantos animales, al parecer, aprenden ms por modelamiento que por condicionamiento clsico o
instrumental.

Efecto del refuerzo

El refuerzo parece facilitar el aprendizaje por modelamiento, ms que forzar una respuesta, como en el
condicionamiento clsico o ms que desarrollar relaciones de contingencia, como en el condicionamiento
instrumental. Un a respuesta imitada, con mayor probabilidad, llegar a ser parte de los patrones de
comportamiento, si se ha reforzado. Sin embargo, en el caso de la respuesta imitada, esto parece
deberse ms al hecho de que se ha observado, y no al hecho de que se ha reforzado. En otras palabras,
el refuerzo sirve solamente como una condicin motivante para el aprendizaje por modelamiento.

Importancia de las respuestas modeladas

Para seguridad de muchos aprendices, algunas respuestas se aprenden mejor a travs del
modelamiento. En algunos casos es imposible el forzar una respuesta; y el aprender una respuesta
instrumental por aproximaciones sucesivas (moldeamiento), puede llevar a que el aprendiz, el profesor u
otras personas, corran riesgos irrazonables.
Ejemplo (1) uno
Aprender a disparar una pistola o un rifle puede hacerse por medio de las tcnicas del condicionamiento
clsico o del condicionamiento instrumental. Sin embargo, tales tcnicas pueden llegar a ser perjudiciales,
en el caso del condicionamiento clsico, por ejemplo, la respuesta del aprendiz puede llegar a ser un
disparo involuntario del arma; y en el caso del condicionamiento instrumental, la aproximacin por ensayo
y error a una respuesta apropiada puede demandar mucho tiempo y adems ser insegura. Por el
contrario, el ejemplo seguro y correcto del arma puede darse por modelamiento con mayor acierto y
rapidez.

Tipos de Modelamiento
El modelamiento puede darse en diversas formas, aunque la premisa fundamental es la misma en todos
los casos.
Observacin de un modelo vivo
Quizs la forma ms comn de aprendizaje por modelamiento es la observacin directa de un modelo
vivo que observa el aprendiz. Esto generalmente ocurre en situaciones sociales, e implica a individuos
con quienes el sujeto, tiene frecuentes contactos (tales como padres, maestros o compaeros).

Nota: A una teora del aprendizaje y del desarrollo de la personalidad se le llama teora del aprendizaje
social o TAS. Una consideracin muy importante de dicha teora es la de que la persona puede ser
imitada.
Aprendizaje Vicario
El aprendizaje vicario se presenta cuando un sujeto no solamente es capaz de tomar nota de la respuesta
del modelo, sino tambin de observar las consecuencias de la misma. La respuesta real y el refuerzo o
castigo resultante, se observa junto con los gestos vocales de postura o faciales, los cuales pueden
revelar las reacciones emocionales del modelo. Realmente, el observador no ejecuta la respuesta en si
misma, ni recibe directamente un refuerzo ni un castigo. Sin embargo, la experiencia vicaria sirve para
alertarlo y puede influir en su forma posterior de responder.
Ejemplo (2) dos
Usted puede recordar fcilmente el aprendizaje vicario si alguna vez ha observado a alguien que sufre
una quemadura dolorosa. Supongamos que usted ha visto a un amigo que se apoya en un cocina
elctrica, en la cual se acaba de apagar uno de los fogones. Sin duda, usted vio la desagradable
quemadura que sufri su amigo. Eso fue suficiente para despertar un poco de ansiedad y comprensin; y
usted no necesita apoyarse en la cocina y quemarse para saber que se har dao. Este es un caso de
supresin vicaria de una respuesta. Otras situaciones que impliquen refuerzo positivo para el modelo
pueden llevar al facilitamiento vicario de una respuesta.
Aprendizaje simblico modelamiento verbal
Algunas formas de modelamiento dependen de representaciones verbales de un comportamiento, ms
que de la observacin de un comportamiento real. Por encima de cualquier otra caracterstica esta
habilidad distingue a los seres humanos de otras especies y hace que su rango de posibilidades sea ms
amplio. Actividades que se representen mediante cdigos verbales se pueden retener (almacenar) para
usarlas posteriormente, como orientaciones para las imitaciones de respuestas apropiadas, pueden
reducir considerablemente el tiempo y el esfuerzo implicados en el aprendizaje de determinados
conocimientos.
Ejemplo (3) tres
Supongamos que usted ha descubierto un camino ms corto que va de su casa al teatro. Podra, por
medio de una descripcin verbal, representar tal camino a su vecino. As, el vecino podr modelar su
comportamiento, sin que sea necesaria la observacin directa de la "va ms corta". El vecino confa, ms
bien en su secuencia de guas verbales, tales como, "de la izquierda de la Avenida Real, hasta llegar a la
orilla del ro y entonces se cruza a la derecha".
Imitacin pura
Cierto modelamiento implica la imitacin exacta de alguna respuesta. En determinados casos, esto puede
significar que la imitacin se da sin comprensin, es decir, se copia la respuesta, pero el imitador no
reconoce el significado de la misma.
Ejemplo (4) cuatro
A veces la imitacin pura lleva a situaciones humorsticas. Existen muchas ancdotas relacionadas con
los villancicos de navidad que cantan los nios sin aprender las palabras correctas. De modo que cuando
se le escucha con cuidado, los nios pueden estar cantando, por ejemplo, "Junto a la Virgen Jos" o
"Noche de Jazz". Los anteriores son intentos de modelamiento imitativo, pero obviamente sin
comprensin.

Factores que influyen en el Modelamiento

El hecho de que alguien observe un comportamiento determinado, no significa que se tenga que dar el
modelamiento. Diversos factores influyen en el hecho de que se de o no el aprendizaje por modelamiento,
Atencin
El factor especfico, ms importante en el aprendizaje por modelamiento es la atencin. Es necesario que
el observador atienda al comportamiento que muestra el modelo. La falta de atencin puede dar como
resultado un modelamiento parcial o incorrecto, o que no se de realmente el aprendizaje. A su vez, la
atencin puede estar afectada por muchos factores, como aquellos que influyen en la percepcin.
Proximidad
Para que se presente el aprendizaje por observacin, la atencin debe dirigirse hacia un modelo. Por lo
general, el observador elegir ms probablemente como modelo a alguien que est cerca, en lugar de
otros parientes cercanos y amigos ntimos, son mucho ms susceptibles de ser elegidos
como modelos que gentes extraas. (Ver sin embargo, el ejemplo 7).
Status de modelo

Las investigaciones han demostrado que los observadores son selectivos en su eleccin de modelos.
Esta selectividad al parecer se basa en el status de modelo, incluyendo caractersticas tales como la
posicin que tenga el mismo, el papel que desempea, el poder o influencia que tenga y la habilidad para
comunicarse.
La evidencia apoya en su mayor parte los hallazgos que indican que los modelos de status elevado
probablemente son ms imitados que los status bajo. Mientras que la determinacin del status puede
variar de acuerdo con el observador, la posicin (tal como padre, maestro o ministro), el rol (tal
como lder o compaero de grupo) o el poder (tal como el derecho de administrar o quitar refuerzos) son
importantes factores relacionados con la direccin de la atencin. Junto con la habilidad del modelo para
comunicarse, dichos factores hacen que el observador se acerque o aparte del modelo.
Ejemplo (5) cinco
Los estudiantes de primeros aos de secundaria, con frecuencia son favorablemente impresionados por
profesores capaces de hablar en su mismo lenguaje y al nivel de los estudiantes, as como de transmitir
bien lo que ensean. A tales profesores s eles reconoce como especiales y son tenidos en alto aprecio
por los alumnos. Si uno de dichos profesores sugiere que cierta clase de comportamientos, tales como
fumar es apropiado, los estudiantes probablemente sigan la sugerencia, si esa misma sugerencia viene
de parte de un profesor con bajo status, los estudiantes posiblemente no la seguirn.
Ejemplo (6) seis
Supongamos que un profesor de los ltimos aos de secundaria vaya a la clase diariamente y comience
su intervencin diciendo: "Nios, ahora". Tal procedimiento puede disminuir el status del profesor a los
ojos de los alumnos. (Los estudiantes de ltimos aos de secundaria no esperan que se les trate como
nios, tendrn fuerte tendencia a desacreditar a un instructor que los trate en tal forma). Es posible que
los "extraos" puedan actuar como modelos, si a travs de los medios de publicidad ocupa cierta
posicin. Los observadores pueden no haberse encontrado personalmente con el modelo, pero si
conferirle un status muy alto.
Ejemplo (7) siete
La televisin ha hecho posible para la mayora de nosotros observar el comportamiento de personas con
habilidades especiales. De esta forma, podemos intentar modelar algunos de nuestros comportamientos
sobre la base del comportamiento de gastrnomos, cantantes o jugadores de tenis, que hemos visto
y odo por televisin.
Es necesario reconocer que el observador es quien otorga status al modelo. Cada observador puede
elegir el modelo en forma diferente de acuerdo con las cualidades que l juzga ms importantes.
Influencia y Poder
Una influencia se define como el hecho de que las actitudes o comportamientos de una persona cambien
debido a otra persona o a un grupo. Se han identificado dos tipos distintos de influencia: influencia
independiente, en la cual se da un cambio porque el mensaje en si mismo es persuasivo e influencia
dependiente, en la cual el cambio se da como resultado de las caractersticas sociales de un modelo o
grupo. El poder se define como una influencia potencial. El status del modelo puede estar
significativamente afectando tanto por la influencia como por el poder que un observador percibe en el
mismo modelo.
Control cognoscitivo
El prrafo anterior implica que la influencia y el poder son eventos externos que pueden tener efectos
importantes en un observador. El control cognoscitivo es el control interno del observador, el cual resulta
del aprendizaje verbal o de otros tipos de aprendizaje que ha tenido.
Ejemplo (8) ocho
La investigacin con respecto a las caractersticas del comportamiento y de personalidad de los asesinos
presidenciales, ha demostrado que casi siempre los asesinos actan, al menos parcialmente, bajo un
engaoso control interno. Voces internas, creencias irracionales y un sentido de "destino heroico" que
llevan al asesino hasta el punto de cometer el crimen. Posteriormente, sus actitudes durante la reclusin,
tienden a resguardarlo de influencias sociales correctivas. Aunque esto puede considerarse un ejemplo
extremo o raro, ilustra ampliamente como el control interno puede superar la influencia o el poder externo.

Retencin
Para que el aprendizaje por modelamiento sea fructfero, el observador debe atender al modelo y retener
el recuerdo del comportamiento del mismo, para emplearlo ms tarde. El observador puede retener una
determinada imagen visual o una representacin verbal del comportamiento del modelo. Como se
mencion previamente, el modelamiento verbal permite presentar a un observador un rango casi ilimitado
de comportamientos del modelo, aun cuando la demostracin de tales actividades no sea posible.

Las imgenes visuales pueden ser muy impactantes y en algunos casos en casi imposible evitar que
lleguen a la memoria consciente; pero el alcance de la retencin y la trasmisin posterior del
comportamiento de un modelo, puede depender del desarrollo del lenguaje del observador.
Ejemplo (9) nueve
Los arquitectos tienen con frecuencia un sentimiento acerca de una determinada construccin, aunque
sean incapaces de expresarlo al cliente. En tal caso, la imagen visual es ms fuerte que la habilidad del
arquitecto para expresarla. Con frecuencia el arquitecto construir un modelo de la estructura poniendo
las imgenes en forma tridimensional, de modo que pueda discutirse posteriormente, revisarse y
mostrarse al cliente. Esto puede darse varias veces durante el desarrollo de los planos, y en algunos
casos permite al cliente aprender a imitar el comportamiento del arquitecto: el cliente, despus de un
tiempo, puede ser capaz de visualizar los cambios en el plano sin estarlos viendo realmente en un modelo
revisado.

Refuerzo y castigo
Como se dijo antes, el refuerzo facilita el aprendizaje por modelamiento, pero no es necesario para que
ste se presente. Lo mismo puede decirse del castigo; puede emplearse para estimular el aprendizaje por
modelamiento, pero no garantiza que dicho aprendizaje se lleve a cabo.
El refuerzo y el castigo pueden afectar al observador a travs del aprendizaje vicario. Los efectos
observados en el comportamiento de otros pueden ser muy importantes y los observadores pueden
desarrollar actitudes de auto - alertamiento o auto - refuerzo, basados en el comportamiento que han visto
en los modelos.
Autoalertamiento
Una persona que observa a otra que ha tenido xito, que ha fracasado o ha sido castigada por
una accin determinada, puede retener una imagen o representacin verbal que recordar ms tarde y le
servir como estmulo motivante.
Ejemplo (10) diez
No se necesita nunca haber hablado ante un gran grupo para sentir temor de hablar en pblico. Sin
embargo, la mayor parte de la gente siente un poco de ansiedad al pensar en tal situacin. Simplemente,
el observar las experiencias de quienes hablan en pblico, es suficiente con frecuencia para originar la
ansiedad.
Autorefuerzo:
Los observadores pueden establecer normas para su propio desempeo con base en aquellas que
parece aceptar el modelo. Puede darse, sin embargo, alguna clase de interaccin: si, por ejemplo, el
modelo es considerado como una persona de bajo status, el observador puede tratar de superarlo; si se le
considera una persona de alto status, el observador puede aceptar normas ms bajas.

Relacin entre el refuerzo vicario y el refuerzo real

El refuerzo vicario a travs del aprendizaje por modelamiento parece ser muy til en muchas situaciones;
para aprender una respuesta nueva, no entrenada antes, sin embargo, es poco probable que el refuerzo
vicario mantenga la respuesta, ya que el aprendiz llega a esperar un refuerzo real.
Ejemplo (11) once
Habiendo observado a un vendedor que emplea una tcnica particular y es recompensado, usted puede
intentar imitarlo. Sin embargo, si sus esfuerzos no son recompensados, usted probablemente no
continuar usando dicha tcnica, aunque contine viendo que la otra persona recibe recompensa.

Aspectos Especiales del Aprendizaje por

Modelamiento
El anlisis del modelamiento en el presente captulo se ha limitado ahora a los casos en los cuales un
observador atiende al comportamiento de un modelo. Sin embargo, puede evidenciarse que despus de
un tiempo, una persona tender a combinar las acciones de diferentes modelos. As pueden surgir estilos
personales de comportamiento, que son diferentes de los de cualquier modelo.
Es muy difcil determinar que tanta influencia de un modelo ha habido en un comportamiento particular.
Aunque el porcentaje de influencia no pueda determinarse, es indiscutible que mltiples factores influyen
en el comportamiento de una persona.
Socializacin y conflicto

El aprendizaje por modelamiento es el origen de muchos comportamientos sociales. Las actitudes y los
comportamientos modelados y reforzados por ciertas culturas y subculturas se adoptan desde temprana
edad y se mantienen con frecuencia a lo largo de la vida.
Una persona que crece en una cultura o subcultura obviamente puede observar comportamientos de
otros y tomarlos como modelos. Esto puede crear conflictos para la persona. La resolucin de
tales conflictos est determinada por la fuerza de los dos comportamientos se adoptar con
mayor probabilidad el ms fuerte o ms valorado de los dos.
Ejemplo (12) doce
Con frecuencia los adolescentes se encuentran en serias situaciones de conflictos. Sus compaeros de
grupo pueden decirles y demostrarles que fumar marihuana es una accin aceptable o deseable. En la
mayora de los casos, los padres le dan un conjunto de normas que entran en conflicto con lo anterior. En
tal situacin, los adolescentes tendern a decidir cual modelo imitar. Dicha eleccin no es fcil,
particularmente porque la ansiedad acerca de un posible rechazo (por parte de sus compaeros de grupo)
puede entrar en conflicto con el castigo (por parte de sus padres).
Inhibicin y Desinhibicin
El aprendizaje por modelamiento se ha empleado para configurar patrones de respuesta ms o menos
probable, usando las actividades de un modelo como gua para el observador. Si el observador ejecuta
alguna respuesta que se considere inapropiada, puede emplearse un modelo que reciba consecuencia
muy negativas o adversivas por tal comportamiento opuesto, u otro que reciba consecuencias positivas
por el comportamiento opuesto. Si el observador no quiere actuar en determinadas circunstancias, puede
emplearse un modelo que acta con consecuencias positivas. El propsito de estas condiciones es tratar
de inhibir aquellas respuestas consideradas inapropiadas, o de disminuir las inhibiciones del observador,
recordando comportamientos que pueden ser apropiados.

Fuente de informacin

Gua de estudio, "Taller de Liderazgo", dictado en la Direccin

de Inteligencia Militar, Venezuela. El 29 de Agosto de 1.991.

Leer ms: http://www.monografias.com/trabajos94/aprendizaje-modelamiento/aprendizajemodelamiento.shtml#ixzz45GwXT39U

Importancia del modelado

El conocimiento sobre las cosas que tenemos a nuestro alrededor, adquirido a
travs de los sentidos y almacenado en el cerebro, no es la realidad sino una
abstraccin, un modelo de la misma. Es un modelo en el que se reflejan
algunas caractersticas estticas (forma, dimensiones, color, sonido, olor,
temperatura, acabado superficial, etc.) y quizs tambin algunas otras
dinmicas (velocidad, etc). Si utilizamos instrumentos de medida, la
informacin que adquirimos puede enriquecerse con nmeros, grficos y
quizs con otros tipos de informacin propia de cada instrumento.
De alguna manera, la informacin que hemos adquirido sobre un objeto es el
resultado de experiencias (experimentos) que hemos realizado sobre el mismo.
Por tanto, la informacin adquirida es siempre parcial, se refiere a los
resultados de experiencias o experimentos y el modelo de cualquier sistema es
tambin parcial, es decir, slo refleja aquellos aspectos que han sido medidos y
analizados dentro de un determinado contexto experimental. Otros aspectos
pueden quedar ocultos en el modelo porque an no se conocen, sencillamente
porque no se han medido o, si se quiere, porque quedan fuera de contexto.

Figura 3.2 : Esquema del modelado

En la figura 3.2 se indica esquemticamente el proceso de obtencin de un

modelo a partir de la realidad. Es importante recalcar que la informacin que
podemos tener sobre una determinada entidad real la adquirimos a travs de
experimentos hechos en un determinado contexto de modelado. Por esta
razn, los nombres con que muchas veces se etiquetan ciertas entidades del
mundo real provienen no de la entidad misma sino de su modelo. As, por
ejemplo, si hablamos de sistemas de tiempo continuo nos estamos refiriendo a
la familia de entidades reales que admiten un modelo de tiempo continuo. Es
decir que lo que estamos haciendo es clasificar las entidades reales en clases
en funcin de las caractersticas de los modelos. Es evidente que una misma
entidad real puede pertenecer a varias de estas clases, o sea, puede admitir
distintos modelos, dependiendo de las caractersticas que se quieran poner de
manifiesto.
Disponer de un modelo antes de proceder al desarrollo de software y hardware
es tan importante para el ingeniero responsable de cualquier automatizacin
industrial como puede ser, para el arquitecto, tener un anteproyecto antes de
construir un gran edificio.

El modelado adquiere mayor importancia cuanto mayor es la complejidad del

sistema. Algunos sistemas (por ejemplo biolgicos) son tan complicados que
hasta hace poco no se saba muy bien cmo funcionaban pero que, tras el
modelado de sus partes elementales y la posterior conexin de las mismas,
empiezan ya a ser estudiados y entendidos, al menos en alguno de sus
aspectos. Sin ir tan lejos, tener un buen modelo resulta de una ayuda
inestimable para cualquier diseo de automatizacin industrial.
Sera estupendo que el lenguaje de modelizacin fuera universal pues ello
facilitar a la comunicacin entre los equipos de desarrollo dentro de la empresa
y tambin, fuera de ella, entre los miembros de la comunidad cientfica.
Un buen lenguaje de modelizacin ha de tener
Elementos del modelo conceptos fundamentales y semnticos
Notacin representacin visual de los elementos del modelo
Directivas lenguajes a utilizar para el modelado
Lenguaje Unificado de Modelizacin (UML)
La carencia de un lenguaje estndar de modelizacin ha sido durante mucho
tiempo el principal quebradero de cabeza de muchos diseadores de software.
La situacin era catica hasta hace poco porque, al ser las herramientas de
desarrollo de software de diferentes fabricantes e incompatibles entre s,
cuando alguien pretenda modelar un sistema complejo, formado por
subsistemas de diferente naturaleza, al final se le presentaba la complicada
tarea de acoplar los resultados de los modelos de cada una de las partes,
desarrolladas en diferentes lenguajes. Afortunadamente la situacin ha
cambiado recientemente con la aparicin del denominado Unified Modeling
Language (UML). El desarrollo de este lenguaje comenz en Octubre de 1994
cuando Grady Booch y Jim Rumbaugh, de la empresa Rational Software
Corporation, unificaron el anterior mtodo de Booch y el llamado tcnica de
Modelado de Objetos (OMT) y crearon un proyecto comn, al que llamaron
Unified Method, cuyo primer borrador vio la luz en Octubre de 1995. A finales
del mismo ano Ivan Jacobson y su empresa Objectory se unieron a Rational
Software y como resultado de la unin surgi el mtodo OOSE (ObjectOriented Software Engineering).
Al comenzar a trabajar juntos, Booch, Rumbaugh y Jacobson fijaron como
objetivos los siguientes:
1. Otorgar al modelado de sistemas (y no solo al software) la capacidad de
utilizar
Conceptos orientados a objetos.
2. Establecer un acoplamiento explcito con los artefactos tanto conceptual
como ejecutable.

3. Tratar los temas inherentes a la escala en los sistemas complejos y de

misin critica.
4. Crear un lenguaje de modelado entendible tanto por las maquinas como por
los seres humanos.
Los esfuerzos de los tres ingenieros dieron su fruto con la publicacin de las
versiones 0.9 y 0.91 de UML, en Junio y en Octubre de 1996. UML comenz a
extenderse con rapidez y muchas importantes empresas vieron en UML un
asunto de importancia estratgica para sus negocios. Tras una primera fusin
con OMG (Object Management Group), Rational Software estableci las bases
para crear un consorcio empresarial, al que pronto se unieron las compaas
ms importantes del mundo de la informtica: DEC, HP, IBM, Microsoft, Oracle,
TI, Unisys, etc.
Ofrecer a los usuarios un lenguaje de modelado de uso inmediato, expresivo y
visual, para desarrollar e intercambiar modelos significativos.
Suministrar mecanismos de extensin y especializacin que permitan
extender
Los conceptos del ncleo del lenguaje.
Soportar especificaciones que sean independientes de los lenguajes de
programacin particulares y de los procesos de desarrollo.
Dar una base formal para el aprendizaje del lenguaje.
Animar el crecimiento del mercado de herramientas para objetos.
Soportar conceptos de desarrollo de alto nivel: components, collaborations,
frameworks, patterns.
Integrar las mejores prcticas de programacin.
Caractersticas de UML
UML es un lenguaje sin propietario y abierto a todos. Ofrece a los ingenieros de
Sistemas que trabajan en anlisis y diseo orientados a objetos, un consistente
lenguaje para especificar, visualizar, construir y documentar los artefactos de
software y tambin para el modelado de negocios y de otros sistemas. Esta
estructurado en 9 paquetes:
Data Types
Core
Extension Mechanisms
Comon Behavior
State Machines
Activity Graphs

 Collaborations
Use Cases
Model Management
Los fabricantes y desarrolladores de software que adoptan el lenguaje UML
deben etiquetar sus productos con la frase UML compliant e indicar el grado de
cumplimiento con cada una de las especificaciones del lenguaje. Para el
desarrollo de los artefactos de software, UML tiene en cuenta las siguientes
consideraciones:
El estudio de todo sistema complejo se aborda mejor por medio de una
secuencia de visiones distintas del modelo. Una sola vista no es suficiente.
Todo modelo se puede expresar a diferentes niveles de fidelidad.
Los mejores modelos estn conectados a la realidad.
En trminos de vistas de un modelo, UML define los siguientes diagramas
grficos:
use case diagram
class diagram
behavior diagrams:
statechart diagram
activity diagram
interaction diagrams
_ sequence diagram
_ collaboration diagram
implementation diagrams:
_ component diagram
_ deployment diagram
Todos estos diagramas dan mltiples perspectivas del sistema bajo anlisis o
desarrollo. Adems UML tiene herramientas para obtener un buen nmero de
visiones derivadas. UML no soporta diagramas de flujo de datos (data-flow
diagrams), simplemente porque no encajan limpiamente en un paradigma
consistente orientado a objeto. Para modelar flujos de datos valen los
diagramas de actividad (activity diagrams) de UML.
UML consigue acabar con las diferencias (a veces absurdas) entre los
lenguajes de modelizacin anteriores y, quizs ms importante, unifica las
perspectivas de acercamiento entre muchas clases diferentes de sistemas
(negocios contra sotware), fases de desarrollo (requerimientos, anlisis, diseo
e implementacin) y conceptos internos.

2da Semana

Proceso de desarrollo de software

Proceso para el desarrollo de software

El Proceso para el desarrollo de software, tambin denominado ciclo de vida del
desarrollo de software es una estructura aplicada al desarrollo de un producto
desoftware. Hay varios modelos a seguir para el establecimiento de un proceso para el
desarrollo de software, cada uno de los cuales describe un enfoque diferente para
diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un
modelo de ciclo de vida un trmino ms general que un determinado proceso para el
desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software
especficos que se ajustan a un modelo de ciclo de vida de espiral.

== Generalidades ==
La gran cantidad de organizaciones de desarrollo de software implementan metodologas
para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria
armamentstica, que en los Estados Unidos necesita un certificado basado en su modelo
de procesos para poder obtener un contrato.
El estndar internacional que regula el mtodo de seleccin, implementacin y monitoreo
del ciclo de vida del software es ISO 12207.
Durante dcadas se ha perseguido la meta de encontrar procesos reproducibles y
predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones
intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar
software. Otros aplican tcnicas de gestin de proyectos para la creacin del software. Sin
una gestin del proyecto, los proyectos de software corren el riesgo de demorarse o
consumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos de
software que no cumplen sus metas en trminos de funcionalidad, costes o tiempo de
entrega, una gestin de proyectos efectiva es algo que a menudo falta.
Algunas organizaciones crean un grupo propio (Software Engineering Process Group,
abreviado SEPG) encargado de mejorar los procesos para el desarrollo de software en la
organizacin.

ndice

1Actividades del desarrollo de software

o

1.1Planificacin

1.2Implementacin, pruebas y documentacin

1.3Despliegue y mantenimiento

2Modelos de Desarrollo de Software

o

2.1Modelo de cascada

2.2Modelo de espiral

2.3Desarrollo iterativo e incremental

2.4Desarrollo gil

2.5Codificacin y correccin

2.6Orientado a la Reutilizacin

3Modelos de mejora de procesos

4Mtodos formales

5Vase tambin

6Referencias

7Enlaces externos

Actividades del desarrollo de software[editar]

Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay

algunos modelos ms para representar este proceso.

Planificacin
La importante tarea a la hora de crear un producto de software es obtener los requisitos o
el anlisis de los requisitos. Los clientes suelen tener una idea ms bien abstracta del
resultado final, pero no sobre las funciones que debera cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un anlisis del
mbito del desarrollo. Este documento se conoce como especificacin funcional.

Implementacin, pruebas y documentacin

La implementacin es parte del proceso en el que los ingenieros de software programan el
cdigo para el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta
parte del proceso tiene la funcin de detectar los errores de software lo antes posible.
La documentacin del diseo interno del software con el objetivo de facilitar su mejora y su
mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentacin de
un API, tanto interior como exterior.

Despliegue y mantenimiento
El despliegue comienza cuando el cdigo ha sido suficientemente probado, ha sido
aprobado para su liberacin y ha sido distribuido en el entorno de produccin.
Entrenamiento y soporte para el software es de suma importancia y algo que muchos
desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio
porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma
adecuada a los futuros usuarios del software.
El mantenimiento o mejora del software de un software con problemas recientemente
desplegado, puede requerir ms tiempo que el desarrollo inicial del software. Es posible
que haya que incorporar cdigo que no se ajusta al diseo original con el objetivo de
solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de
mantenimiento son muy elevados puede que sea oportuno redisear el sistema para poder
contener los costes de mantenimiento.

Modelos de Desarrollo de Software

Los modelos de desarrollo de software son una representacin abstracta de una manera
en particular. Realmente no representa cmo se debe desarrollar el software, sino de un
enfoque comn. Puede ser modificado y adaptado de acuerdo a las necesidades del
software en proceso de desarrollo. 1 Hay varios modelos para perfilar el proceso de

desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debera escoger
el ms apropiado para sus necesidades. En ocasiones puede que una combinacin de
varios modelos sea apropiado. Existen tres paradigmas de los modelos de desarrollo de
software:
1. Paradigma Tradicional:
Es uno de los paradigmas ms antiguo, se invent durante la creacin del mtodo
estructurado. Si se elige un proyecto, el mtodo varia en etapas.2 Como todo modelo,
existen sus pros y contras al usar este paradigma:

Si se aplica este paradigma, unos de los principales problemas , es que las etapas
realizadas no son autnomas de las siguientes, creando una dependencia estructural y en
el acaso de un error atrasara todo el proyecto. Se tiene que tener pautas bien definidas, y
que no se incurra a modificacin porque implicara en que el software no cumpla con su
ciclo de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia. 3
2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programacin orientada
a objetos; por lo tanto, se refiere al concepto de clase, el anlisis de requisitos y el diseo.
El modelo o paradigma orientado a objetos posee dos caractersticas principales, las
cuales son:

Permite la re-utilizacin de software.

Facilita el desarrollo de herramientas informticas de apoyo al desarrollo, el cual es
simple al implementarla en una notacin orientado a objetos llamado UML.4

3. Paradigma de Desarrollo gil: Es un paradigma de las Metodologas De

Desarrollo basado en procesos giles. Estos intentan evitar los tediosos caminos de las
metodologas tradicionales enfocndose en las personas y los resultados. Usa un enfoque
basado en el Valor para construir software, colaborando con el cliente e incorporando los
cambios continuamente.5

Modelo de cascada
Artculo principal: Desarrollo en cascada

El modelo de cascada define las siguientes etapas que deben cumplirse de forma
sucesiva:
1. Especificacin de requisitos
2. Diseo del software
3. Construccin o Implementacin del software
4. Integracin
5. Pruebas (o validacin)
6. Despliegue (o instalacin)
7. Mantenimiento
Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase,
comienza la otra. En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo
que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de
cambio). Las revisiones tambin se utilizan para asegurar que la fase anterior ha sido
totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con
el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya
se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente
de crtica de los defensores de modelos ms flexibles.

Modelo de espiral
Artculo principal: Desarrollo en espiral

La principal caracterstica del modelo en espiral es la gestin de riesgos de forma peridica

en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando
algunos aspectos clave de las metodologas del modelo de cascada y del desarrollo rpido
de aplicaciones, pero dando nfasis en un rea que para muchos no jug el papel que
requiere en otros modelos: un anlisis iterativo y concienzudo de los riesgos,
especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a travs de algunas interaciones con el
diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
1. crear planes con el propsito de identificar los objetivos del software,
seleccionados para implementar el programa y clarificar las restricciones en el
desarrollo del software;
2. Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para
evaluar como identificar y eliminar el riesgo;
3. la implementacin del proyecto: implementacin del desarrollo del software y su
pertinente verificacin;

Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las
opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software
puede ayudar como una meta propia en la integracin en el desarrollo del producto. Sin
embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
1. El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que
acepten este anlisis y acten en consecuencia. Para ello es necesaria confianza
en los desarrolladores as como la predisposicin a gastar ms para solventar los
temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de
software a gran escala.
2. Si la implementacin del riesgo de anlisis afectar de forma esencial los
beneficios del proyecto, no debera utilizarse este modelo.
3. Los desarrolladores de software han de buscar de forma explcita riesgos y
analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la bsqueda de un plan para conseguir los objetivos con las
limitaciones del proyecto para as buscar y eliminar todos los riesgos potenciales por
medio de un cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un
prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es
conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por ltimo, se
evalan los resultados y se inicia el diseo de la siguiente fase.

Desarrollo iterativo e incremental[editar]

Artculo principal: Desarrollo iterativo e incremental

El desarrollo iterativo recomienda la construccin de secciones reducidas de software que

irn ganando en tamao para facilitar as la deteccin de problemas de importancia antes
de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del
diseo en el caso de clientes que no saben cmo definir lo que quieren. 6

Desarrollo gil[editar]
Artculo principal: Desarrollo gil de software

El desarrollo gil de software utiliza un desarrollo iterativo como base para abogar por un
punto de vista ms ligero y ms centrado en las personas que en el caso de las soluciones
tradicionales. Los procesos giles utilizan retroalimentacin en lugar de planificacin, como
principal mecanismo de control. La retroalimentacin se canaliza por medio de pruebas
peridicas y frecuentes versiones del software.
Hay muchas variantes de los procesos giles:

En el caso de la programacin extrema (XP), las fases se realizan en pasos muy

cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente
incompleto) por los pasos puede ocurrir en un da o en una semana, en lugar de los
meses o aos de cada paso completo en el modelo en cascada. En primer lugar, se
crean pruebas automatizadas para proveer metas concretas al desarrollo. Despus se
programa el cdigo, que ser completo cuando todas las pruebas se superan sin
errores, y los desarrolladores ya no sabran como mejorar el conjunto de pruebas
necesario. El diseo y la arquitectura emergen a partir de la refactorizacin del cdigo,
y se da despus de programar. El diseo lo realizan los propios desarrolladores del
cdigo. El sistema, incompleto, pero funcional se despliega para su demostracin a los

usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este
punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del
sistema de ms importancia.

Codificacin y correccin[editar]
El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms que una
estrategia predeterminada, el resultado de una falta de experiencia o presin que se ejerce
sobre los desarrolladores para cumplir con una fecha de entrega. 7 Sin dedicar tiempo de
forma explcita para el diseo, los programadores comienzan de forma inmediata a
producir cdigo. Antes o despus comienza la fase de pruebas de software (a menudo de
forma tarda) y los inevitables errores que se encuentran han de eliminarse antes de poder
entregar el software.

Orientado a la Reutilizacin[editar]
La reutilizacin de software es un proceso donde se recurre al uso de activos de software
en las especificaciones de anlisis, diseos, implementacin y pruebas de una aplicacin o
sistemas de software.8

La reutilizacin tiene ciertos Indicadores por ejemplo:

1. Entre el 40% y 60% de una aplicacin es re-utilizable en otra.
2. Aproximadamente el 60% de una aplicacin administrativa es re-utilizable.
3. Aproximadamente el 75% de las funciones son comunes a ms de un programa.
4. Solo el 15% del cdigo encontrado en muchos sistemas es nico y novedoso a una
aplicacin especifica.
El rango general de uso recurrente esta entre el 15% y 85%. 9
La reutilizacin tiene Principios como la existencia de parecidos en distintos sistemas de
un mismo dominio, donde el software puede representarse como una combinacin de
mdulos y los sistemas nuevos se puede caracterizar por diferencias respecto a los
antiguos sistemas.10

Modelos de mejora de procesos[editar]

Capability Maturity Model Integration
El Capability Maturity Model Integration (CMMI), en espaol Integracin de
Modelos de Madurez de Capacidades es uno de los modelos lderes basados en
mejores prcticas. Son evaluaciones independientes las que confirman el grado
con el que una organizacin siguen sus propios procesos, que no evala la calidad
de los procesos o del software que se produce. CMMI ha reemplazado a CMM y
tiene un mbito global, no slo en procesos destinados al desarrollo del software.
ISO 9000
ISO 9000 describe estndares para un proceso organizado formalmente para
resultar en un producto y los mtodos de gestin y monitoreo del progreso. Aunque
este estndar se cre inicialmente para el sector de produccin, los estndares de

ISO 9000 tambin se han aplicado al desarrollo del software. Al igual que CMMI,
que una organizacin est certificada con el ISO 9000 no garantiza la calidad del
resultado final, slo confirma que se ha seguido los procesos establecidos.
ISO 15504
ISO 15504, tambin conocido como Software Process Improvement Capability
Determination (SPICE), en espaol Determinacin de la Capacidad de Mejora del
Proceso de Software es un marco para la evaluacin de procesos de software.
Este estndar tiene como objetivo un modelo claro para poder comparar procesos.
SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar,
controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza
entonces para medir lo que una organizacin o proyecto hace durante el desarrollo
del software. Esta informacin se analiza para identificar puntos dbiles y definir
acciones para subsanarlos. Tambin identifica puntos fuertes que pueden
adoptarse en el resto de la organizacin.

Mtodos formales[editar]
Los mtodos formales son soluciones matemticas para resolver problemas
de software y hardware a nivel de requisitos, especificacin y diseo.
Ejemplos de mtodos formales incluyen el Mtodo B, la red de Petri,
la demostracin automtica de teoremas, RAISE y el VDM. Hay varias
notaciones de especificaciones formales, tales como el lenguaje Z. Ms
generalmente, se puede utilizar la teora de autmatas para aumentar y validar
el comportamiento de la aplicacin diseando un sistema de autmata finito.
Las metodologas basadas en los autmatas finitos permiten especificacin de
software ejecutable y evitar la creacin convencional de cdigo.
Los mtodos formales se suelen aplicar en software de aviacin,
especialmente si es software de seguridad crtico. Los estndares de
aseguramiento del software de seguridad, tales como DO178B demandan
mtodos formales en el nivel ms alto de categorizacin (Nivel A).
La formalizacin del desarrollo de software est ganando en fuerza poco a
poco, en otros mbitos, con la aplicacin del lenguaje de especificacin
OCL2.0 (y especializaciones tales como Java Modeling Language) y
particularmente con Model-driven Architecture, que permite la ejecucin de
diseos, incluso especificaciones.
Otra tendencia que est surgiendo en el desarrollo de software es la redaccin
de especificaciones en algn tipo de lgica (normalmente una variacin de
FOL), para acto seguido ejecutar esa lgica como si se tratase de un
programa. El lenguaje OWL, basado en lgica descriptiva, es un buen
ejemplo. Tambin se est trabajando en enlazar un idioma natural de forma
automtica con lgica, lgica que puede ejecutarse. Ejemplo en este campo
es el Attempto Controlled English, una lgica de negocios de Internet, que no
busca controlar el vocabulario o la sintaxis. Una caractersticas de los
sistemas que apoyan el vnculo bidireccional ingls-lgica y ejecucin directa
de la lgica es que pueden explicar sus resultados en ingls en un nivel de
negocios o cientfico.

3ra Semana

Herramientas para modelar software