INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA

INGENIERA EN SISTEMAS COMPUTACIONALES

INGENIERA DE SOFTWARE
SEXTO SEMESTRE GRUPO A
DOCENTE: ING. INS LEN FLOREZ

ANTOLOGIA
ALUMNO: JESUS ALONSO AVELINO ROJAS















1

NDICE
INTRODUCCIN ................................................................................................................................... 2
UNIDAD 1- MODELADO DE NEGOCIOS ............................................................................................... 3
1.1 EVOLUCION DEL MODELADO DE NEGOCIOS ............................................................................ 3
1.2 COMPONENTES DEL MODELADO DE NEGOCIOS ...................................................................... 6
1.3 ORIENTACIONES DEL MODELO DE NEGOCIOS ........................................................................ 11
1.4 BPMN....................................................................................................................................... 15
UNIDAD 2 - METODOLOGAS DE DESARROLLO ................................................................................. 18
2.1 MODELO EN CASCADA ............................................................................................................ 18
2.2 MODELO CONSTRUCTIVO DE PROTOTIPOS ............................................................................ 20
2.3 MODELO DRA .......................................................................................................................... 21
2.4 EL MODELO INCREMENTAL ..................................................................................................... 23
2.5 EL MODELO ESPIRAL ................................................................................................................ 24
2.6 EL MODELO ESPIRAL WINWIN ................................................................................................ 26
2.7 DESARROLLO BASADO EN COMPONENTES ............................................................................. 28
UNIDAD 3- ARQUITECTURAS DE SOFTWARE ..................................................................... 29
3.1 ARQUITECTURA DE SOFTWARE ............................................................................................... 29
3.2 DESCOMPOSICIN MODULAR ................................................................................................ 30
3.3 PATRONES DE DISEO ............................................................................................................. 31
3.4 DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR .......................................... 34
3.5 DISEO DE SOFTWARE DE CLIENTE SERVIDOR ................................................................... 36
3.6 DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA ...................................................... 37
3.7 DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL ARQUITECTURA ..................... 38
UNIDAD 4: SEGURIDAD EN INGENIERA DE SOFTWARE ................................................. 39
4.1 SEGURIDAD DE SOFTWARE ..................................................................................................... 39
4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE ................................................... 42
4.3 CONFIABILIDAD DEL SOFTWARE ............................................................................................. 45
4.4 INGENIERA DE SEGURIDAD .................................................................................................... 46
CONCLUSIN ................................................................................................................................ 48
BIBLIOGRAFIAS ............................................................................................................................ 49




2

INTRODUCCIN
Los cambios tecnolgicos, econmicos, sociales y de otras ndoles que se estn
produciendo continuamente en nuestro entorno, hacen que empresas que,
tradicionalmente, han gozado de gran xito, se enfrenten en la actualidad a situaciones
econmicas muy delicadas en las que peligra su supervivencia, ms all incluso de su
crecimiento orgnico.
Si bien el entorno de crisis global en el que nos encontramos, ha tenido un peso
especfico importante en esta situacin, debemos tener presente que si realizsemos un
anlisis del funcionamiento de las PYMEs a nivel operativo, el diagnostico final en muchas
de ellas sera comn: un modelo de negocio obsoleto.
Lo primero que necesitamos es una definicin comn y clara de este concepto, modelo de
negocio, del que tanto se oye hablar ltimamente, para poder as saber de qu hablamos
y bajo que prisma debemos observarlo. Un modelo de negocio son una serie de
elementos clave en los que influyen en el desarrollo de nuestra actividad proposicin de
valor, segmento de mercado al que nos dirigimos, estructura de costes, y las relaciones
existentes entre ellos.
En s, un modelo de negocio describe los fundamentos en base a los cuales una
organizacin crea, distribuye y captura valor.
Para determinar o analizar todos los aspectos de un sistema o de un software podemos
utilizar las diferentes metodologas de desarrollo de software ya que cada una de ellas te
puedes guiar hasta tu meta o objetivo, cada una de ellas caracterizada por su velocidad
de anlisis y uso mnimo de recursos pero con diferentes etapas de desarrollo,
Al tomar en cuenta todos los aspectos podemos determinar la estructura de nuestro
software, de cmo va a estar constituido, y como va a hacer la relacin con el usuario.
Tambin hay que tomar en cuenta muchos aspectos de comos estar constituido con toda
la organizacin o empresa.





3

UNIDAD 1- MODELADO DE NEGOCIOS

1.1 EVOLUCION DEL MODELADO DE NEGOCIOS
Tradicionalmente, el modelo de una Compaa del sector manufactura mantena
integralmente sus procesos dentro del negocio, es decir, no ceda ningn proceso a
terceras partes. En tal sentido, tpicamente encontrbamos compaas con todos sus
procesos de procura o abastecimiento sincronizados y operados por ella misma.
Figura N 1. Esquema tradicional de los proceso de negocio/sector manufactura
As, la cadena de suministros podra, frecuentemente, haber estado alineada con los
procesos de: desarrollo de productos, mercadeo, promocin, y venta. Adicionalmente, las
funciones, tales como Finanzas, Tecnologa de Informacin, y Comunicaciones, apoyaban
al ncleo o core de procesos del negocio.

A partir de los aos 80s y hasta mediados de los 90s, los modelos de procesos de
negocio en las compaas eran actualizados dependiendo de los resultados de estudios
basados en Calidad Total, Enfoques tipo Ishikawa, Crculos de Calidad, Re-
ingeniera de Procesos, entre otros. Estos estudios estaban dirigidos a analizar cmo los
procesos y sus relaciones haban sido diseados en una Compaa en particular, sin
eliminar pasos que no agregaban valor y sin remplazarlos por otras actividades que s
agregaran valor.

PROBLEMAS:
Escases de inventario
Cuellos de botella
Falta de capacidad de inventario para responder a la demanda
Mejoramiento en las relaciones con el cliente
En muchas empresas manufactureras, como producto de proyectos de re-ingeniera se
inclua el desarrollo e implantacin de procesos del tipo Just-in-time, en los cuales
existan ciertos indicadores que se disparaban rpidamente y de una manera flexible,


4

sensibilizaban al rea de manufactura y sta responda mediante la ejecucin de sus
procesos y seguidamente se realizaba la carga y transporte del producto terminado o
servicio, para luego continuar con el prximo paso o actividad.
La eliminacin de pasos que no agregaban valor, logrando la reduccin de tiempos en el
ciclo de negocio, y la implantacin de los enfoques o esquemas Just-in-time, era
prioritario para ese entonces. Mediante la adopcin de un esquema basado en el tiempo,
fue reducido el inventario en las compaas, se elev la eficiencia del capital de trabajo, y
se hizo ms eficiente la respuesta al mercado. Sin embargo, este esquema todava
conservaba problemas en cuanto al capital de trabajo, tales como: carencia de
inventarios, cuellos de botellas, fallas de capacidad en los inventarios para responder al
incremento de la demanda. Todo ello conllevaba a una insatisfaccin de la demanda y por
consecuencia las rdenes emanadas de los clientes, no podan ser satisfechas. Esto
deriv en ciertos casos en iniciativas prematuras de contratacin de terceros outsourcing
y automatizacin de procesos.
Desde entonces, se comenz a utilizar un conjunto de servicios y tecnologas, tales como:
la Transferencia Electrnica de Datos (EDI, de sus siglas en ingls: Electronic Data
Interchange) a los fines de conectar eficientemente los elementos de la cadena de
procura, o la tecnologa orientada a la automatizacin de los procesos de manufactura.
Esto haca, en muchos casos, que se potenciaran los problemas en la cadena de procura
y en lugar de resolver los problemas antes indicados, lo que produca era la potenciacin
de los mismos.
Es as como la utilizacin de estos servicios y tecnologas implantadas parcialmente en
los procesos de las cadenas de valor del negocio, hacan que se redujera los tiempos en
la ejecucin de los mismos, pero creaban cuellos de botella en el resto de procesos y
causaban el incremento del capital de trabajo. Como consecuencia de esto, en lo que se
refiere a EDI, en muchos casos, las compaas se limitaban a utilizar esta tecnologa para
ciertas reas con poca complejidad, como el caso del manejo de los depsitos de la
nmina. Sin embargo, el outsourcing de los procesos intent resolver el problema desde
el punto vista ms all de la tecnologa, lo cual hizo que se profundizaran las dificultades,
trayendo como resultado, una vez ms, la re-ingeniera de los procesos. En la Figura se
muestra este tipo de fenmeno relativo a lo prematuro del uso del outsourcing y la
automatizacin.


5

