~ 1 ~

INSTITUTO TECNOLOGICO SUPERIOR DE TEPEACA

INGENIERIA EN SISTEMAS COMPUTACIONALES

INGENIERIA DE SOFTWARE

6 SEMESTRE FEBRERO-JUNIO

ANTOLOGIA

Luis Meneses Vera

No. CONTROL: 10791061


PROFRSORA: INES LEON FLORES

~ 2 ~

NDICE
Contenido
UNIDAD 1 MODELO DE NEGOCIOS .................................................................................................. 4
1.1 Evolucin del Modelado de Negocios ....................................................................................... 4
1.2 Componentes del Modelado de Negocios ................................................................................ 6
1.3 Orientacin del Modelado de Negocio ................................................................................... 10
1.4 BPMN en el Modelo de Negocio ............................................................................................. 12
UNIDAD 2 METODOLOGA DEL DESARROLLO ................................................................................... 13
2.1 Metodologa Clsica ................................................................................................................ 13
2.1.1 Cascada................................................................................................................................. 13
2.1.2 Incremental .......................................................................................................................... 14
2.1.3 Evolutivo ............................................................................................................................... 14
2.1.4.- Espiral ................................................................................................................................. 15
2.1.5.- Prototipos........................................................................................................................... 16
2.1.6.- DESARROLLO BASADO EN COMPNENTES .......................................................................... 17
2.2.- OTRAS METODOLOGIAS ........................................................................................................ 18
2.2.1.- GANAR-GANAR (WinWin) .................................................................................................. 18
2.2.2.- PROCESO UNIFICADO (UP) ................................................................................................. 18
2.2.3.- INGENIERIA WEB ................................................................................................................ 19
2.2.4.- METODOLOGIAS AGILES .................................................................................................... 20
UNIDAD 3 ARQUITECTURAS DE SOFTWARE ...................................................................................... 21
3.1.- DESCOMPOSICIN MODULAR .............................................................................................. 21
3.2.- ARQUITECTURA DE DOMINO ESPECIFICO ............................................................................ 27
3.3.- DISEO DE SOFTWARE DE ARQUITECTURA DE MULTIPROCESADOR ................................... 29
3.4.- DISEO DE SOFTWARE DE CLIENTE-SERVIDOR ..................................................................... 30
3.5.- DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA .................................................... 31
3.6.- DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL .............................................. 33
UNIDAD 4 SEGURIDAD EN INGENIERA DE SOFTWARE..................................................................... 34
4.1.- SEGURIDAD DEL SOFTWARE ................................................................................................. 34
4.2.- SEGURIDAD EN EL SIGLO DE DESARROLLO DE SOFTWARE. .................................................. 36
4.3.- CONFIABILIDAD DE SOFTWARE. ............................................................................................ 37
~ 3 ~

4.4.- INGENIERA DE SEGURIDAD. ................................................................................................. 39
GLOSARIO .......................................................................................................................................... 40
BIBLIGRAFIA ....................................................................................................................................... 41

Figura 1. 1Los principales componentes del modelo de negocios; el modelo RCOV. (Adaptado de
Lecocq, Demil y Warnier, 2006). ......................................................................................................... 7
Figura 1. 2 Componentes del modelado de negocios (Profit site, Valor al cliente, Alcance,
Estrategias de precios, Fuentes de ingreso(utilidad)). ........................................................................ 8
Figura 1. 3 Componentes del modelado de negocios(negocio tradicional y negocio electrnico). .... 9
~ 4 ~


UNIDAD 1 MODELO DE NEGOCIOS
1.1 Evolucin del Modelado de Negocios

El trmino modelos de negocio ha prosperado en la bibliografa dedicada a las actividades
gerenciales desde finales de la dcada de 1990, especialmente a raz de la aparicin de la era de
Internet y de su adopcin masiva por parte del comercio (Ghaziani y Ventresca, 2005). En los
discursos de los directivos, los modelos de negocio se suelen mencionar para evocar la idea de
cambio, en frases como esta: Tenemos que hacer evolucionar nuestro modelo de negocio
(vase, por ejemplo, Yip, 2004 o Johnson y cols., 2008). Lo que es ms, un modelo de negocio
raras veces se descubre de inmediato. Para crear una coherencia interna o adaptarse al entorno,
es necesario realizar sucesivos ajustes. Como Winter y Szulanski (2001: 731) argumentan: La
frmula o el modelo de negocio, lejos de ser una cantidad de informacin que se revela de una
sola vez, normalmente es un conjunto complejo de rutinas interdependientes que se descubren,
ajustan y matizan mediante la accin. Algunos cambios masivos en el modelo de negocio pueden
incluso transformar radicalmente un sector industrial. Por ejemplo, la aparicin de un sector de
prensa gratuita se describe a menudo como uno de los factores del declive de los medios de
comunicacin tradicionales.
A pesar del inters de una visin dinmica del modelo de negocio, su uso, paradjicamente, suele
ser esttico. Desde luego, a menudo se describe al modelo de negocio como el esquema general
de una actividad empresarial (Magretta, 2002), y ayuda a pensar de forma ms o menos creativa
en la pregunta bsica: Cmo puedo ganar dinero en mi sector? (Afuah, 2004). Segn esta
visin, un modelo de negocio describe y sintetiza la forma de crear valor en un negocio. Ms
concretamente, lleva a los directivos a conceptualizar las diferentes actividades que una empresa
inicia con el fin de generar valor para los clientes y los accionistas. Por ejemplo, el modelo de
negocio de las lneas areas de bajo coste ahora est bien documentado. Esas empresas utilizan
recursos estndar y tipos estndar de aviones, ofrecen vuelos sin conexiones, tienen una gestin
de recursos humanos basada en bajos salarios y poca presencia de los sindicatos, utiliza de forma
intensiva los sistemas de reservas a travs de Internet y establecen contratos con aeropuertos
secundarios. Esos elementos coherentes han reducido de forma drstica la estructura de costes de
dichas empresas. As pues, la visin esttica del modelo de negocio sigue siendo til para insistir
en la coherencia de los diferentes elementos y ayuda a comunicarse y a conseguir el acuerdo
(Osterwalder, 2004), una caracterstica que resulta especialmente importante para los empresarios.
En este artculo, abordamos la paradoja entre la necesidad de coherencia entre los diferentes
componentes de un modelo de negocio, por un lado (visin esttica), y la necesidad de pensar en
la evolucin de un modelo de negocio, por otro (visin dinmica). Para ello, nos basaremos en un
marco de trabajo que permita al mismo tiempo la coherencia y una visin dinmica del modelo de
negocio: el modelo RCOV (Lecocq y cols., 2006). Proporcionamos una visin coherente de la
dinmica del modelo de negocio, al tener en cuenta los cambios entrelazados, voluntarios y
emergentes que afectan a los diferentes componentes de un modelo de negocio y que pueden
influir en su coherencia general. Ilustraremos nuestro entorno de trabajo con el caso del Arsenal
FC, el club de ftbol de la Premier League inglesa cuyo modelo de negocio ha evolucionado
radicalmente a lo largo de los ltimos diez aos. Mediante este breve caso ilustrativo, pretendemos
demostrar que un modelo de negocio es un delicado proceso de ajuste, basado en la construccin
de recursos permite tambin ilustrar cmo los cambios emergentes y voluntarios estn
relacionados entre s. Algunas evoluciones del entorno pueden llevar a acciones voluntarias por
parte de las organizaciones. Por el contrario, las elecciones estratgicas pueden tener conse-
~ 5 ~

cuencias emergentes inesperadas sobre el modelo de negocio. Una consecuencia alentadora de
tales hallazgos es que la sostenibilidad de una organizacin puede estar relacionada con su
capacidad de anticiparse a las consecuencias que los cambios de un determinado componente de
su modelo de negocio pueden conllevar para otros componentes. Tal capacidad permite adaptarse
de forma voluntaria a los cambios que van surgiendo en el entorno, pero adems permite crear
crculos virtuosos que siguen una decisin estratgica que modifica un componente del modelo de
negocio de la organizacin. Por ltimo, una visin semejante de los modelos de negocio promueve
una visin dinmica de la estrategia que es adecuada para el entorno actual. Por supuesto, evita
los lmites, tanto de los enfoques de estrategia en trminos de ventaja competitiva sostenible
(visin basada en la economa y los recursos industriales), que se supone que defienden y
protegen una determinada ventaja competitiva (por ejemplo, ningn gran cambio en el modelo de
negocio), como de los enfoques en trminos de rendimiento no sostenible (hper competencia), que
conllevan cambios casi caticos y permanentes en los componentes del modelo de negocio,
debidos a la permanente presin ambiental. Llamamos coherencia dinmica a la capacidad de
una empresa de construir y mantener un rendimiento sostenible, al tiempo que cambia su modelo
de negocio (es decir, al tiempo que encuentra procesos nuevos pero coherentes que llevan a la
obtencin de beneficios).

~ 6 ~

1.2 Componentes del Modelado de Negocios

Para nosotros, el modelo de negocio abarca las elecciones de una organizacin para generar
ingresos en un sentido amplio: volumen de negocio, pero tambin derechos de propiedad
intelectual, alquileres, intereses, subsidios, transferencias de activos (Afuah, 2004; Lecocq y cols.,
2006). Ms concretamente, vemos el modelo de negocio como la forma en que una organizacin
articula dinmicamente tres componentes principales para generar ingresos y posteriormente
beneficios. Esos tres componentes comprendidos en el modelo RCOV son: recursos y
competencias (RC) para generar valor, organizacin (O) de la empresa dentro de una red de valor
o dentro de los lmites de la empresa (Amit y Zott, 2001; Chesbrough y Rosenbloom, 2002), y la
proposicin de valor (V) para los productos y servicios suministrados.
Los recursos y las competencias se valoran a travs del suministro de productos o servicios en los
mercados. Por ejemplo, American Airlines desarroll internamente el sistema de gestin de
reservas Sabre para su uso interno, antes de considerarlo un recurso que pudiera generar ingresos
por s mismo, al ofrecerlo a terceros. Actualmente, 7.000 personas trabajan en todo el mundo para
Sabre Holdings Corporation, y la empresa tiene un volumen de negocio de 2 mil millones de
dlares por la venta y el mantenimiento del sistema Sabre para 200 lneas areas de distintas
partes del mundo.
Por organizacin se entiende la eleccin de operaciones que una entidad asegura y las
relaciones que establece con otras entidades. Dicho de otra forma, para examinar el componente
organizacin hace falta estudiar la cadena de valor (Porter, 1985) y la red de valor, es decir, la
compleja trama de relaciones que una empresa crea con los participantes externos (proveedores,
clientes, competidores, reguladores...). Implica tambin pensar en la apropiacin de valor dentro de
la red de valor (Chesbrough y Rosenbloom, 2002). Por ejemplo, el sistema de inscripcin de
muchos sitios web en Internet ha transformado a los clientes tradicionales en algo muy similar a
empleados, al ofrecerles un porcentaje de las ventas que generan.
Finalmente, el modelo de negocio consiste tambin en pensar en la proposicin de valor que la
empresa proporciona al cliente a travs de sus productos y servicios por s mismos, y cmo esos
productos y servicios se comercializarn, as como pensar en su frmula de beneficios (Johnson y
cols., 2008). Por ejemplo, en el sector de la biotecnologa, gran cantidad de emprendimientos
aaden servicios a su portafolio de desarrollo de productos. Sus fuentes de ingresos a largo plazo
son los productos, pero para generar recursos rpidos en efectivo, necesitan proponer servicios a
sus clientes. Esta dimensin refleja el contenido de la transaccin (Amit y Zott, 2001) y el desarrollo
idiosincrsico de los recursos que cada organizacin gestiona. Desde luego, como subraya
Penrose (1959: 25): Los servicios prestados por los recursos estn en funcin de la forma en que
se utilizan (...) en combinacin con diferentes tipos o cantidades de otros recursos.

~ 7 ~


Figura 1. 1Los principales componentes del modelo de negocios; el modelo RCOV.
(Adaptado de Lecocq, Demil y Warnier, 2006).
Esos tres componentes bsicos de un modelo de negocio determinan la estructura y el volumen de
costes e ingresos de un negocio y, en ltima instancia, sus beneficios y, por lo tanto, su
sostenibilidad (vase la figura 1). En nuestra opinin, la estructura de costes est impulsada, en
esencia, por los recursos y las competencias que la empresa adquiere y desarrolla, as como por la
organizacin que despliega, con el fin de llevar hacia las diversas actividades de su cadena de
valor y de su red de valor. Estos elementos corresponden al conjunto de recursos y del sistema
administrativo que propuso Penrose (1959). La parte de los ingresos depende, sobre todo, de las
proposiciones de valor realizadas a diversos tipos de clientes.
La concepcin RCOV lleva con moderacin a un enfoque en el que los empresarios tienen que
considerar las cuestiones de organizacin conjuntamente con el valor ofrecido y los recursos
acumulados y combinados. Ms concretamente, el concepto de modelo de negocio debera
comprenderse desde la perspectiva de las interacciones permanentes entre los componentes de
un modelo de negocio y de las repercusiones de un cambio en los otros componentes. Por
ejemplo, elegir quin paga un producto o servicio significa definir los participantes de la empresa y
su poder relativo para negociar. En el sector de la prensa escrita, los participantes no sern los
mismos, segn si los clientes pagan por la informacin, si son las empresas las que pagan la
publicidad, o si el diario se distribuye de forma gratuita a los lectores. Elegir cmo se paga un
producto o un servicio tambin influye en el flujo de efectivo, adems de en la imagen y la
reputacin de la empresa.





~ 8 ~













Figura 1. 2 Componentes del modelado de negocios (Profit site, Valor al cliente, Alcance,
Estrategias de precios, Fuentes de ingreso(utilidad)).


~ 9 ~


Figura 1. 3 Componentes del modelado de negocios(negocio tradicional y negocio
electrnico).

Componente Negocio tradicional Negocio
Electrnico
Actividades
relacionadas
Qu conjunto de
actividades tiene que
desarrollar la empresa para
ofrecer valor? Cmo estn
relacionadas?
Cuntas nuevas actividades se
tienen que desarrollar con el uso
del Internet? En qu mejoran o
ayudan?
Implementacin Cmo es la estructura
organizacional, gente,
sistemas y ambiente
necesarios para
implementar las
actividades?
Cmo afecta el Internet la
estructura organizacional, gente,
sistemas y ambiente?
Capacidades Qu capacidades tiene la
empresa? Cules le falta
llenar? Hay algo diferente
en esas capacidades que
permiten ofrecer mejor
valor o valor poco imitable?
Cul es el origen de esas
capacidades?
Qu nuevas capacidades se
deben desarrollar con el uso del
Internet?
Sustentabilidad Qu hace la empresa para
dificultar que la imiten? La
empresa es constante
generando dinero? Cmo
se mantiene la ventaja
competitiva?
El Internet hace la
sustentabilidad ms fcil o ms
difcil? Esto permite ms o
menos ventaja competitiva?
Costo de
estructura
Cunto cuesta desarrollar
cada elemento del modelo
de negocio?
Qu impacto tiene el Internet en
el costo de cada componente del
modelo de negocio?
~ 10 ~

1.3 Orientacin del Modelado de Negocio

Las estrategias se deben orientar a rentabilidad, alta rotacin de inventarios (los productos deben
mantenerse siempre frescos). Todos los componentes del canal de distribucin son un equipo
(logstica de distribucin), el servicio como un derecho del cliente. Direccin de la compaa como
el cerebro que gua. Ponerse en los zapatos del cliente, mirar de afuera hacia adentro (orientacin
al mercado).
Lealtad (se acta en la empresa como pequeos empresarios / los no leales le hacen daos
irreparables a la compaa), gente con compromiso. Garanta de producto y servicio. Control
sistemtico. Calidad total y mejoramiento continuo.