En los aos 90s la mayora de las compaas continuaron afinando los modelos de
procesos del negocio siguiendo el enfoque de sincronizacin de la cadena de procura,
mediante la premisa de compartir la informacin del mercado y la demanda a travs de la
cadena de suministros. En tal sentido, por medio de esta prctica se pudo reducir los
tiempos del ciclo de procesos del negocio, as como los problemas del inventario y el
capital de trabajo. Esto fue acompaado con la utilizacin de sistemas ERP (por sus
siglas en ingls, Enterprise Resource Planning) con el objeto de sincronizar y estandarizar
los procesos de acuerdo a las mejores prcticas y los modelos implcitamente
incorporados en estos sistemas. En consecuencia, la cadena de procura elev su
efectividad, y se sincroniz, aun ms, la demanda de productos y los procesos de
produccin, lo cual deriv en un mejoramiento de la gerencia del modelo de procesos de
negocio.
Con este gran esfuerzo hecho a travs de los sistemas ERP, el desarrollo de un nuevo
modelo de negocio y la re-ingeniera de los procesos para adaptarse a las mejores
prcticas, le permiti a las compaas y a sus gerencias, atacar nuevos mercados y
capitalizar las nuevas oportunidades de negocio. Concurrentemente, las herramientas
Customers Relationship Management - CRM, comenzaron a homogenizar o estandarizar
las relaciones y procesos con los mercados, creando un estrecho vnculo con los ERP.
Evolucin de las compaas en la economa
En la Figura se puede observar, a nivel general, el mejoramiento de la cadena de
procesos de la demanda, al tiempo que los sistemas ERP y las herramientas CRM se
alinean con la cadena de procesos de procura; asimismo, se demuestra la evolucin de
los conceptos y trminos arriba mencionados y a lo largo de los ltimos 25 aos.
Tres son las razones principales que hacen que sea necesario para toda empresa, el
anlisis y la necesidad de evolucin o cambio en el Modelo de Negocio que
tradicionalmente ha definido su funcionamiento:
La primera no es otra que la velocidad actual del mercado. Los ciclos de vida de los
productos o servicios que creamos para aportar algo nuevo al mercado, son cada vez
ms cortos. Aparecen novedades alternativas a gran velocidad y eso nos obliga a una
evolucin continua de nuestro modo de trabajar.



6

En segundo lugar debemos tener presente la competencia intra-industria que existe hoy
en da. Ya no competimos nicamente con productos o servicios similares al nuestro,
ofrecidos por nuestra competencia. Cada da ms aparecen nuevos productos y servicios
que, si bien no son anlogos a los nuestros, si que pueden ser substitutivos de los
mismos. Un ejemplo de fcil comprensin es la situacin que se produce cuando vamos a
comprar regalos y optamos por dispositivos electrnicos en lugar de regalar los
tradicionales bolsos, ropa, perfumes.
Finalmente, la disrupcin en costes que introducen los nuevos modelos de negocio, lo que
les permite crear experiencias en el cliente de un modo real y ms completo. El tomar
posiciones en un mayor nmero de ubicaciones dentro de la cadena de valor de nuestro
producto y servicio, algo posible hoy en da gracias a los avances en las IT, nos permite
diversificar las fuentes de generacin de ingresos ofreciendo al mismo tiempo un conjunto
de servicios alrededor de nuestro producto que crea esa experiencia ms gratificante en
el consumidor. Un ejemplo, en el sector de los juguetes, frente a la existencia de grandes
almacenes que ofrecen productos muy similares y que bsicamente compiten en precios,
existen nuevas propuestas que ofrecen la posibilidad de la creacin de tu propio juguete,
a un precio ms elevado por supuesto, y que estn teniendo mucho xito en mercados
avanzados. Actualmente buscamos ms innovaciones en experiencias que en productos.
Esta realidad motiva que, cada vez ms, sea de vital importancia, tanto para la
sostenibilidad de nuestra empresa como para permitirnos crecer con ella, el anlisis de los
modelos de negocio con los que estamos funcionando para de este modo, comprender
donde nos encontramos y poder hacerlos evolucionar, o transformarlos completamente,
hacia modelos ms eficientes y competitivos.
1.2 COMPONENTES DEL MODELADO DE NEGOCIOS
El modelo de negocio (business model, BM) es el mecanismo mediante el cual un negocio
genera ingresos y beneficios y a su vez, cmo una empresa sirve a sus clientes. Debe de
ser capaz de generar, sobre el papel, un beneficio mutuo tanto para el cliente como para
la empresa y debe de ser explicado en trminos de, cmo mucho, una decena de
elementos clave.
Algunos de los elementos clave son los siguientes:
1. Propuesta de valor:


7

Segn Michael Porter, la propuesta de valor es la mezcla de la comodidad, calidad,
precio, servicio y garanta que la organizacin ofrece a sus clientes. Kaplan y Norton
hablan de cuatro clases amplias de propuestas de valor:
Mejor compra o Menor costo total: Precios econmicos, calidad confiable, servicio rpido.
Liderazgo de producto e innovacin: Los ltimos productos de los lderes de la industria.
Llave en mano: Soluciones a medida para las necesidades y preferencias especficas de
cada cliente.
Cautiverio: El concepto de cliente cautivo fue introducido por Michael Porter. La
organizacin intenta conseguir a una gran cantidad de compradores en una posicin
donde los deja sin posibilidad de continuar sus compras con otro proveedor.
2. Segmento de mercado:
El target o mercado objetivo es el segmento del mercado al que est dirigido un bien, ya
sea producto o servicio. Generalmente, se define en trminos de edad, gnero o variables
socioeconmicas. Hay tres pasos para establecer mercados objetivos:
segmentacin de mercado
seleccin del mercado objetivo
posicionamiento del producto
Las estrategias para acotar un target estn influidas por:
la madurez del mercado
la diversidad de preferencias y necesidades de los consumidores
el tamao de la compaa
la fortaleza de la competencia o la economa
el volumen de ventas requerido para producir beneficios
3. Segmento de no mercado:


8

De la misma manera, el segmento que no es objetivo en un determinado momento debe
de ser conocido y puede convertirse en cliente potencial mediante estrategias de ocano
azul creando mercados sin rivales y llegando a segmentos de mercado en los que antes
no estaba.
4. Alianzas estratgicas:
Las alianzas estratgicas son uniones formales entre dos o ms organizaciones que
tienen como propsito llevar a cabo la formacin de sociedades que ayuden a la
competitividad y al fortalecimiento de las empresas. Son entendidas tambin, como
formas de cooperacin entre algunos de los entes que directamente influyen en su
comportamiento, proveedores, distribuidores, clientes, nuevos participantes, entre otros.
5. Dilogo cliente (mercado son conversaciones):
David Weinberger, Christopher Locke y Doc Searls opinaron en 1998 que los mercados
son conversaciones. El cliente hoy en da opina, critica, comenta, demanda y exige. Las
empresas quieren saber que se dice de ellas pero no participan del dilogo.
En este elemento se analiza si este dilogo es nulo, es decir, si las empresas estn
acostumbradas a la unidireccionalidad de mensajes a un mercado objetivo o sin embargo,
estn ms cerca de relaciones 2.0 en las que existe un verdadero dilogo entre la
empresa y el cliente.
El dialogo con el cliente debe ser:
1. Los mercados son conversaciones.
2. Los mercados consisten de seres humanos, no de sectores demogrficos.
3. Las conversaciones entre seres humanos suenan humanas. Se conducen en una voz
humana.
6. Fidelizacin:
Cmo la empresa convierte cada venta en el principio de la siguiente, es decir, en
conservar al cliente y de esta manera un determinado pblico se mantiene fiel a una
determinada marca
7. Servicio (antes, durante, despus):


9

Cmo orienta la empresa su compromiso de calidad con el cliente. Los servicios que
ofrece antes, durante y despus mientras interacta con su consumidor.
8. Canales de distribucin y presencializacin:
El Canal de distribucin es el circuito a travs del cual los fabricantes (o productores)
ponen a disposicin de los consumidores (o usuarios finales) los productos para que los
adquieran. La separacin geogrfica entre compradores y vendedores y la imposibilidad
de situar la fbrica frente al consumidor hacen necesaria la distribucin (transporte y
comercializacin) de bienes y servicios desde su lugar de produccin hasta su lugar de
utilizacin o consumo. La ventaja competitiva es la flexibilidad y la presencia oportuna en
el mercado.
Los canales tradicionales son los siguientes:
1. Canales de Distribucin Para Productos de Consumo:
- Canal Directo o Canal 1 (del Productor o Fabricante a los Consumidores)
- Canal Detallista o Canal 2 (del Productor o Fabricante a los Detallistas y de stos a los
Consumidores)
- Canal Mayorista o Canal 3 (del Productor o Fabricante a los Mayoristas, de stos a los
Detallistas y de stos a los Consumidores)
- Canal Agente/Intermediario o Canal 4 (del Productor o Fabricante a los Agentes
Intermediarios, de stos a los Mayoristas, de stos a los Detallistas y de stos a los
Consumidores)
2. Canales Para Productos Industriales o de Negocio a Negocio:
- Canal Directo o Canal 1 (del Productor o Fabricante al Usuario Industrial)
- Distribuidor Industrial o Canal 2 (del Productor o Fabricante a Distribuidores Industriales
y de ste al Usuario Industrial)
- Canal Agente/Intermediario o Canal 3 (Del Productor o Fabricante a los Agentes
Intermediarios y de stos a los Usuarios Industriales)