Control vertical y horizontal a los procesos. Estrategia y planeacin (como una costumbre, algo que
se hace de manera natural). Guerra de mercados (leer y aplicar el arte de la guerra del maestro
Sun Tzu, uno de los mejores libros de marketing aplicado). Posicionamiento de productos (con su
marca), posicionamiento de empresa.
Liderazgo en un nicho (as sea creado por la empresa). Responder a la globalizacin como lderes
en costos, con recursos frescos de capital (no al endeudamiento), con precios en funcin al
mercado internacional, con alta tecnologa.
Hagamos nfasis en la logstica o cadena de abastecimiento. Nos ayuda a encontrar la mayora de
las respuestas que hemos venido buscando. El anlisis logstico permite: Ver al negocio de
comercio de una manera distinta a la habitual, inserto en una sucesin de pasos: Estos eslabones
se inician en el cliente, llegando hacia atrs hasta el punto de consecucin o compra de los
productos al proveedor.
Una estrategia en logstica de distribucin bien diseada es una de las herramientas ms
contundentes para crear lealtad de los clientes, adems que aporta definitivamente en "minimizar"
el costo oculto generado por el agotamiento de un producto. Otro de los beneficios tangibles es el
aumento de la rentabilidad (por disminucin de costos) al prestar un mejor servicio a nuestros
clientes.
El futuro del marketing est completamente ligado a la logstica y no se pueden separar y la
percepcin que tengan los consumidores sobre nuestros productos y servicios en el corto plazo
estar relacionada directamente con esta fusin de mercadeo y logstica.
Como ya lo habamos expresado en ocasiones anteriores, La cadena de abastecimiento es una
estrategia de negocios en las que distribuidores y proveedores se comprometen y trabajan juntos
para lograr mejores valores para los consumidores. Esta estrategia recibe el nombre de "efficient
consumer response", una filosofa que logra reducir los costos de un producto en su camino de la
fbrica al consumidor final.
La visin empresarial de quienes participan en esta cadena es un flujo mas rpido y que responda
mejor, costando menos, en el recorrido productor y comerciantes tanto mayoristas como
minoristas. Una cadena sin interrupciones, en la cual la informacin adems de ser fundamental en
todo este proceso, fluye rpida y oportunamente a todas las partes involucradas en este proceso
va al consumidor final. El punto de partida est motivado por las compras de los consumidores,
esto motiva el movimiento de productos e inventarios.
Una bien diseada cadena de abastecimientos logra reduccin en los costos de fabricacin,
gracias a una mejor y ms eficiente fabricacin, la reduccin de empaques y la compra ms
eficiente de materias primas.
Los costos del marketing y administrativos tambin de reducen significativamente como
consecuencia de un movimiento ms rpido de las mercancas, mejorando sustancialmente la
rotacin.
~ 11 ~

Se consiguen as mismo reducciones importantes de costos en la operacin de los puntos de venta
y una mejor utilizacin del capital de trabajo disponible.
Las cadenas de abastecimiento de apoyan en la informacin rpida y oportuna de
rotacin en la misma cadena, informacin sobre el comportamiento del consumidor, categorizacin
de los productos, segmentacin de los mercados, bases de datos, lectores de barras en las
registradoras, rdenes de compra asistidas por la computadora.
La creacin de las cadenas de abastecimiento implica un cambio profundo en los sistemas
habituales de comercializacin, se rompen esquemas en la manera y cultura de hacer negocios.
Implica una gerencia con mentes abiertas y dispuestas a la innovacin y aplicacin de nuevas
metodologa para lograr unos mejores resultados. Esta reconvencin de la lnea habitual de
suministros de productos al consumidor final obliga a una reingenieria total en el papel actual de
los comerciantes tanto mayoristas como minoristas.
En este caso hay un ahorro muy importante en los costos de almacenar, se mejoran
sustancialmente los ndices de rotacin de inventarios. Consiste en utilizar el inventario disponible
de algunos fabricantes o empresas de distribucin como propio, por medio de una comunicacin
por computadora se ingresa desde el punto de venta al inventario del fabricante y sobre este se
elabora un pedido para ser despachado de manera inmediata y surtido directamente en las
gndolas. El proveedor despacha y factura lo correspondiente a ese pedido. Esta operacin puede
darse varias veces al mes, a la semana o diario. Son importantes entonces en esto de la cadena
de abastecimiento el reintentar de la parte de distribucin y usarlo para enfrentar a los crecientes
desafos de la competencia minorista.

~ 12 ~

1.4 BPMN en el Modelo de Negocio

Es un nuevo estndar de modelado de procesos de negocio, en donde se presentan grficamente las diferentes
etapas del proceso del mismo. La notacin ha sido diseada especficamente para coordinar la secuencia de procesos
y los mensajes que fluyen entre los diferentes procesos participantes.

BPMN
(Business Process Modeling Notacin) y las extensiones de UML que te ayudarn a modelar la situacin actual y
deseada en los procesos de negocio de tu cliente. Ya tienes claro que si no partes de reglas de negocio claramente
establecidas difcilmente podrs desarrollar el sistema adecuado que proporcione un valor real a tu cliente. El mundo
de los procesos de negocio ha cambiado dramticamente en los ltimos aos. Un proceso de este tipo abarca
mltiples participantes, y la coordinacin puede ser compleja. Antes de BPMN no haba una tcnica de modelado
estndar desarrollado para encargarse de estos asuntos. BPMN ha sido desarrollado para proveer a los usuarios de
una notacin de uso libre. Esto beneficiar a los usuarios de la misma forma que UML benefici el mundo de la
ingeniera de software.

A quin est dirigido BPMN? BPMN
Est dirigido a gerentes, directores, dueos de empresas, ingenieros de procesos, analistas de negocios, analistas de
sistemas, administradores de proyectos, responsables de calidad y todo aquel que necesita definir, documentar y
hacer ms eficientes sus procesos de negocio con el estndar ms avanzado y aceptado a nivel internacional.

Qu significa esto para los usuarios de UML?
UML (El lenguaje de modelado unificado) toma un perfil orientado a objetos en el modelado de aplicaciones, mientras
que BPMN toma un perfil orientado a procesos en el modelado de sistemas

BPMN
Tiene un enfoque en procesos de negocio, UML se enfoca al diseo de software y por lo tanto ambas notaciones son
totalmente compatibles entre s. Las extensiones de UML para el modelado de negocio aportan elementos muy
importantes ya que proporcionan algunas otras vistas de la arquitectura de negocio que son ms difciles de observar
usando nicamente.

BPMN
. Por ejemplo, la visualizacin de las responsabilidades de los trabajadores del negocio, la manipulacin de las
entidades del negocio y la comprensin de los estados asociados a las entidades del negocio. Es por eso que en
nuestro exclusivo curso planteamos la coexistencia de ambas notaciones.

~ 13 ~

UNIDAD 2 METODOLOGA DEL DESARROLLO
2.1 Metodologa Clsica
2.1.1 Cascada

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se
hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseo, lo
cual significa que se harn los cambios necesarios en la codificacin y se tendrn que realizar de
nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento
hay que recorrer de nuevo el resto de las etapas. Despus de cada etapa se realiza una revisin
para comprobar si se puede pasar a la siguiente
Estructura Modelo en Cascada
Ingeniera y Anlisis del Sistema:
Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo
los requisitos de todos los elementos del sistema y luego asignando algnsubconjunto de estos
requisitos al software.
Anlisis de los requisitos del software:
El proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El
ingeniero de software debe comprender el mbito de la informacin del software, as como la
funcin, el rendimiento y las interfaces requeridas.
Diseo:
El diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los
datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz
Codificacin:
El diseo debe traducirse en una forma legible para la mquina. El paso de codificacin realiza
esta tarea.
Prueba: La prueba se centra en la lgica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se
requieren.
Mantenimiento:
El software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debidos a
que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo
(sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones
funcionales eso del rendimiento
Caractersticas
Es el ms utilizado.
~ 14 ~

Es una visin del proceso de desarrollo de software como una sucesin de etapas que producen
productos intermedios.
Para que el proyecto tenga xito deben desarrollarse todas las fases.
Las fases continan hasta que los objetivos se han cumplido.
Si se cambia el orden de las fases, el producto final ser de inferior calidad
2.1.2 Incremental

El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de
prototipos.
En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin
embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline,
utilizado en muchas otras formas de programacin. 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 elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva
pero se diferencia de aquellos en que al final de cada incremento se entrega un producto
completamente operacional.
Caractersticas- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.- El usuario se involucre ms.- Difcil de evaluar el costo total.- Difcil 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
muy positivo.

El Modelo Incremental 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.
2.1.3 Evolutivo

Es el modelo cuyas etapas consisten en expandir incrementos de un producto de software
operacional donde la direccin de la evolucin la dicta la experiencia con el sistema
El cliente recibe pequeos incrementos del sistema a medida que van siendo desarrollados:
distribucin incremental
Caractersticas:
~ 15 ~

Gestionan bien la naturaleza evolutiva del software
Son iterativos: construyen versiones de software cada vez ms completas
Se adaptan bien:
Los cambios de requisitos del producto
Fechas de entrega estrictas poco realistas
Especificaciones parciales del producto
Ventajas
Es interactivo
Con cada incremento se entrega al cliente un producto operacional, que puede evaluarlo
Personal
Permite variar el personal asignado a cada interaccin
Gestin riesgos tcnicos
Por ejemplo disponibilidad de hardware especifico
Inconvenientes
La primera interaccin puede plantear los mismos problemas que un modelo lineal secuencial

2.1.4.- Espiral

El modelo en espiral, propuesto originalmente por Boehm [BOE88], es un modelo de proceso de
software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los
aspectos controlados y sistemticos del modelo lineal secuencial. Proporciona el potencial para el
desarrollo rpido de versiones incrementales del software. 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. Generalmente,
existen entre tres y seis regiones de tareas. La figura representa un modelo en espiral que contiene
seis regiones de tareas:
Comunicacin con el cliente- las tareas requeridas para establecer comunicacin entre el
desarrollador y el cliente.
~ 16 ~

Planificacin- las tareas requeridas para definir recursos, el tiempo y otra informacin
relacionadas con el proyecto.
Anlisis de riesgos- las tareas requeridas para evaluar riesgos tcnicos y de gestin.
Ingeniera- las tareas requeridas para construir una o ms representaciones de la
aplicacin.
Construccin y accin- las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario (por ejemplo: documentacin y prctica)
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 implementada
durante la etapa de instalacin
2.1.5.- Prototipos

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica
los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo
del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptacin
de un sistema operativo, o de la forma en que debera tomarse la interaccin hombre mquina. En
estas y en otras muchas situaciones, un paradigma de construccin de prototipos puede ofrecer el
mejor enfoque.
El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El
desarrollador
Y el cliente encuentra y definen los objetivos globales para el software, identifican los requisitos
Conocidos y las reas del esquema en donde es obligatoria ms definicin. Entonces aparece un
diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software
que sern visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida).
El diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente/usuario y se
utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo
se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el
desarrollador comprenda mejor lo que se necesita hacer.