10

- Canal Agente/Intermediario Distribuidor Industrial o Canal 4 (del Productor o
Fabricante a los Agentes Intermediarios, de stos a los Distribuidores Industriales y de
stos a los Usuarios Industriales)
9. Recursos clave: Procesos clave. Arquitectura de valor. Infraestructura:
Las empresas son tan eficientes como lo son sus procesos. La mayora de las empresas
y las organizaciones que han tomado conciencia de esto han reaccionado ante la
ineficiencia que representa las organizaciones departamentales, con sus nichos de poder
y su inercia excesiva ante los cambios, potenciando el concepto del proceso, con un foco
comn y trabajando con una visin de objetivo en el cliente.
En la planificacin estratgica definir cules son esos procesos clave y todos los recursos
humanos, infraestructuras es esencial para la confeccin del modelo de negocio.
10. El retorno del valor (beneficio). PVE, PBE:
Consiste en determinar cul es el beneficio del modelo de negocio. Consiste en la
propuesta de valor para el consumidor, el cul es un elemento subjetivo y el valor objetivo
de coste del producto que ofrece la empresa. El coste de la propuesta de valor, PGE:
Consiste en definir cul es el coste de la propuesta de valor que ofrece la empresa a sus
clientes.
11. El efecto marca:
Las marcas, las enseas, los nombres comerciales estn omnipresentes en nuestro da a
da, en muchas ocasiones el consumidor, el cliente o clienta ya no adquiere un producto o
contrata un servicio solo por el uso o la funcin misma del mismo o por el servicio que le
va a prestar, sino que lo adquiere por el concepto marca y todo lo que con ello lleva
asociado.

12. El efecto plataforma:
Qu plataformas son empleadas por la empresa en la confeccin del modelo de negocios.
Finalmente, la descripcin de cada uno de estos elementos forma en su conjunto el
modelo de negocio de una propuesta de valor de una empresa.


11

1.3 ORIENTACIONES DEL MODELO DE NEGOCIOS
MODELO DE NEGOCIOS
Es el mecanismo por el cual un negocio trata de generar ingresos y beneficios. Es un
resumen de cmo una compaa planifica servir a sus clientes. Implica tanto el concepto
de estrategia como el de implementacin.
El modelo de ingresos debe ser creble, nada sacamos con decirnos mentiras a nosotros
mismos. Las ideas empresariales reciben esta categora gracias a su potencial real de
desarrollo en el mercado y a su rentabilidad. Si su idea no genera ingresos es mejor que
la revise nuevamente antes de llamarla negocio.
Qu contiene:
Cmo seleccionar sus clientes
Cmo define y diferencia sus ofertas de producto
Cmo crea utilidad para sus clientes
Cmo consigue y conserva a los clientes
Cmo sale al mercado (estrategia de publicidad y distribucin)
Cmo define las tareas que deben llevarse a cabo
Cmo configura sus recursos
Cmo consigue el beneficio

A que responde un modelo de negocio..?
Quin es el cliente?
Cul es el valor para el cliente?
Cmo obtenemos dinero en este negocio?
Cul es la lgica econmica que justifica que podemos entregar valor a los
clientes a un costo apropiado?

MODELO VALOR/CLIENTE



12

Se dice que los clientes han evolucionado porque ya no buscan nicamente el precio ms
bajo o la buena calidad de un producto o servicio. En la actualidad, ellos buscan y
premian a quienes les entreguen "valor" por su compra o adquisicin.
Hoy en da, la gran mayora de personas se encuentran ante una amplia variedad de
productos y servicios que pretenden satisfacer una determinada necesidad, ya sea,
ofertando el precio mas bajo del mercado o la mejor calidad. Y es, ante esta situacin
altamente competitiva que surge una pregunta lgica para todos los mercadlogos:
Cmo le hacen las personas para tomar sus decisiones de compra?
La respuesta no es muy sencilla de dar; sin embargo, algunos expertos en la materia
afirman que la mayora de personas basan sus decisiones de compra en "sus
percepciones acerca del valor que proporcionan los distintos productos o servicios"; lo
cual, supera la barrera del precio ms bajo o de mayor calidad.
Por ese motivo, en la actualidad se viene divulgando con mucha asertividad que las
empresas exitosas no entregan productos a cambio de una ganancia, sino ms bien:
Valor a cambio de una utilidad.
Cmo Perciben los Clientes el Valor de un Producto o Servicio?
Los clientes, en su gran mayora, perciben el "valor" de un producto o servicio poniendo
dos cosas en la balanza:
Por un lado: Todos los beneficios que obtienen al poseer o usar un producto o servicio.
Y por otro: El precio o todos los costos que implica su adquisicin, consumo o utilizacin.

La diferencia de esta operacin (beneficio menos precio), llega a representar el "valor"
que percibe el cliente; el cual, es comparado con las otras ofertas existentes en el
mercado.
Para comprender mejor esta afirmacin, recordemos una frmula (bsica) que utilizan los
departamentos de contabilidad para determinar si la empresa gana o pierde dinero al
realizar una operacin:
Ingresos totales - Costos totales = Utilidad para la empresa


13

De manera parecida, la mayora de clientes realizan una operacin (consciente o
inconsciente, racional o irracional) para determinar si ganan o pierden al realizar una
compra, utilizando la siguiente frmula:
Beneficios Totales - Costos Totales = Utilidad para el cliente (valor)
Como es de suponer, el cliente se inclinar por la marca que le otorgue el mayor margen
de utilidad (valor), dejando de lado las opciones que ofrecen los otros competidores.
Un detalle muy importante dentro de este anlisis, es que la percepcin acerca de los
"beneficios" que ofrece un producto o servicio vara de cliente a cliente. Por ejemplo,
algunos le pondrn ms nfasis a los beneficios funcionales, como ser: tamao, peso,
forma, facilidad de uso, durabilidad, etc. Otros, se inclinarn ms hacia los beneficios
estticos, por ejemplo: Cun atractivo es el producto, cun simpticas son las personas
que dan el servicio, etc. Tambin, habr otro grupo que se incline ms por los beneficios
psicolgicos, como ser: Tranquilidad, seguridad, autoestima, aceptacin, sentido de
pertenencia, etc. Otro grupo de personas se inclinarn ms hacia los beneficios basados
en los servicios que se ofrecen como un plus, por ejemplo: Capacitacin, garantas,
mantenimientos, actualizaciones, etc.
De igual manera, el factor "precio" no se refiere nicamente al precio de lista o de oferta
que tiene un producto o servicio, sino que implica varios aspectos adicionales, tal y como
lo observ Adam Smith hace ms de 200 aos: "El precio real de algo es la maraa de
dificultades para adquirirlo". Por tanto, el costo total o el precio real para el consumidor
implica por lo general, lo siguiente: el precio monetario, el costo del tiempo que se emplea
para tomar una decisin, el costo psicolgico y el costo de la energa o del esfuerzo.
Ahora, considerando el contexto actual basado en la entrega de valor, se plantean las
siguientes premisas para las "empresas inteligentes":
1ro. Determinar el conjunto de beneficios que oferta la empresa: Producto, servicios,
personal, imagen, etc...
2do. Determinar el precio real o costo total de cada producto o servicio: Precio monetario,
costo del tiempo, costo psicolgico y costo de energa.


14

3ro. Determinar (mediante una investigacin de mercados) como perciben los clientes
actuales y potenciales el valor de cada producto o servicio (de los que oferta la empresa y
la competencia).
4to. Comparar el "valor percibido por el cliente" de los productos o servicios que ofrece la
empresa con los que ofrece la competencia.
5to. Si la empresa se encuentra en desventaja, tiene tres alternativas para remontar esa
situacin: A) Incrementar los beneficios para el consumidor, B) Disminuir el costo total, C)
Hacer ambas cosas: incrementar los beneficios y disminuir el costo total.
Importancia de la Percepcin de "Valor", en la Actualidad
Hoy en da, los mercadlogos estn emprendiendo una carrera por la "creacin de valor";
el cual, se extiende ms all de slo ofrecer los precios ms bajos del mercado. Esta
nueva tendencia se produce porque han comprendido que para el cliente, valor significa
mucho ms que la cantidad de dinero cobrada por un producto.
Otra prueba de la creciente importancia que viene teniendo el concepto de "valor
percibido por el cliente" es que varias empresas lo estn considerando como una
"variable" a usar para fijar los precios de sus productos o servicios. Por ejemplo, existen
productos cuyo principal beneficio (bajo la percepcin de sus clientes) es el status; por
tanto, su precio ser ms elevado que el precio promedio del mercado y sus servicios
sern ms especializados, solo para mantener ese beneficio psicolgico en su pblico
objetivo.
MODELO A LA ACTIVIDAD / ROL
Es un modelo organizativo basado en procesos puede ayudar a mejorar la productividad
de la organizacin en su conjunto.
Un proceso es un conjunto de actividades interrelacionadas orientadas a cumplir un
objetivo especfico.
Los procesos comparten las siguientes caractersticas:

Los procesos son cuantificables y se basan en el rendimiento.


15

Tienen resultados especficos.
Los procesos tienen un cliente final que es el receptor de dicho resultado.
Se inician como respuesta a un evento.
El Centro de Servicios y la Gestin del Cambio son dos claros ejemplos de funcin y
proceso respectivamente.
Sin embargo, en la vida real la dicotoma entre funciones y procesos no siempre es tan
evidente pues puede depender de la estructura organizativa de la empresa u organismo
en cuestin.
Otro concepto ampliamente utilizado es el de rol.
Un rol es un conjunto de actividades y responsabilidades asignada a una persona o un
grupo. Una persona o grupo puede desempear simultneamente ms de un rol.
Hay cuatro roles genricos que juegan un papel especialmente importante en la gestin
de servicios TI:
Gestor del Servicio: es el responsable de la gestin de un servicio durante todo su ciclo de
vida: desarrollo, implementacin, mantenimiento, monitorizacin y evaluacin.
Propietario del Servicio: es el ltimo responsable cara al cliente y a la organizacin TI de
la prestacin de un servicio especfico.
Gestor del Proceso: es el responsable de la gestin de toda la operativa asociada a un
proceso en particular: planificacin, organizacin, monitorizacin y generacin de
informes.
Propietario del Proceso: es el ltimo responsable frente a la organizacin TI de que el
proceso cumple sus objetivos. Debe estar involucrado en su fase de diseo,
implementacin y cambio asegurando en todo momento que se dispone de las mtricas
necesarias para su correcta monitorizacin, evaluacin y eventual mejora.
1.4 BPMN
NOTACIN DE MODELADO DE PROCESOS DE NEGOCIO
Modelar el proceso de negocio es una parte esencial de cualquier proceso de desarrollo
de software. Permite al analista capturar el esquema general y los procedimientos que


16

gobiernan el negocio. Este modelo provee una descripcin de dnde se va a ajustar el
sistema de software considerado dentro de la estructura organizacional y de las
actividades habituales. Tambin provee la justificacin para la construccin del sistema
de software al capturar las actividades manuales y los procedimientos automatizados
habituales que se incorporarn en nuevo sistema, con costos y beneficios asociados.
Como un modelo preliminar del negocio, permite al analista capturar los eventos, las
entradas, los recursos y las salidas ms importantes vinculadas con el proceso de
negocio.
Es posible construir un modelo completamente trazable mediante la posterior conexin de
elementos de diseo (tales como los casos de uso) al modelo de negocio a travs de
conectores de implementacin, desde la generalidad del proceso de negocio a los
requisitos funcionales y eventualmente a los artefactos de software que se construirn
realmente.
Por el hecho de que el modelo de procesos de negocio normalmente es ms amplio que
la parte de sistema computacional considerada, tambin permite al analista identificar
claramente qu est dentro del alcance del sistema propuesto y qu se implementar de
otras formas (por ejemplo: un proceso manual).
Notacin del Modelado de Proceso
Un modelo de proceso de negocio tpicamente define los siguientes elementos:
El Objetivo o el motivo del proceso
Las Entradas especficas
Las Salidas especficas
Los Recursos consumidos
La secuencia de las Actividades; y
Los Eventos que dirigen el proceso

El proceso de negocio:


17

Puede afectar a ms de una unidad organizacional. Tiene un impacto horizontal en la
organizacin. Crea algn tipo de valor para el cliente. Los clientes pueden ser internos o
externos.
El Proceso de Negocio
Un proceso de negocio es una coleccin de actividades diseadas para producir una
salida especfica para un cliente o un mercado en particular. Esto implica un fuerte
nfasis en cmo se realiza el trabajo dentro de una organizacin, en contraposicin con
un enfoque del producto en qu se produce. Por lo tanto, el proceso es una secuencia
especfica de actividades de trabajo a travs del tiempo y del espacio, con un inicio, un
final y unas entradas y salidas claramente definidas: una estructura para la accin.
Creacin de Modelos dirigidos por la Arquitectura (MDA)

Tipos de Procesos

BPM - Nuevo paradigma?
(Gestin por Procesos).

Es una forma de abordar la comunicacin entre los clientes / usuarios y los
tcnicos
Antes, la gente de negocios hablaba de procesos, roles, personas, etc.
Los tcnicos hablaban de sistemas, mquinas, datos, etc.
Ahora, con BPM todos hablan de lo mismo.

La tecnologa BPMS reduce la distancia con los sistemas, mquinas y aplicaciones
que automatizan los procesos.
Lenguaje pensado para los no tcnicos.




18

Modelos de Procesos.
Representacin abstracta grfica- de los procesos de una organizacin
Muestra cmo y quin efecta las actividades que generan valor para la
organizacin Muestran:
Los actores involucrados en los procesos
Cules son las actividades operativas
Qu actividades son ejecutables y por quin
Entradas y salidas de las actividades
Secuencia de los actividades
Recursos consumidos
Los eventos que dirigen el proceso.

BPMN diagramas.
BPMN define diagramas de procesos de negocios basados en la tcnica de diagramas
de flujo, adaptados para graficar las operaciones de los procesos de la organizacin
Se compone de un conjunto de elementos grficos que facilitan un diagrama
entendible tanto por audiencias de negocios como tcnicas.
Objetos de Flujo.

UNIDAD 2 - METODOLOGAS DE DESARROLLO

2.1 MODELO EN CASCADA
Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal
secuencial sugiere un enfoque5 sistemtico, secuencial, para el desarrollo del software
que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin,
pruebas y mantenimiento. La Figura 2.4 muestra el modelo lineal secuencial para la
ingeniera del software. Modelado segn el ciclo de ingeniera convencional, el modelo
lineal secuencial comprende las siguientes actividades: Ingeniera y modelado de
Sistemas/Informacin.


19

Como el software siempre forma parte de un sistema ms grande (o empresa), el trabajo
comienza estableciendo requisitos de todos los elementos del sistema y asignando al
software algn subgrupo de estos requisitos. Esta visin del sistema es esencial cuando
el software se debe interconectar con otros elementos como hardware, personas y bases
de datos. La ingeniera y el anlisis de sistemas comprenden los requisitos que se
recogen en el nivel del sistema con una pequea parte de anlisis y de diseo. La
ingeniera de informacin abarca los requisitos que se recogen en el nivel de empresa
estratgico y en el nivel del rea de negocio.


Anlisis de los requisitos del software. El proceso de reunin de requisitos se intensifica y
se centra especialmente en el software. Para comprender la naturaleza del (los)
programa(s) a construirse, el ingeniero (analista) del software debe comprender el
dominio de informacin del software (descrito en el Captulo 1 l), as como la funcin
requerida, comportamiento, rendimiento e interconexin. Diseo. El diseo del software es
realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de
programa: estructura de datos, arquitectura de software, representaciones de interfaz y
detalle procedimental (algoritmo). El proceso del diseo traduce requisitos en una
representacin del software donde se pueda evaluar su calidad antes de que comience la
codificacin. Generacin de cdigo. El diseo se debe traducir en una forma legible por la
mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el
diseo de una forma detallada, la generacin de cdigo se realiza mecnicamente.
Pruebas. Una vez que se ha generado el cdigo, comienzan las pruebas del programa. El
proceso de pruebas se centra en los procesos lgicos internos del software, asegurando
que todas las sentencias se han comprobado, y en los procesos externos funcionales; es
decir, realizar las pruebas para la deteccin de errores y asegurar que la entrada definida
produce resultados reales de acuerdo con los resultados requeridos. Mantenimiento. El
software indudablemente sufrir cambios despus de ser entregado al cliente (una
excepcin posible es el software empotrado). Se producirn cambios porque se han
encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de
su Entorno externo (por ejemplo: se requiere un cambio debido a un sistema operativo o
dispositivo perifrico nuevo), o porque el cliente requiere mejoras funcionales o de


20

rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las
fases precedentes a un programa ya existente y no a uno nuevo.

2.2 MODELO CONSTRUCTIVO DE 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 (Fig.2.5) comienza con la recoleccin de requisitos. El
desarrollador y el cliente encuentran 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.

El prototipo puede servir como primer sistema. El que Brooks recomienda tirar. Aunque
esta puede ser una visin idealizada. Es verdad que a los clientes y a los que desarrollan
les gusta el paradigma de construccin de prototipos. A los usuarios les gusta el sistema
real y a los que desarrollan les gusta construir algo inmediatamente. Sin embargo, la
construccin de prototipos tambin puede ser problemtica por las siguientes razones: 1.
El cliente ve lo que parece ser una versin de trabajo del software, sin tener conocimiento
de que el prototipo tambin est junto con el chicle y el cable de embalar, sin saber que
con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software


21