Lo ideal sera que el prototipo sirviera como un mecanismo para identificar los requisitos del
software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los
fragmentos del programa ya existentes o aplica herramientas (por ejemplo: generadores de
informes, gestores de ventanas, etc.) que permiten generar rpidamente programas de trabajo.
~ 17 ~

2.1.6.- DESARROLLO BASADO EN COMPNENTES

En esencia, un componente es una pieza de cdigo pre elaborado que encapsula alguna
funcionalidad expuesta a travs de interfaces estndar (1). Los componentes son los "ingredientes
de las aplicaciones", que se juntan y combinan para llevar a cabo una tarea (2). Es algo muy
similar a lo que podemos observar en el equipo de msica que tenemos en nuestra sala. Cada
componente de aquel aparato ha sido diseado para acoplarse perfectamente con sus pares, las
conexiones son estndar y el protocolo de comunicacin est ya preestablecido. Al unirse las
partes, obtenemos msica para nuestros odos.
El paradigma de ensamblar componentes y escribir cdigo para hacer que estos componentes
funcionen se conoce como Desarrollo de Software Basado en Componentes. El uso de este
paradigma posee algunas ventajas:
Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software.
Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los
componentes antes de probar el conjunto completo de componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes,
el desarrollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar
otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente
por un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con
el paso del tiempo.
De la misma manera, el optar por comprar componentes de terceros en lugar de desarrollarlos,
posee algunas ventajas:
Ciclos de desarrollo ms cortos. La adicin de una pieza dada de funcionalidad tomar das en
lugar de meses o aos.
Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversin puede ser ms
favorable que desarrollando los componentes uno mismo.
Funcionalidad mejorada. Para usar un componente que contenga una pieza de funcionalidad, solo
se necesita entender su naturaleza, ms no sus detalles internos. As, una funcionalidad que sera
imprctica de implementar en la empresa, se vuelve ahora completamente asequible.

~ 18 ~

2.2.- OTRAS METODOLOGIAS

2.2.1.- GANAR-GANAR (WinWin)
El modelo en espiral tratado sugiere una actividad del marco de trabajo que aborda la
comunicacin con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En
un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente
proporciona detalles suficientes para continuar. Desgraciadamente, esto raramente ocurre. En
realidad el cliente y el desarrollador entran en un proceso de negociacin, donde el cliente puede
ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o caractersticas del
sistema frente al coste y al tiempo de comercializacin.
Las mejores negociaciones se esfuerzan en obtener' victoria-victoria. Esto es, el cliente gana
obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el
desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.
El modelo en espiral WINWIN de Boehm [BOE98] define un conjunto de actividades de
negociacin al principio de cada paso alrededor de la espiral. Ms que una simple actividad de
comunicacin con el cliente, se definen las siguientes actividades:
1. Identificacin del sistema o subsistemas clave de los directivos8.
2. Determinacin de las condiciones de victoria de los directivos.
3. Negociacin de las condiciones de victoria de los directivos para reunirlas en un conjunto de
condiciones victoria-victoria para todos los afectados (incluyendo el equipo del proyecto de
software).

2.2.2.- PROCESO UNIFICADO (UP)