global o la facilidad de mantenimiento a largo plazo. Cuando se informa de que el
producto se debe construir otra vez para que se puedan mantener los niveles altos de
calidad, el cliente no lo entiende y pide que se apliquen a n o s pequeos ajustes>>para
que se pueda hacer del prototipo un producto final. De forma demasiado frecuente la
gestin de desarrollo del software es muy lenta.
2. El desarrollador, a menudo, hace compromisos de implementacin para hacer que el
prototipo funcione rpidamente. Se puede utilizar un sistema operativo o lenguaje de
programacin inadecuado simplemente porque est disponible y porque es conocido; un
algoritmo eficiente se puede implementar simplemente para demostrar la capacidad.
Despus de algn tiempo, el desarrollador debe familiarizarse con estas selecciones, y
olvidarse de las razones por las queson inadecuadas. La seleccin menos ideal ahora es
una parte integral del sistema. Aunque pueden surgir problemas, la construccin de
prototipos puede ser un paradigma efectivo para la ingeniera del software. La clave es
definir las reglas del juego al comienzo; es decir, el cliente y el desarrollador se deben
poner de acuerdo en que el prototipo se construya para servir como un mecanismo de
definicin de requisitos

2.3 MODELO DRA
El Desarrollo Rpido de Aplicaciones (DRA)es un modelo de proceso del desarrollo del
software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El
modelo DRA es una adaptacin a alta velocidad del modelo lineal secuencial en el que
se logra el desarrollo rpido utilizando una construccin basada en componentes. Si se
comprenden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite
al equipo de desarrollo crear un sistema completamente funcional dentro de perodos
cortos de tiempo (por ejemplo: de 60 a 90 das) [MAR91]. Cuando se utiliza
principalmente para aplicaciones de sistemas de informacin, el enfoque DRA comprende
las siguientes fases [KER94]: Modelado de Gestin. El flujo de informacin entre las
funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu
informacin conduce el proceso de gestin? Qu informacin se genera? Quin la
genera? A dnde va la informacin? Quin la procesa? El modelado de gestin se
describe con ms detalle en el Captulo 10.
Modelado de datos. El flujo de informacin definido como parte de la fase de modelado de
gestin se refina como un conjunto de objetos de datos necesarios para apoyar la
empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y


22

las relaciones entre estos objetos. El modelado de datos se trata en el Captulo 12.
Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de informacin necesario para implementar una
funcin de gestin. Las descripciones del proceso se crean para aadir, modificar,
suprimir, o recuperar un objeto de datos. Generacin de aplicaciones. El DRA asume la
utilizacin de tcnicas de cuarta generacin (Seccin 2.10). En lugar de crear software
con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver
a utilizar componentes de programas ya existentes (cuando es posible) o a crear
componentes reutilizables (cuando sea necesario). En todos los casos se utilizan
herramientas para facilitar la construccin del software.

Pruebas y entrega. Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado
muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin
embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las
interfaces a fondo. El modelo de proceso DRA se ilustra en la Figura 2.6. Obviamente, las
limitaciones de tiempo impuestas en un proyecto DRA demandan mbito en escalas
[KER94]. Si una aplicacin de gestin puede modularse de forma que permita
completarse cada una de las funciones principales en menos de tres meses (utilizando el
enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones
puede ser afrontada por un equipo DRA separado y ser integradas en un solo conjunto. Al
igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes [BUT94]:
Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos
suficientes como para crear el nmero correcto de equipos DRA. DRA requiere clientes y
desarrolladores comprometidos en las rpidas actividades necesarias para completar un
sistema en un marco de tiempo abreviado. Si no hay compromiso por ninguna de las
partes constituyentes, los proyectos DRA fracasarn. No todos los tipos de aplicaciones
son apropiados para DRA. Si un sistema no se puede modularizar adecuadamente, la
construccin de los componentes necesarios para DRA ser problemtico. Si est en
juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en
componentes de sistemas, el enfoque DRA puede que no funcione. DRA no es adecuado
cuando los riesgos tcnicos son altos. Esto ocurre cuando una nueva aplicacin hace uso
de tecnologas nuevas, o cuando el software nuevo requiere un alto grado de
interoperabilidad con programas de computadora ya existentes. Modelos evolutivos de
procesos de software Se reconoce que el software, al igual que todos los sistemas


23

complejos, evoluciona con el tiempo [GIL88]. Los requisitos de gestin y de productos a
menudo cambian conforme a que el desarrollo proceda haciendo que el camino que lleva
al producto final no sea real; las estrictas fechas tope del mercado hacen que sea
imposible finalizar un producto completo, por lo que se debe introducir una versin
limitada para cumplir la presin competitiva y de gestin; se comprende perfectamente el
conjunto de requisitos de productos centrales o del sistema, pero todava se tienen que
definir los detalles de extensiones del producto o sistema. En estas y en otras situaciones
similares, los ingenieros del software necesitan un modelo de proceso que se ha diseado
explcitamente para acomodarse a un producto que evolucione con el tiempo. El modelo
lineal secuencial (Seccin 2.4) se disea para el desarrollo en lnea recta. En esencia,
este enfoque en cascada asume que se va entregar un sistema completo una vez que la
secuencia lineal se haya finalizado. El modelo de construccin de prototipos (Seccin 2.5)
se disea para ayudar al cliente (o al que desarrolla) a comprender los requisitos. En
general, no se disea para entregar un sistema de produccin. En ninguno de los
paradigmas de ingeniera del software se tiene en cuenta la naturaleza evolutiva del
software. Los modelos evolutivos son iterativos. Se caracterizan por la forma en que
permiten a los ingenieros del software desarrollar versiones cada vez ms completas del
software.

2.4 EL MODELO INCREMENTAL

El modelo incrernental combina elementos del modelo lineal secuencial (aplicados
repetidamente) con la filosofa interactiva de construccin de prototipos. Como muestra la
Figura 2.7, el modelo incremental aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un
incremento del software [MDE93]. Por ejemplo, el software de tratamiento de textos
desarrollado con el paradigma incremental podra extraer funciones de gestin de
archivos bsicos y de produccin de documentos en el primer incremento; funciones de
edicin ms sofisticadas y de produccin de documentos en el segundo incremento;
correccin ortogrfica y gramatical en el tercero; y una funcin avanzada de esquema de
pgina en el cuarto. Se debera tener en cuenta que el flujo del proceso de cualquier
incremento puede incorporar el paradigma de construccin de prototipos. Cuando se
utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es
decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias (algunas


24

conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la
revisin detallada). Como un resultado de utilizacin y/o de evaluacin, se desarrolla un
plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin
de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas
adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se
elabore el producto completo. El modelo de proceso incremental, como la construccin de
prototipos (Seccin 2.5) y otros enfoques evolutivos, es iterativo por naturaleza. Pero a
diferencia de la construccin de prototipos, el modelo incremental se centra en la entrega
de un producto operacional con cada incremento. Los primeros incrementos son
versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad
que precisa y tambin una plataforma para la evaluacin. El desarrollo incremental es
particularmente til cuando la dotacin de personal no est disponible para una
implementacin completa en la fecha lmite que se haya establecido para el proyecto. Los
primeros incrementos se pueden implementar con menos personas.

2.5 EL MODELO 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, tambin
llamadas regidores de tareas6. Generalmente, existen entre tres y seis regiones de
tareas. La Figura 2.8 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. 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


25

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.
Cada una de las regiones est compuesta por un conjunto de tareas del trabajo, llamado
conjunto de tareas, que se adaptan a las caractersticas del proyecto que va a
emprenderse. Para proyectos pequeos, el nmero de tareas de trabajo y su formalidad
es bajo. Para proyectos mayores y ms crticos cada regin de tareas contiene tareas de
trabajo que se definen para lograr un nivel ms alto de formalidad. En todos los casos, se
aplican las actividades de proteccin (por ejemplo: gestin de configuracin del software y
garanta de calidad del software) mencionadas en la Seccin 2.2. Cuando empieza este
proceso evolutivo, el equipo de ingeniera del software gira alrededor de la espiral en la
direccin de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral
puede producir el desarrollo de una especificacin de productos; los pasos siguientes en
la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones
ms sofisticadas del software. Cada paso por la regin de planificacin produce ajustes
en el plan del proyecto. El coste y la planificacin se ajustan con la realimentacin ante la
evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de
iteraciones requeridas para completar el software. A diferencia del modelo de proceso
clsico que termina cuando se entrega el software, el modelo en espiral puede adaptarse
y aplicarse a lo largo de la vida del software de computadora. Una visin alternativa del
modelo en espiral puede ser considerada examinando el eje de punto de entrada en el
proyecto tambin reflejado en la Figura 2.8. Cada uno de los cubos situados a lo largo del
eje pueden usarse para representar el punto de arranque para diferentes tipos de
proyectos. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral
y continuar (aparecen mltiples iteraciones a lo largo de la espiral que limita la regin
sombreada central) hasta que se completa el desarrollo del concepto. Si el concepto se va
a desarrollar dentro de un producto real, el proceso contina a travs del cubo siguiente
(punto de entrada del proyecto de desarrollo del producto nuevo) y se inicia un nuevo
proyecto de desarrollo. El producto nuevo evolucionar a travs de iteraciones alrededor
de la espiral siguiendo el camino que limita la regin algo ms brillante que el centro. En
esencia, la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que
el software se retira. Hay veces en que el proceso est inactivo, pero siempre que se


26

inicie un cambio, el proceso arranca en el punto de entrada adecuado (por ejemplo:
mejora del producto). El modelo en espiral es un enfoque realista del desarrollo de
sistemas y de software a gran escala. Como el software evoluciona, a medida que
progresa el proceso el desarrollador y el cliente comprende y reaccionan mejor ante
riesgos en cada uno de los niveles evolutivos. El modelo en espiral utiliza la construccin
de prototipos como mecanismo de reduccin de riesgos, pero, lo que es ms importante,
permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier
etapa de evolucin del producto. Mantiene el enfoque sistemtico de los pasos sugeridos
por el ciclo de vida clsico, pero lo incorpora al marco de trabajo iterativo que refleja de
forma ms realista el mundo real. El modelo en espiral demanda una consideracin
directa de los riesgos tcnicos en todas las etapas del proyecto, y, si se aplica
adecuadamente, debe reducir los riesgos antes de que se conviertan en problemticos.
Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar
difcil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que
el enfoque evolutivo es controlable. Requiere una considerable habilidad para la
evaluacin del riesgo, y cuenta con esta habilidad para el xito. Si un riesgo importante no
es descubierto y gestionado, indudablemente surgirn problemas. Finalmente, el modelo
no se ha utilizado tanto como los paradigmas lineales secuenciales o de construccin de
prototipos. Todava tendrn que pasar muchos aos antes de que se determine con
absoluta certeza la eficacia de este nuevo e importante paradigma.


2.6 EL MODELO ESPIRAL WINWIN
El modelo en espiral tratado en la Seccion 2.7.2 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


27

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). Conseguidos completamente estos pasos iniciales se logra un
resultado victoria-victoria, que ser el criterio clave para continuar con la definicin del
sistema y del software. El modelo en espiral WINWIN se ilustra
en la Figura 2.9.

Adems del nfasis realizado en la negociacin inicial, el modelo en espiral WINWIN
introduce tres hitos en el proceso, llamados puntos de fijacin [BOE96], que ayudan a
establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de
decisin antes de continuar el proyecto de software.
En esencia, los puntos de fijacin representan tres visiones diferentes del progreso
mientras que el proyecto recorre la espiral. El primer punto de fijacin, llamado objetivos
del ciclo de vida (OCV), define un conjunto de objetivos para cada actividad principal de
ingeniera del software. Como ejemplo, de una parte de OCV, un conjunto de objetivos
asociados a la definicin de los requisitos del producto/sistema del nivel ms alto. El
segundo punto de fijacin, llamado arquitectura del ciclo de vida (ACV), establece los
objetivos que se deben conocer mientras que se define la arquitectura del software y el
sistema. Como ejemplo, de una parte de la ACV, el equipo del proyecto de software debe
demostrar que ha evaluado la funcionalidad de los componentes del software reutilizables
y que ha considerado su impacto en las decisiones de arquitectura. La capacidad
operativa inicial (COI) es el tercer punto de fijacin y representa un conjunto de objetivos
asociados a la preparacin del
Software para la instalacin/distribucin, preparacin del lugar previamente a la
instalacin, y la asistencia precisada de todas las partes que utilizar o mantendr el
software.


28


2.7 DESARROLLO BASADO EN COMPONENTES
Las tecnologas de objetos (4.g Parte de este libro) proporcionan el marco de trabajo
tcnico para un modelo de proceso basado en componentes para la ingeniera del
software. El paradigma orientado a objetos enfatiza la creacin de clases que encapsulan
tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se disean y
se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las
diferentes aplicaciones y arquitecturas de sistemas basados en computadora.

El modelo de desarrollo basado en componentes (Fig. 2.11) incorpora muchas de las
caractersticas del modelo en espiral. Es evolutivo por naturaleza [NIE92], y exige un
enfoque iterativo para la creacin del software. Sin embargo, el modelo de desarrollo
basado en componentes configura aplicaciones desde componentes preparados de
software (llamados clases en la Fig. 2.11). La actividad de la ingeniera comienza con la
identificacin de clases candidatas. Esto se lleva a cabo examinando los datos que se van
a manejar por parte de la aplicacin y el algoritmo que se va a aplicar para conseguir el
tratamientoI2. Los datos y los algoritmos correspondientes se empaquetan en una clase.
Las clases creadas en los proyectos de ingeniera del software anteriores, se almacenan
en una biblioteca de clases o diccionario de datos (repository) (Captulo 3 1). Una vez
identificadas las clases candidatas, la biblioteca de clases se examina para determinar si
estas clases ya existen. En caso de que as fuera, se extraen de la biblioteca y se vuelven
a utilizar. Si una clase candidata no reside en la biblioteca, se aplican los mtodos
orientados B objetos (Captulos 2 1-23). Se compone as la primera iteracin de la
aplicacin a construirse, mediante las clases extradas de la biblioteca y las clases nuevas
construidas
para cumplir las necesidades nicas de la aplicacin. El flujo del proceso vuelve a la
espiral y volver a introducir por ltimo la iteracin ensambladora de componentes a
travs de la actividad de ingeniera. El modelo de desarrollo basado en componentes
conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los
ingenieros de software. Segn estudios de reutilizacin, QSM Asociaste, Inc. Informa que
el ensamblaje de componentes lleva a una reduccin del 70 por 100 de tiempo de ciclo de
desarrollo, un 84 por 100 del coste del proyecto y un ndice de productividad del 26.2,
comparado con la norma de industria del 16.9 [YOU94]. Aunque estos resultados estn en


29

funcin de la robustez de la biblioteca de componentes, no hay duda de que el
ensamblaje de componentes proporciona ventajas significativas para los ingenieros de
software. El proceso unificado de desarrollo de software
[JAC99] representa un nmero de modelos de desarrollo basados en componentes que
han sido propuestos en la industria. Utilizando el Lenguaje de Modelado Unijcado (UML),
el proceso unificado define los componentes que se utilizarn para construir el sistema y
las interfaces que conectarn los componentes. Utilizando una combinacin del desarrollo
incremental e iterativo, el proceso unificado define la funcin del sistema aplicando un
enfoque basado en escenarios (desde el punto de vista de1 usuario). Entonces acopla la
funcin con un marco de trabajo arquitectnico que identifica la forma que tomar el
software.

UNIDAD 3- ARQUITECTURAS DE SOFTWARE

3.1 ARQUITECTURA DE SOFTWARE
En los inicios de la informtica, la programacin se consideraba un arte y se desarrollaba
como tal, debido a la dificultad que entraaba para la mayora de las personas, pero con
el tiempo se han ido descubriendo y desarrollando formas y guas generales, con base a
las cuales se puedan resolver los problemas.
A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los
planos de un edificio o construccin, estas indican la estructura, funcionamiento e
interaccin entre las partes del software. En el libro "An introduction to Software
Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseo
que hace foco en aspectos "ms all de los algoritmos y estructuras de datos de la
computacin; el diseo y especificacin de la estructura global del sistema es un nuevo
tipo de problema".
La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un
sistema.
Una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste
en un conjunto de patrones y abstracciones coherentes que proporcionan el marco


30

Una arquitectura de software se selecciona y disea con base en objetivos y
restricciones. Los objetivos son aquellos prefijados para el sistema de informacin,
pero no solamente los de tipo funcional, tambin otros objetivos como la
mantenibilidad, audibilidad, flexibilidad e interaccin con otros sistemas de
informacin. Las restricciones son aquellas limitaciones derivadas de las
tecnologas disponibles para implementar sistemas de informacin. Unas
arquitecturas son ms recomendables de implementar con ciertas tecnologas
mientras que otras tecnologas no son aptas para determinadas arquitecturas. Por
ejemplo, no es viable emplear una arquitectura de software de tres capas para
implementar sistemas en tiempo real.
La arquitectura de software define, de manera abstracta, los componentes que
llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin entre
ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que
consiste simplemente en determinar qu computadora tendr asignada cada tarea.

3.2 DESCOMPOSICIN MODULAR
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).


31

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. 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.Describircada 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

3.3 PATRONES DE DISEO
Los patrones de diseo son la base para la bsqueda de soluciones a problemas
comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o
interfaces. Un patrn de diseo resulta ser una solucin a un problema de diseo. Para
que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de
ellas es que debe haber comprobado su efectividad resolviendo problemas similares en


32

ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a
diferentes problemas de diseo en distintas circunstancias.
Objetivos de los patrones de diseo
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 de diseo
Segn la escala o nivel de abstraccin:

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.


33

Adems, tambin es importante resear el concepto de "anti patrn 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 anti patrones 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.

Arquitectura de modelo 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