El Proceso Unificado de Desarrollo Software 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 Racional 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 Racional, tambin es un marco de trabajo extensible, por lo que muchas veces resulta
~ 19 ~

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 Racional o RUP son marcas registradas por IBM
(desde su compra de Racional Software Corporacin 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 Racional utilizan el trmino
Proceso Unificado, mientras que los autores que pertenecen a Racional favorecen el nombre de
Proceso Unificado de Racional.

2.2.3.- INGENIERIA WEB

Ofrece una solucin de comercio electrnico a las empresas que han decidido comercializar y
administrar sus productos a travs de Internet mediante una tienda virtual y que adems es la
aplicacin de metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente,
operacin y evolucin de aplicaciones de alta calidad en la World Wide Web.
La Ingeniera de la Web no es un clon o subconjunto de la ingeniera de software aunque ambas
incluyen desarrollo de software y programacin, pues a pesar de que la Ingeniera de la Web utiliza
principios de ingeniera de software, incluye nuevos enfoques, metodologas, herramientas,
tcnicas, guas y patrones para cubrir los requisitos nicos de las aplicaciones web. Adems,
existen ciertos aspectos que van ligados a la ingeniera web y que son de mucha utilidad para las
aplicaciones que realicen, aqu los ms importantes para m:
Diseo de procesos de negocio para aplicaciones web
Generacin de cdigo para aplicaciones web
Desarrollo web colaborativo
Ingeniera web emprica
Entornos de desarrollo de aplicaciones web integrados
Pruebas de rendimiento de aplicaciones basadas en web
Personalizacin y adaptacin de aplicaciones web
Modelado de procesos para aplicaciones web
Herramientas y mtodos de prototipo
~ 20 ~

Control de calidad y pruebas de sistemas
Aplicaciones web mviles
Usabilidad de aplicaciones web
Accesibilidad para la web
Metodologas de diseo web
Diseo de interfaces de usuario

2.2.4.- METODOLOGIAS AGILES

Las metodologas giles son sin duda uno de los temas recientes en ingeniera de software que
estn acaparando gran inters. Prueba de ello es que se estn haciendo un espacio destacado en
la mayora de conferencias y workshops celebrados en los ltimos aos. Es tal su impacto que
actualmente existen 4 conferencias internacionales de alto nivel y especficas sobre el tema.
Adems ya es un rea con cabida en prestigiosas revistas internacionales. En la comunidad de la
ingeniera del software, se est viviendo con intensidad un debate abierto entre los partidarios de
las metodologas tradicionales (referidas peyorativamente como "metodologas pesadas") y
aquellos que apoyan las ideas emanadas del "Manifiesto gil". La curiosidad que siente la mayor
parte de ingenieros de software, profesores, e incluso alumnos, sobre las metodologas giles hace
prever una fuerte proyeccin industrial. Por un lado, para muchos equipos de desarrollo el uso de
metodologas tradicionales les resulta muy lejano a su forma de trabajo actual considerando las
dificultades de su introduccin e inversin asociada en formacin y herramientas. Por otro, las
caractersticas de los proyectos para los cuales las metodologas giles han sido especialmente
pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo de software;
aquellos en los cuales los equipos de desarrollo son pequeos, con plazos reducidos, requisitos
voltiles, y/o basados en nuevas tecnologas.
~ 21 ~

UNIDAD 3 ARQUITECTURAS DE SOFTWARE

3.1.- DESCOMPOSICIN MODULAR

Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un mecanismo
sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el
problema, consiguiendo de esta manera una solucin modular efectiva.
Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los
componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin
modular que no inventa nada ya inventado.
Capacidad de comprensin modular. Si un mdulo se puede comprender como una unidad
autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los
mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de
los efectos secundarios de los cambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin aberrante y sus efectos se
limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los
errores.
Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso
aunque su implementacin deba ser monoltica. Existen situaciones (por ejemplo, software en
tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan
sobrecargas de memoria y de velocidad por mnimos que sean (por ejemplo, subrutinas,
procedimientos). En tales situaciones el software podr y deber disearse con modularidad como
filosofa predominante.
El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener
un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los
beneficios de un sistema modular.

DESCOMPOSICION MODULAR
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus
ventajas: claridad, reduccin de costos y reutilizacin
Los pasos a seguir son:
1. Identificar los mdulos
2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda
considerar suficiente validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad
Descomposicin Modular: Independiente Funcional
~ 22 ~

Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En
principio, cada funcin ser realizada en un mdulo distinto. Si las funciones son independientes
los mdulos tendrn independencia funcional.
Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es
recomendable reducir las relaciones entre mdulos al mnimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin.
Descomposicin Modular: Acoplamiento
El grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin y la
complejidad de la interface:
FUERTEPOR CONTENIDO, cuando desde un mdulo se pueden cambiar datos locales de otro
COMN, se emplea una zona comn de datos a la que tienen acceso varios mdulos
MODERADODE CONTROL, la zona comn es un dispositivo externo al que estn ligados los
mdulos, esto implica que un cambio en el formato de datos afecta a todos estos mdulos
POR ETIQUETA, en intercambio de datos se realiza mediante una referencia a la estructura
completa de datos (vector, pila, rbol, grafo, )
DBILDE DATOS, viene dado por los datos que intercambian los mdulos. Es el mejor posible
SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe
Descomposicin Modular: Cohesin
Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para que el n
de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos
afines y relacionados en un mismo mdulo.
ALTACOHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo abstracto de
datos o como una clase de objetos
COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y especfica
MEDIACOHESIN SECUENCIAL, los elementos del mdulo trabajan de forma secuencial
COHESIN DE COMUNICACIN, elementos que operan con le mismo conjunto de datos de
entrada o de salida
COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej.
Arrancar o parar dispositivos
BAJACOHESIN LGICA, se agrupan elementos que realizan funciones similares. Ejs.: mdulos
de E/S o de tratamiento de errores
COHESIN COINCIDENTAL, es la peor y se produce cuando los elementos de un mdulo no
guardan relacin alguna
La descripcin del comportamiento de un mdulo permite establecer el grado de cohesin:
Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA
Si contiene expresiones secuenciales (primero, entonces, cuando), ser temporal o secuencial
Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin lgica
Si aparece inicializar, preparar, configurar, probablemente sea temporal.
Descomposicin Modular: Comprensibilidad
Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada
uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional,
pero adems es deseable:
IDENTIFICACIN, el nombre debe ser adecuado y descriptivo
DOCUMENTACIN, debe aclarar todos los detalles de diseo e implementacin que no queden de
manifiesto en el propio cdigo
SIMPLICIDAD, las soluciones sencillas son siempre las mejores
Descomposicin Modular: Adaptabilidad
~ 23 ~

La adaptacin de un sistema resulta ms difcil cuando no hay independencia funcional, es decir,
con alto acoplamiento y baja cohesin, y cuando el diseo es poco comprensible. Otros factores
para facilitar la adaptabilidad:
PREVISIN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en
el futuro, y poner estos elementos en mdulos independientes, de manera que su modificacin
afecte al menor nmero de mdulos posible
ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e
implementacin para obtener un conocimiento suficiente del sistema antes de proceder a su
adaptacin
CONSISTENCIA, despus de cualquier adaptacin se debe mantener la consistencia del sistema,
incluidos los documentos afectados.

En 1979 el arquitecto Christopher Alexander aport al mundo de la arquitectura el libro
TheTimelessWay of Building; en l propona el aprendizaje y uso de una serie de patrones para la
construccin de edificios de una mayor calidad.
En palabras de este autor, "Cada patrn describe un problema que ocurre infinidad de veces en
nuestro entorno, as como la solucin al mismo, de tal modo que podemos utilizar esta solucin un
milln de veces ms adelante sin tener que volver a pensarla otra vez."
Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen
denominado A PatternLanguage, son un intento de formalizar y plasmar de una forma prctica
generaciones de conocimiento arquitectnico. Los patrones no son principios abstractos que
requieran su redescubrimiento para obtener una aplicacin satisfactoria, ni son especficos a una
situacin particular o cultural; son algo intermedio. Un patrn define una posible solucin correcta
para un problema de diseo dentro de un contexto dado, describiendo las cualidades invariantes
de todas las soluciones.
Ms tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para
desarrollar cinco patrones de interaccin hombre-ordenador (HCI) y publicaron un artculo en
OOPSLA-87 titulado UsingPatternLanguagesfor OO Programs.
No obstante, no fue hasta principios de la dcada de 1990 cuando los patrones de diseo tuvieron
un gran xito en el mundo de la informtica a partir de la publicacin del libro DesignPatterns
escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph
Johnson y John Vlisides, en el que se recogan 23 patrones de diseo comunes.
Objetivos de los patrones
Los patrones de diseo pretenden:
Proporcionar catlogos de elementos reusables en el diseo de sistemas software.
Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados
anteriormente.
Formalizar un vocabulario comn entre diseadores.
Estandarizar el modo en que se realiza el diseo.
Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya
existente.
Asimismo, no pretenden:
Imponer ciertas alternativas de diseo frente a otras.
Eliminar la creatividad inherente al proceso de diseo.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o
similar que soluciona el patrn, siempre teniendo en cuenta que en un caso particular puede no ser
aplicable. "Abusar o forzar el uso de los patrones puede ser un error".
Categoras de patrones
Segn la escala o nivel de abstraccin:
~ 24 ~

Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental
para sistemas de software.
Patrones de diseo: Aquellos que expresan esquemas para definir estructuras de diseo (o sus
relaciones) con las que construir sistemas de software.
Dialectos: Patrones de bajo nivel especficos para un lenguaje de programacin o entorno
concreto.
Adems, tambin es importante resear el concepto de "antipatrn de diseo", que con forma
semejante a la de un patrn, intenta prevenir contra errores comunes de diseo en el software. La
idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseos muy
frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejn
sin salida por haber cometido los mismos errores.
Adems de los patrones ya vistos actualmente existen otros patrones como el siguiente:
Interaccin: Son patrones que nos permiten el diseo de interfaces web.
Estructuras o plantillas de patrones
Para describir un patrn se usan plantillas ms o menos estandarizadas, de forma que se expresen
uniformemente y puedan constituir efectivamente un medio de comunicacin uniforme entre
diseadores. Varios autores eminentes en esta rea han propuesto plantillas ligeramente distintas,
si bien la mayora definen los mismos conceptos bsicos.
La plantilla ms comn es la utilizada precisamente por el GoF y consta de los siguientes
apartados:
Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la comunidad
(normalmente se expresan en ingls).
Clasificacin del patrn: creacional, estructural o de comportamiento.
Intencin: Qu problema pretende resolver el patrn?
Tambin conocido como: Otros nombres de uso comn para el patrn.
Motivacin: Escenario de ejemplo para la aplicacin del patrn.
Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn.
Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrn.
Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que participan
en el patrn.
Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes.
Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del
patrn.
Implementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn.
Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn.
Usos conocidos: Ejemplos de sistemas reales que usan el patrn.
Patrones relacionados: Referencias cruzadas con otros patrones.
Relacin de principales patrones GoF (Gang Of Four)
Patrones creacionales
Object Pool (no pertenece a los patrones especificados por GoF): se obtienen objetos nuevos a
travs de la clonacin. Utilizado cuando el costo de crear una clase es mayor que el de clonarla.
Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se utiliza una
interfaz del prototipo para crear un nuevo objeto por clonacin. El proceso de clonacin se inicia
instanciando un tipo de objeto de la clase que queremos clonar.
Abstract Factory (fbrica abstracta): permite trabajar con objetos de distintas familias de manera
que las familias no se mezclen entre s y haciendo transparente el tipo de familia concreta que se
est usando.
Builder (constructor virtual): abstrae el proceso de creacin de un objeto complejo, centralizando
dicho proceso en un nico punto.
~ 25 ~

Factory Method (mtodo de fabricacin): centraliza en una clase constructora la creacin de
objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica, es decir, la
diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear.
Prototype (prototipo): crea nuevos objetos clonndolos de una instancia ya existente.
Singleton (instancia nica): garantiza la existencia de una nica instancia para una clase y la
creacin de un mecanismo de acceso global a dicha instancia.
Patrones estructurales
Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro
modo no podra utilizarla.
Bridge (Puente): Desacopla una abstraccin de su implementacin.
Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se
tratase.
Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente.
Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de
interfaces de un subsistema.
Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idntica
informacin.
Proxy: Mantiene un representante de un objeto.
Mdulo: Agrupa varios elementos relacionados, como clases, singletons, y mtodos, utilizados
globalmente, en una entidad nica.
Patrones de comportamiento
Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben llevar
los mensajes para que los objetos realicen la tarea indicada.
Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin
sin necesidad de conocer el contenido de la misma.
Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las
herramientas necesarias para interpretarlo.
Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la
implementacin de estos.
Mediator (Mediador): Define un objeto que coordine la comunicacin entre objetos de distintas
clases, pero que funcionan como un conjunto.
Memento (Recuerdo): Permite volver a estados anteriores del sistema.
Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que
cuando un objeto cambie de estado se notifique y actualicen automticamente todos los objetos
que dependen de l.
State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su
estado interno.
Strategy (Estrategia): Permite disponer de varios mtodos para resolver un problema y elegir cul
utilizar en tiempo de ejecucin.
TemplateMethod (Mtodo plantilla): Define en una operacin el esqueleto de un algoritmo,
delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan
ciertos pasos de un algoritmo sin cambiar su estructura.
Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar
las clases sobre las que opera.
Patrones de interaccin
El primer intento por aplicar este concepto en el diseo de las interfaces de usuario se dio por
Ward Cummingham y Kent Beck quienes adaptaron la propuesta de C. Alexander y crearon cinco
patrones de interfaz: Window per task, Few panes, Standard panes, Nouns and verbs, y Short
Menu. En aos ms recientes investigadores como Martin Van Welie, Jennifer Tidwell, Jaime
~ 26 ~

Muoz han desarrollado colecciones de patrones de interaccin para la World Wide Web. En
dichas colecciones captan la experiencia de programadores y diseadores expertos en el
desarrollo de interfaces usables y condensan esta experiencia en una serie de guas o
recomendaciones, que puedan ser usadas por los desarrolladores novatos con el propsito de que
en poco tiempo adquieran la habilidad de disear interfaces que incidan en la satisfaccin de los
usuarios. Los patrones de interaccin buscan la reutilizacin de interfaces eficaces y un manejo
ptimo de los recursos de las pginas web, haciendo ms eficaz el consumo de tiempo en el
diseo del sitio web y permitiendo a los programadores novatos adquirir ms experiencia.
Aplicacin en mbitos concretos
Adems de su aplicacin directa en la construccin de software en general, y derivado
precisamente del gran xito que han tenido, los patrones de diseo han sido aplicados a mltiples
mbitos concretos producindose "lenguajes de patrones" y extensos "catlogos" de la mano de
diversos autores.
En particular son notorios los esfuerzos en los siguientes mbitos:
Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores formas de
construir interfaces hombre-mquina (vase Interaccin persona-computador, Interfaz grfica de
usuario).
Patrones para la construccin de sistemas empresariales, en donde se requieren especiales
esfuerzos en infraestructuras de software y un nivel de abstraccin importante para maximizar
factores como la escalabilidad o el mantenimiento del sistema.
Patrones para la integracin de sistemas (vase Integracin de aplicaciones empresariales), es
decir, para la intercomunicacin y coordinacin de sistemas heterogneos.
Patrones de flujos de trabajo, esto es para la definicin, construccin e integracin de sistemas
abstractos de gestin de flujos de trabajo y procesos con sistemas empresariales. Vase tambin
BPM.


~ 27 ~

3.2.- ARQUITECTURA DE DOMINO ESPECIFICO

El reto para el diseo es disear el software y hardware para proporcionar caractersticas
deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos
sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de
sistemas distribuidos. Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos:
Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de
servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y
los clientes se tratan de forma diferente en estos sistemas.
Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distincin entre servidores y
clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya
localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos
servicios
Ambas arquitecturas se usan ampliamente en la industria, pero la distribucin de las aplicaciones
generalmente tiene lugar dentro de una nica organizacin. La distribucin soportada es, por lo
tanto, intraorganizacional. Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas
que son ms adecuadas para la distribucin interorganizacional: arquitectura de sistemas peer-to-
peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados
principalmente para sistemas personales, pero estn comenzando a usarse para aplicaciones de
empresa.
Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de
programacin y pueden ejecutarse en tipos de procesadores completamente diferentes. Los
modelos de datos, la representacin de la informacin y los protocolos de comunicacin pueden
ser todos diferentes.
Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y
asegurar que dichas partes se puedan comunicar e intercambiar datos. El trmino middleware se
usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes
distribuidos del sistema.
Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computacin
distribuida. El middleware es un software de propsito general que normalmente se compra como
un componente comercial ms que escribirse especialmente por los desarrolladores de la
aplicacin. Ejemplos de middleware son software para gestionar comunicaciones con bases de
datos, administradores de transacciones, convertidores de datos y controladores de comunicacin.
Los sistemas distribuidos se desarrollan normalmente utilizando una aproximacin orientada a
objetos. Estos sistemas estn formados por partes independientes pobremente integradas, cada
una de las cuales puede interaccionar directamente con los usuarios o con otras partes del
sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los
objetos software reflejan estas caractersticas; por lo tanto, son abstracciones naturales para los
componentes de sistemas distribuidos.

Existen dos modelos de dominio especfico:

1. Modelos genricos que son abstracciones de varios sistemas reales.

2. Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.

Modelo genrico: flujo de datos de un compilador Modelo de Referencia: La arquitectura OSI.
~ 28 ~



~ 29 ~

3.3.- DISEO DE SOFTWARE DE ARQUITECTURA DE
MULTIPROCESADOR

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma
concurrente, la razn es porque actualmente la mayora de las CPUs slo pueden ejecutar un
proceso cada vez. La nica forma de que se ejecuten de forma simultnea varios procesos es
tener varias CPUs (ya sea en una mquina o en varias, en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta
operacin consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el
primero sin que se entere de nada.
El multiproceso no es algo difcil de entender: ms procesadores significa ms potencia
computacional. Un conjunto de tareas puede ser completado ms rpidamente si hay varias
unidades de proceso ejecutndolas en paralelo. Esa es la teora, pero otra historia es la prctica,
como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del
hardware como del software.

Es necesario conocer ampliamente como estn interconectados dichos procesadores, y la forma
en que el cdigo que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software
que aproveche al mximo sus prestaciones.






figura 1. Ejemplo de multiprocesos




~ 30 ~

3.4.- DISEO DE SOFTWARE DE CLIENTE-SERVIDOR

La arquitectura cliente-servidor es una forma de dividir las responsabilidades de un Sistema de
Informacin separando la interfaz de usuario (Nivel de presentacin) de la gestin de la
informacin (Nivel de gestin de datos).
Esta arquitectura consiste bsicamente en que un programa, el Cliente informtico realiza
peticiones a otro programa, el servidor, que les da respuesta.
Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es
ms ventajosa en un sistema multiusuario distribuido a travs de una red de computadoras.
La arquitectura cliente-servidor sustituye a la arquitectura monoltica en la que no hay distribucin,
tanto a nivel fsico como a nivel lgico.
Ventajas de la arquitectura cliente-servidor

Centralizacin del control: los accesos, recursos y la integridad de los datos son controlados por
el servidor de forma que un programa cliente defectuoso o no autorizado no pueda daar el
sistema.

Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado.

Se reduce el trfico de red considerablemente. Idealmente, el cliente se comunica con el servidor
utilizando un protocolo de alto nivel de abstraccin como por ejemplo SQL.








figura 2. Modelo cliente- Servidor
~ 31 ~

3.5.- DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA


Estos recursos tcnicos suelen catalogarse en:
- Infraestructura.
-Plataforma.
-Comunicaciones.
-Datos.
- Software:
- Aplicaciones.
-Interfaces.
-Servicios.
- Seguridad.
Pero no olvidemos que detrs del sistema operativo hay personas que lo usan y los gestionan. El
factor humano ser fundamental como nos cuidaremos de recordar a lo largo del todo el diseo.

Disear un sistema distribuido es crear aplicaciones de software que, utilizando servicios y
ayudndose de la conectividad, participen y se integren en este entorno de forma transparente a
las plataformas de proceso y de almacenamiento de datos, dotndolas de los recursos necesarios
para gestionarse de forma integrada con el resto del sistema distribuido.
Los servicios permitirn usar todos los recursos tcnicos y el sistema distribuido resulto ante no
ser nada ms, ni nada menos, que un conjunto de servicios que interpelan entre ellos
colaborando para cumplir los objetivos que se han establecido para el sistema.

Los sistemas distribuidos que se diseen y construyan deben estar alineados con los objetivos de
negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compaa y permitir el
mayor rendimiento con el menor coste en las estructuras informticas que dan soporte.

Sistemas cuyos componentes hardware y software, que estn en ordenadores conectados en red,
se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un
objetivo. Se establece la comunicacin mediante un protocolo prefijado por un esquema cliente-
servidor.
Caractersticas:
Concurrencia.- Esta caracterstica de los sistemas distribuidos permite que los
recursosdisponibles en la red puedan ser utilizados simultneamente por los usuarios y/o agentes
que interactan en la red.
Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los
diferentes componentes para la realizacin de una tarea, no tienen una temporizacin general, esta
ms bien distribuida a los componentes.

Fallos independientes de los componentes.- Cada componente del sistemapuede fallar
independientemente, con lo cual los dems pueden continuar ejecutando sus acciones. Esto
permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua
trabajando.
Evolucin:
Procesamiento central (Host).- Uno de los primeros modelos de ordenadores interconectados,
llamados centralizados, donde todo el procesamiento de la organizacin se llevaba a cabo en una
~ 32 ~

sola computadora, normalmente un Mainframe, y los usuarios empleaban sencillos ordenadores
personales.
Los problemas de este modelo son:
Cuando la carga de procesamiento aumentaba se tena que cambiar el hardware del Mainframe,
lo cual es ms costoso que aadir ms computadores personales clientes o servidores que
aumenten las capacidades.

El otro problema que surgi son las modernas interfases grficas de usuario, las cuales podan
conllevar a un gran aumento de trfico en los medios de comunicacin y por consiguiente podan
colapsar.

~ 33 ~

3.6.- DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL

El software de tiempo real est muy acoplado con el mundo externo, esto es, el software de tiempo
real debe responder al mbito del problema en un tiempo dictado por el mbito del problema.
Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy
rigurosas, el diseo del software esta conducido frecuentemente, tanto por la arquitectura del
hardware como por la del software, por las caractersticas del sistema operativo, por los requisitos
de la aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo.

La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos
nosotros. Las computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto
de gasolina de nuestras ultimas generaciones de coches y programar a nuestros aparatos.

Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de
computacin de tiempo real. La computadora esta controlando algo que interactua con la realidad
sobre una base de tiempo de hecho, el tiempo es la esencia de la interaccin.

Los sistemas de tiempo real generan alguna accin en respuesta a sucesos externos. Para realizar
esta funcin, ejecutan una adquisicin y control de datos a alta velocidad bajo varias ligaduras de
tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real
estn frecuentemente dedicados a una nica aplicacin.
Durante muchos aos, los principales consumidores de sistemas de tiempo real eran militares.
Sin embargo, hoy la significativa reduccin del coste del hardware ha hecho posible para la
mayora de las compaas, proporcionar sistemas (y productos) de tiempo real para diversas
aplicaciones, que incluyen control de procesos, automatizacin industrial, investigacin medica y
cientfica, grficos de computadoras, comunicaciones locales y de largo alcance, sistemas
aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentacin industrial.
Consideraciones Sobre los Sistemas Como cualquier sistema basado en computadora, un sistema
de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, par
conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento.
El problema para los sistemas de tiempo real es realzar la asignacin importante como la funcin,
pero las decisiones de asignacin relativas al rendimiento son frecuentemente difciles de hacer
con seguridad.

Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un
hardware especial para hacer el trabajo?

Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de
interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto,
cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el
ingeniero de sistemas de tiempo real.
~ 34 ~

UNIDAD 4 SEGURIDAD EN INGENIERA DE SOFTWARE

4.1.- SEGURIDAD DEL SOFTWARE

La Ingeniera del Software todava no es capaz de brindar un mecanismo para implementar
adecuadamente la seguridad: los lenguajes tienen primitivas inseguras, el cdigo relativo a la
seguridad es siempre un cdigo confuso y complejo debido a tcnicas de abstraccin insuficientes,
etc. Estos problemas son los objetivos que promete satisfacer el nuevo paradigma de
Programacin Orientada a Aspectos (POA). Por lo tanto, en este trabajo, analizamos la aplicacin
de la POA como solucin a los problemas de la seguridad en el software.

El concepto de la seguridad en los sistemas de software es un rea de investigacin que ha
pasado a ser vital dentro de la Ingeniera de Software. Con el crecimiento de Internet, y otras
aplicaciones sobre redes, como el comercio electrnico, correo electrnico, etc., la posibilidad de
ataques se ha incrementado notablemente, como tambin lo han hecho las consecuencias
negativas de estos ataques.

En este sentido, existe un nuevo paradigma de programacin, la programacin orientada a
aspectos (POA), el cual al permitir encapsular requerimientos o conceptos tpicamente no
funcionales, como la seguridad, se convierte en una herramienta atractiva para el desarrollo de
software seguro. La POA nos permitira encapsular las polticas de seguridad de forma separada e
independiente del resto del sistema, con las consecuentes ventajas que esto implica.

Nuestro trabajo apunta entonces a investigar la aplicabilidad de la POA a la seguridad en software,
al considerarlo como la alternativa ms viable y prometedora en pos de lograr software seguro.


Problemtica actual de la seguridad en el software.

Los puntos dbiles ms importantes de la Ingeniera de Software con respecto a la seguridad
pueden ser clasificados en dos grandes categoras:

Fallas para implementar software seguro.
Fallas para implementar seguridad en el software.


Fallas para implementar seguridad en el software

En la actualidad, el desarrollador de software que quiera incorporar seguridad a su sistema se
enfrentar con la difcil realidad de las tcnicas de programacin tradicionales, y tambin, con una
Ingeniera de Software que recin est aprendiendo sobre la seguridad.

Tpicamente la seguridad es considerada como un requerimiento no funcional. Luego, debido a los
problemas de planificacin y presupuesto, la seguridad slo es tenida en cuenta una vez que los
requerimientos funcionales son obtenidos. Esto conduce a que la seguridad sea considerada como
un concepto afterthougth, y que se incorpore tardamente al sistema. Esto lleva a una
implementacin pobre, ineficiente, e inadecuada de la seguridad. Tambin, la mayora de las
metodologas de diseo y herramientas dedicadas a la seguridad trabajan de esta forma, como
herramientas afterthougth (ver seccin de Trabajo Relacionado).


~ 35 ~

Objetivos para un software seguro

En pos de conseguir un software seguro, se debe dejar claro qu se entiende por seguridad, para
as luego poder establecer requisitos mnimos que debe satisfacer un sistema que pretenda ser
considerado seguro.















Figura 4. 1. Software de seguridad.

~ 36 ~

4.2.- SEGURIDAD EN EL SIGLO DE DESARROLLO DE SOFTWARE.

Est comprobado que cunto ms temprano se encuentre una falla de seguridad en el ciclo de vida
del desarrollo de software, ms rpida y econmica ser su mitigacin. Cul es el rumbo a
seguir?
Las buenas prcticas indican la conveniencia de incluir seguridad de la informacin desde el
principio y a lo largo de todas las etapas del ciclo de vida de desarrollo, conocido como SDLC por
ser las siglas en ingls de Software Development Life Cicle.

Estas etapas pueden variar segn la modalidad de cada organizacin, pero a grandes rasgos son
las siguientes: anlisis de requerimientos, diseo funcional y detallado, codificacin, testing/QA,
implementacin/puesta en produccin.

Seguridad en el anlisis de requerimientos

En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrn impacto en los
aspectos de seguridad de la aplicacin. Algunos de ellos son: requerimientos de complace con
normativas locales o internacionales (ej.: PCI, SOX, A 4609, etc.), tipo de informacin que se
transmitir o procesar (ej: Informacin pblica o confidencial, datos personales, datos financieros,
contraseas, datos de pago electrnico, etc.) y requerimientos de registros de auditora (ej: Qu
debe registrar la aplicacin en sus Logs).


Seguridad en el diseo

Antes de comenzar a escribir lneas de cdigo, hay numerosos aspectos de seguridad que deben
ser tenidos en cuenta durante el diseo de la aplicacin. Algunos de ellos son: diseo de
autorizacin
(ej.: Definir los roles, permisos y privilegios de la aplicacin), diseo de autenticacin (aqu se debe
disear el modo en el que los usuarios se van a autenticar, contemplando aspectos tales como los
mecanismos o factores de autenticacin con contraseas, tokens, certificados, etc. posibilidades
de integrar la autenticacin con servicios externos como LDAP, Radius o Active Directory y los
mecanismos que tendr la aplicacin para evitar ataques de diccionario o de fuerza bruta (ej.:
bloqueo de cuentas, implementacin de captchas, etc.), diseo de los mensajes de error y
advertencia, para evitar que los mismos brinden demasiada informacin y que sta sea utilizada
por atacantes y diseo de los mecanismos de proteccin de datos (aqu se debe contemplar el
modo en el que se proteger la informacin sensible en trnsito o almacenada; segn el caso, se
puede definir la implementacin de encripcin, hashes o truncamiento de la informacin).

Una vez que se cuenta con el diseo detallado de la aplicacin, una prctica interesante es la de
realizar sobre el mismo un anlisis de riesgo orientado a software. Existen tcnicas documentadas
al respecto, tales como Threat Modeling. Estas tcnicas permiten definir un marco para identificar
debilidades de seguridad en el software, antes de la etapa de codificacin. Como valor agregado,
del anlisis de riesgo orientado a software se pueden obtener casos de prueba para ser utilizados
en la etapa de Testing/QA.

Seguridad en la codificacin

Una vez concluido el diseo, le toca a los desarrolladores el turno de codificar los distintos
componentes de la aplicacin. Es en este punto en donde suelen incorporarse, por error u omisin,
distintos
Por Pablo Milano, Consultor Cybsec tipos de vulnerabilidades. Estas vulnerabilidades podramos
dividirlas en dos grandes grupos a saber: vulnerabilidades clsicas y vulnerabilidades funcionales.
Las primeras son bien conocidas y categorizadas.
~ 37 ~


Ejemplo de estas vulnerabilidades son las presentes en el OWASP Top 10 (Vulnerabilidades de
inyeccin, Cross Site Scripting, errores en manejo de sesiones, etc.) como as tambin otras
vulnerabilidades no ligadas directamente con las aplicaciones WEB, como desbordamiento de
buffer, denegacin de servicio, etc. Los Frameworks de desarrollo de aplicaciones son una buena
ayuda en este punto, ya que ofician de intermediario entre el programador y el cdigo, y permiten
prevenir la mayora de las vulnerabilidades conocidas. Ejemplos de estos frameworks son Struts,
Ruby on Rails y Zope.

Vulnerabilidades funcionales son aquellas ligadas especficamente a la funcionalidad de negocio
que posee la aplicacin, por lo que no estn previamente categorizadas. Algunos ejemplos
ilustrativos de este tipo de vulnerabilidad son los siguientes: una aplicacin de banca electrnica
que permite realizar transferencias con valores negativos, un sistema de subastas que permite ver
los valores de otros oferentes, un sistema de venta de entradas para espectculos que no impone
lmites adecuados a la cantidad de reservas que un usuario puede hacer.

Testing / QA de seguridad

Tradicionalmente, la labor del equipo de Testing/QA fue la de encontrar y reportar errores
funcionales de la aplicacin. Para esto, se desarrollan casos de test basados en la funcionalidad
esperada.
A esto denominamos testing funcional y bsicamente consiste en validar que la aplicacin haga lo
que se esperaba que hiciera. Sucede que habitualmente hay un desfasaje entre el diseo original
de la aplicacin (lo que se espera que haga) y la implementacin real (lo que realmente hace).
Aqu surgen 3 reas bien definidas: lo que fue definido y la aplicacin hace, lo que fue definido y la
aplicacin no hace (errores funcionales) y lo que no fue definido pero la aplicacin hace.

Es en este ltimo grupo, en donde habitualmente estn las vulnerabilidades, y el testing funcional
clsico no es capaz de encontrarlas. Por este motivo se necesitan nuevas tcnicas para explorar lo
desconocido. El testing de seguridad se basa principalmente en probar la aplicacin con
escenarios no planificados, incluyendo valores mutados, fuera de rango, de tipo incorrecto o
malformados, acciones fuera de orden, etc.

Existen herramientas automticas que pueden ayudar al analista de QA en la bsqueda de errores.
Las mismas son tiles por su velocidad y capacidad de automatizacin, pero pueden causar falsos
positivos, y por lo general no son buenas detectando vulnerabilidades funcionales. Es por esto que
los mejores resultados resultan de la combinacin de tcnicas automticas y manuales.


Implementacin / Puesta en produccin

Una mala configuracin al momento de implementar la aplicacin podra echar por tierra toda la
seguridad de las capas anteriores. Tanto la aplicacin como el software de base deben
configurarse de manera segura al momento de poner el software en produccin. En este punto se
deben contemplar tareas tales como: cambio de usuarios y contraseas iniciales o por defecto,
borrado de datos de prueba y cambio de permisos de acceso. Es tambin importante mantener
una correcta separacin de los ambientes de desarrollo, testing y produccin y procedimientos de
traspaso seguro de uno a otro de estos ambientes.



4.3.- CONFIABILIDAD DE SOFTWARE.

~ 38 ~

La confiabilidad de software significa que un programa particular debe de seguir funcionando en la
presencia de errores. Los errores pueden ser relacionados al diseo, a la implementacin, a la
programacin, o el uso de errores. As como los sistemas llegan a ser cada vez ms complejos,
aumenta la probabilidad de errores. Como mencionamos, es increblemente difcil demonstrar que
un sistema sea seguro. Ross Anderson dice que la seguridad de computacin es como programar
la computadora del Satn. Software seguro debe de funcionar abajo de un ataque. Aunque casi
todo el software tenga errores, la mayora de los errores nunca sern revelados debajo de
circunstancias normales. Un atacante busca esta debilidad para atacar un sistema.

La confiabilidad del software se refiere a la precisin con la que una aplicacin proporciona, sin
errores, los servicios que se establecieron en las especificaciones originales. El diseo para
favorecer la confiabilidad, adems de referirse al tiempo de funcionamiento de la aplicacin antes
de que se produzca algn error, est relacionado tambin con la consecucin de resultados
correctos y con el control de la deteccin de errores y de la recuperacin para evitar que se
produzcan errores. Se producen errores en la aplicacin por distintos motivos: Comprobacin
inadecuada, Problemas relacionados con cambios en la administracin, Falta de control y anlisis
continuados. Errores en las operaciones, Cdigo poco consistente, Ausencia de procesos de
diseo de software de calidad, Interaccin con aplicaciones o servicios externos. Condiciones de
funcionamiento distintas (cambios en el nivel de uso, sobrecargas mximas), Sucesos inusuales
(errores de seguridad, desbordamientos en la difusin), Errores de hardware (discos,
controladores, dispositivos de red, servidores, fuentes de alimentacin, memoria, CPU).
Problemas de entorno (red elctrica, refrigeracin, incendios, inundaciones, polvo, catstrofes
naturales).


~ 39 ~


4.4.- INGENIERA DE SEGURIDAD.

La Ingeniera de la seguridad es una rama de la ingeniera, que usa todo tipo de ciencias para
desarrollar los procesos y diseos en cuanto a las caractersticas de seguridad, controles y
sistemas de seguridad. La principal motivacin de esta ingeniera ha de ser el dar soporte de tal
manera que impidan comportamientos malintencionados.
El campo de esta ingeniera puede ser muy amplio, podra desarrollarse en muchas tcnicas:
Equipos: Como el diseo de cerraduras, cmaras, sensores,...
Procesos: polticas de control, procedimientos de acceso,...
Informtico: control de passwords, criptografa,...
Uno de los pioneros en la Ingeniera de seguridad como un campo de estudio es Ross Anderson.

En tanto el e-business se expande en el mercado, el aumento en los puntos de acceso de las
redes de las compaas las hace ms vulnerables a los ataques y las posibilidades de robo y
sabotaje de los activos digitales se vuelve ms factible. Si a ello agregamos un marco legal poco
claro, la participacin de terceros en los proyectos, el desarrollo de aplicaciones con cada vez
mayor distribucin de la capacidad de procesamiento y el deseo de los usuarios finales de
desarrollar y operar sus propios sitios web, los potenciales problemas de seguridad y control
aumentan notoriamente.


Los profesionales de e-business de Price wter house Coopers combinan experiencia en control y
seguridad con un extenso conocimiento de las tecnologas emergentes. Ofrecemos a las
compaas soluciones que ayudan a proteger sus activos digitales y operaciones internas
apoyndolas en el diseo, construccin, testeo e implantacin de los controles que se requieran, a
la vez que con aplicaciones seguras (correo, servidores de web apoyados por procesos de back
office de un ERP, y tecnologas informticas seguras para procesamiento distribuido),
proporcionamos seguridad en todos los procesos de la cadena de valor del e-business.


~ 40 ~

GLOSARIO
Un modelo de negocio es un delicado proceso de ajuste, basado en la construccin de
recursos estratgicos que permiten generar ms ofertas e ingresos.

BPMN: Business Process Modeling Notacion.


~ 41 ~

BIBLIGRAFIA

Benot Demil
1

Institut d Administration des Entreprises de Lille

benoit.demil@iae.univ-lille1.fr

Xavier Lecocq
Institut d Administration des Entreprises de Lille
IESEG School of Management

Xavier.Lecocq@iae.univ-lille1.fr
Fecha de recepcin y acuse de recibo: 19 de mayo de 2009. Fecha inicio proceso de evaluacin:
19 de mayo de 2009. Fecha primera evaluacin: 2 de junio de 2009. Fecha de aceptacin: 6 de
julio de 2009.