34

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
3.4 DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR
Los sistemas multiprocesador (MP) son un tipo de arquitectura con una importancia
creciente y ampliamente difundido. La mayora de los constructores de computadores
ofrece mquinas en las que estn presentes ms de una CPU, configuracin que es hoy
en da de uso habitual en casi todos los sistemas de tamao medio y grande, incluso ya
en ordenadores personales. Asimismo, los fabricantes de procesadores incorporan a sus
arquitecturas, desde hace unos aos, los mecanismos necesarios para que stos se


35

puedan emplear fcilmente, y con un coste reducido (publicidad de Sun Microsystems en
1999: "si compra un procesador, le regalamos otro"), en la construccin de este tipo de
sistemas.

Esta tendencia se ha visto reforzada en los ltimos aos con la aparicin de los multicore,
es decir, varios ncleos por procesador. En los prximos aos veremos mquinas con
bastantes procesadores, cada uno de ellos con multitud de ncleos. Por tanto,
comprender como funcionan y saber explotar correctamente esta potencia de cmputo se
vuelve algo necesario para cualquier ingeniero informtico. 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 solo pueden ejecutar un proceso cada vez.
La nica forma de que se ejecuten de forma simultanea varios procesos es tener varias
cpus ya sea en una maquina o en varias en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto
y 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 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.
VENTAJAS
Es econmica
Las computadoras paralelas son inherentes escalables permitiendo actualizarlas para
adecuarse a la necesidad

DESVENTAJAS
Puede ser limitante fsica, existen factores que limitan la velocidad mxima de un
procesador independiente del factor econmico


36

Las barreras fsicas infranqueables tales como la velocidad de la luz, efectos de tamao,
la capacidad.
3.5 DISEO DE SOFTWARE DE CLIENTE SERVIDOR
La arquitectura cliente-servidor es un modelo de aplicacin distribuida en el que las tareas
se reparten entre los proveedores de recursos o servicios, llamados servidores, y los
demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor,
quien le da respuesta. Esta idea tambin se puede aplicar a programas que se ejecutan
sobre una sola computadora, aunque es ms ventajosa en un sistema
operativo multiusuario distribuido a travs de una red de computadoras.

En esta arquitectura la capacidad de proceso est repartida entre los clientes y los
servidores, aunque son ms importantes las ventajas de tipo organizativo debidas a la
centralizacin de la gestin de la informacin y la separacin de responsabilidades, lo que
facilita y clarifica el diseo del sistema.
La separacin entre cliente y servidor es una separacin de tipo lgico, donde el servidor
no se ejecuta necesariamente sobre una sola mquina ni es necesariamente un slo
programa. Los tipos especficos de servidores incluyen los servidores web, los servidores
de archivo, los servidores del correo, etc. Mientras que sus propsitos varan de unos
servicios a otros, la arquitectura bsica seguir siendo la misma.
Una disposicin muy comn son los sistemas multicapa en los que el servidor se
descompone en diferentes programas que pueden ser ejecutados por diferentes
computadoras aumentando as el grado de distribucin del sistema.
La arquitectura cliente-servidor sustituye a la arquitectura monoltica en la que no hay
distribucin, tanto a nivel fsico como a nivel lgico.
La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes
estn conectados a un servidor, en el que se centralizan los diversos recursos y
aplicaciones con que se cuenta; y que los pone a disposicin de los clientes cada vez que
estos son solicitados.
Esto significa que todas las gestiones que se realizan se concentran en el servidor, de
manera que en l se disponen los requerimientos provenientes de los clientes que tienen


37

prioridad, los archivos que son de uso pblico y los que son de uso restringido, los
archivos que son de slo lectura y los que, por el contrario, pueden ser modificados, etc.
Este tipo de red puede utilizarse conjuntamente en caso de que se este utilizando en una
red mixta.
Caractersticas
En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus
caractersticas son:
Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la
comunicacin (dispositivo maestro o amo).
Espera y recibe las respuestas del servidor.
Por lo general, puede conectarse a varios servidores a la vez.
Normalmente interacta directamente con los usuarios finales mediante
una interfaz grfica de usuario.
Al contratar un servicio de redes, se debe tener en cuenta la velocidad de
conexin que le otorga al cliente y el tipo de cable que utiliza , por ejemplo : cable
de cobre ronda entre 1 ms y 50 ms.


3.6 DISEO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA
La utilizacin de la arquitectura distribuida basada en una red de ordenadores personales
tiene como objetivo global: obtener prestaciones razonables a un coste bajo.
VENTAJAS DE LA ARQUITECTURA DISTRIBUIDA
Fue creada a partir de la Arquitectura n-Layer desacoplada, donde intervienen las capas
de presentacin, de negocio, de servicios y datos. Adems de las tecnologas para su
implementacin, Workflows, Servicios Web e Interfaces Grficas declarativas. En la
siguiente grafica se muestran las capas que la conforman.
Evita la sobrecarga de procesador con clculos sobre los modelos matemticos y
generacin de la escena.


38

Permite una mayor reutilizacin del cdigo: al ser compartimentos ms o menos
estancos, las mayores variaciones se realizan en interfase de usuario.
El uso de ordenadores personales reduce el coste inicial de implantacin.
Los ordenadores personales son altamente fiables, se reparan fcilmente y se
sustituyen de forma inmediata.
Es software empleado es de gran difusin y se encuentra fcilmente software
desarrollado y personal cualificado.
El uso del mismo tipo de ordenador para tareas distintas permite un coste de
mantenimiento ms reducido.
Inconvenientes de la arquitectura distribuida:
Es ms difcil disear y desarrollar el software para el trabajo en paralelo que para
una aplicacin nica lineal.
Hay adquirir y aprender un software para las comunicaciones entre los distintos
ordenadores.
Los problemas de organizacin del trfico de informacin para garantizar la
consistencia de las comunicaciones es una tarea bien compleja.
Se necesita un hardware de red de suficiente fiabilidad.
La depuracin de los programas en este tipo de arquitectura se dificulta
enormemente. En algunos casos es necesario desarrollar herramientas ad-hoc
para obtener datos que puedan ayudar a la depuracin.
3.7 DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO REAL
ARQUITECTURA
A los sistemas de tiempo real tambin se les conoce como sistemas empotrados o
embebidos. Es un sistema informtico que interacciona rpidamente con su
entorno fsico y realiza funciones de supervision y control.
Un sistema de tiempo real es un sistema de procesamiento de informacin el cual tiene
que responder a estmulos de entrada generados externamente en un perodo finito y
especfico.
Un sistema en tiempo real es una combinacin de computadoras, dispositivos de E/S,
hardware y software de propsito especfico en donde:
existe una fuerte interaccin con el ambiente.


39

el ambiente cambia con el tiempo
el sistema debe controlar y/o reaccionar a diferentes aspectos del ambiente.

Como resultado:
Se imponen restricciones de tiempos al software.
El software es naturalmente concurrente.
Se exige una alta confiabilidad.
Una caracterstica distintiva de un sistema en tiempo real es la producibilidad. La cual
implica que debe ser posible demostrar o comprobar a priori que los requerimientos de
tiempos se cumplen en cualquier circunstancia.


UNIDAD 4: SEGURIDAD EN INGENIERA DE SOFTWARE

4.1 SEGURIDAD DE 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 la actualidad prcticamente todo sistema debe incorporar cuestiones de seguridad
para defenderse de ataques maliciosos. El desarrollador ya no slo debe concentrarse
nicamente en los usuarios y sus requerimientos, sino tambin en los posibles atacantes.
Esto ha motivado cambios importantes en el proceso de diseo y desarrollo de software
para incorporar a la seguridad dentro de los requerimientos crticos del sistema.
Problemtica actual de la seguridad en el software


40

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 software seguro

Lamentablemente, la mayora de las herramientas que tiene disponible un desarrollador
de software sufren de fallas propias de seguridad. Una de las debilidades ms
trascendentes al momento de implementar software seguro surge del estado de los
lenguajes de programacin desde el punto de vista de la seguridad. Son escasos los
lenguajes que proveen primitivas seguras que ayuden al programador a escribir un
mejor cdigo.
Dos de los lenguajes de programacin ms usados en la actualidad, C y C++, presentan
graves problemas de seguridad. Esto se debe a que al utilizar muchos de sus servicios
provistos por sus libreras estndar se introducen fallas de seguridad que pasarn
inadvertidas al programador debido a que ste las considera libre de errores.

Las razones por las cuales estas fallas internas permanecen en la actualidad son varias:
mal entendimiento de los protocolos de seguridad, una visin ingenua respecto a lo que
un sistema debiera considerar como seguro, aproximaciones no serias a la seguridad
como corregir luego o no se van a dar cuenta, o directamente desconocimiento, ya que
lamentablemente estas fallas no son conocidas universalmente, y existen pocas fuentes
de informacin para escribir cdigo seguro.

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.



41

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. Como definicin del concepto de seguridad
en software, se adoptar en este trabajo la definicin que propone Doshi Shreyas

software es un concepto multi-dimensional. Las mltiples dimensiones de la seguridad
son:
Autenticacin: el proceso de verificar la identidad de una entidad.
Control de acceso: el proceso de regular las clases de acceso que una entidad
tiene sobre los recursos.
Auditoria: un registro cronolgico de los eventos relevantes a la seguridad de un
sistema. Este registro puede luego examinarse para reconstruir un escenario en
particular.
Confidencialidad: la propiedad de que cierta informacin no est disponible a
ciertas entidades.
Integridad: la propiedad de que la informacin no sea modificada en el trayecto
fuente-destino.
Disponibilidad: la propiedad de que el sistema sea accesible a las entidades
autorizadas.
No repudio: la propiedad que ubica la confianza respecto al desenvolvimiento de
una entidad en una comunicacin.
La seguridad puede tener diferentes significados en distintos escenarios. En
general, cuando se habla de seguridad implica referirse a ms de una de las
dimensiones mencionadas anteriormente. Por ejemplo:
Seguridad en correo electrnico: involucra confidencialidad, no repudio e
integridad.
Seguridad en compras online: implica autentificacin, confidencialidad, integridad y
no repudio.

Una vez definido el concepto de seguridad, se pueden establecer objetivos bsicos para
un software seguro:



42

Independencia de la seguridad: la seguridad debe construirse y utilizarse de
manera independiente de la aplicacin.
Independencia de la aplicacin: la aplicacin no debe depender del sistema de
seguridad usado, debe ser desarrollada y mantenida en forma separada.
Uniformidad: la seguridad debe aplicarse de manera correcta y consistente a
travs de toda la aplicacin y del proceso que desarrolla la misma.
Modularidad: mantener la seguridad separada. Entre otras ventajas, esto nos
brindar mayor flexibilidad y menor costo de mantenimiento.
Ambiente seguro: se debe partir de un entorno confiable. Es decir, las
herramientas de desarrollo y lenguajes de programacin no deben contener
agujeros de seguridad.
Seguridad desde el comienzo: la seguridad debe ser considerada como un
requerimiento desde el inicio del diseo.

4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones
propias para su gestin de negocio. Como todo software, estas aplicaciones pueden
contener fallas de seguridad y a diferencia del software comercial, no se dispone de
actualizaciones o parches liberados en forma peridica por el fabricante. El tratamiento de
las vulnerabilidades en aplicaciones propias corre por parte de la organizacin que las
desarrolla.

Qu est pasando en las organizaciones?
Lamentablemente es una prctica habitual en muchas organizaciones la puesta en
produccin de sistemas sin la participacin del sector de Seguridad de la Informacin.
Muchas otras veces, el sector de Seguridad se entera demasiado tarde, y no tiene
suficiente margen de accin para el anlisis de seguridad de la aplicacin desarrollada.
Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que
la aplicacin ya est desarrollada. Aqu muchas veces se encuentran errores que
requieren el rediseo de parte de la aplicacin, lo cual implica un costo adicional en
tiempo y esfuerzo.




43

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.

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 compliance 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).

Seguridad en la codificacin


44

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 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. 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.

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.


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


45

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.

Conclusin
La seguridad en las aplicaciones de software debe abordarse desde el primer da del
proceso de desarrollo y a lo largo de todas las etapas del mismo. En cada una de estas
etapas, se pueden realizar diversas actividades que en su conjunto ayudarn a aumentar
la seguridad de la aplicacin de software que se est desarrollando. Es importante que en
cada organizacin, el sector de seguridad de la informacin sea invitado a participar a lo
largo de todo el proceso de desarrollo como supervisor de las tareas y verificaciones de
seguridad.

4.3 CONFIABILIDAD DEL SOFTWARE
La IEEE define a la confiabilidad como "la habilidad que tiene un sistema o componente
de realizar sus funciones requeridas bajo condiciones especficas en periodos de tiempo
determinados". Musa (2002) define a la confiabilidad como "la probabilidad o la capacidad
de que un sistema de funciones trabajen sin falla en un periodo de tiempo y bajo
condiciones o un medio ambiente tambin especfico".
La confiabilidad es un aspecto en el cual se involucran diferentes dimensiones. Los
principales conceptos asociados a la confiabilidad del software en los setenta fueron:

Fiabilidad.
Disponibilidad.
Mantenimiento.
Seguridad.


Disponibilidad: Se refiere a la condicin de trabajo que un sistema debe de tener.
Fiabilidad: En la ingeniera se usa generalmente para asegurar aquella condicin
de trabajo que permite al usuario realizar sus tareas para que el sistema no llegue
a corromperse.


46

Seguridad: Este concepto no solo describe el comportamiento del sistema,
tambin nos define la habilidad que tiene este para poder resistir los ataques
externos.
Proteccin: Se refiere a la capacidad del sistema de permitir las fallas de manera
inmediata, en caso de que el sistema llegara a fallar existir alguna manera de
proteger la informacin o las acciones que el sistema realice.



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,.

En nuestro caso nos referimos a la seguridad informtica, especficamente a la seguridad
en el software.

Las polticas de seguridad, los objetivos de seguridad
En el establecimiento de las condiciones de seguridad de cualquier sistema juegan un
papel fundamental las polticas de seguridad y los perfiles de proteccin. El modelado de
riesgos es el primer paso a dar cuando uno piensa en el diseo de un sistema seguro.
Cules son los riesgos reales que se afrontan con el sistema? Con que frecuencia
pueden ocurrir? Y sobre todo Cul es su costo? y Cunto estamos dispuestos a invertir
para garantizar que no ocurran? Esta actividad requiere de una visin sistmica de lo que


47

pueden significar los riesgos de seguridad. No es suficiente con hacer un listado completo
de los posibles riegos de seguridad.

La ingeniera de seguridad procede secuencialmente desde los requerimientos de
seguridad hasta la solucin, no desde la tecnologa ms novedosa. Esto significa que lo
primero que hay que hacer es modelar el tipo de ataques al que se est sujeto, a partir de
esto crear una poltica de seguridad y luego a partir de esto escoger la tecnologa a
aplicar para evitar los riesgos antes modelados.
Los riesgos determinan la poltica y esta define la tecnologa a utilizar, los pasos a seguir
seran los siguientes:

Comprender los riesgos reales del sistema y evaluar el las probabilidades de esos
riesgos.
Describir la poltica de seguridad requerida para defenderse de esos ataques o
riesgos.
Disear las medidas de seguridad destinadas a contrarrestar esos riesgos.










48


CONCLUSIN
Cuando se emplea un modelo de negocios la empresa se sustenta en pilares slidos:
empleados motivados, excelencia en los procesos para ofrecer la mxima calidad al
mnimo precio, clientes satisfechos, sociedad satisfecha y generacin de valor para el
accionista.
Los retos son mantener el liderazgo y seguir innovando para mantener enamorados a los
clientes frente a los movimientos que hagan los competidores.
Las empresas que pretendan alcanzar el xito en sus respectivos mercados, y no
simplemente sobrevivir en ellos, requieren de una filosofa empresarial que la haga capaz
de entregar un valor superior a sus clientes. No es tarea fcil. Y requiere de un cambio de
mentalidad que le permita visualizar dos principios fundamentales:
El buen conocimiento de sus clientes, competidores y del entorno.
Establecer vnculos de estrecha colaboracin con sus empleados, proveedores,
distribuidores y otros, para en conjunto, brindarle a sus clientes: un valor superior
Cuando se utiliza una metodologa de desarrollo de software implica que estas tomando
las mejores opciones para tu organizacin o empresa ya que estas ayudan a usar
recursos mnimos y a si tener un buen comienzo. Y con el determinar el tipo de estructura
del software









49


BIBLIOGRAFIAS
Orientacin a mercado. Un modelo desde la perspectiva de aprendizaje organizacional.
Autor: Mara del Carmen Martnez Serna
Direcciones web
www.mailxmail.com Comercio electrnico. E-business
www.directivoglobal.com/articulos/23/los-modelos-de-negocio-y-la-necesidad-de-
cambio.html
http://manuelgross.bligoo.com/20110720-los-12-elementos-claves-de-los-modelos-de-
negocio
http://manuelgross.bligoo.com/content/view/634585/Que-es-un-Modelo-de-Negocio-La-
fuente-de-tu-competitividad.html
http://www.culturaemedellin.gov.co/sites/CulturaE/Comunidadesvirtuales/ComunidadNodo
Medell%C3%ADnDigital/Memorias%20capacitaciones/Modelo_de_Negocio.pdf
http://www.promonegocios.net/mercadotecnia/valor.htm
http://itilv3.osiatis.es/funciones_procesos_roles.php
http://www.craftware.net/es/descargas/modelo_de_proceso_de_negocio.pdf
http://www.slideshare.net/gugarte/bpmn-estandar-para-modelamiento-de-procesos-
presentation
http://kuainasi.ciens.ucv.ve/ideas07/documentos/conferencias/ConferenciaJonasMontilva.
pdf
http://www.milestone.com.mx/CursoModeladoNegociosBPMN.htm
http://www.bizagi.com/docs/BPMNbyExampleSPA.pdf