INGENIERIA DE LOS SISTEMAS DE INFORMACION

I . El ciclo de vida de los sistemas de informacin. Modelos del ciclo de vida

CICLO DE VIDA = Ciclo de Desarrollo + Mantenimiento





1. Estructurada
2. Orientado a Objetos


Modelos del ciclo de vida

El director de un proyecto, contando con el asesoramiento de los dems
miembros del equipo, debe elegir los mtodos y herramientas ms adecuados en
cada momento para satisfacer las necesidades especficas del proyecto, adems
de establecer las medidas oportunas que permitan controlar la evolucin del
proyecto. Las decisiones tomadas en este sentido han de tener como objetivo
satisfacer los tiempos de entrega pactados con el cliente sin comprometer la
calidad del producto final.

Existen distintas formas de organizar el orden concreto en el que se acometern
las distintas etapas del ciclo de vida de un sistema de informacin. En los
siguientes prrafos se describen algunas de las alternativas que deberan tenerse
en cuenta:


- Ciclo de vida clsico

El modelo de ciclo de vida clsico, tambin denominado "modelo en
cascada", se basa en intentar hacer las cosas bien desde el principio, de
una vez y para siempre. Se pasa, en orden, de una etapa a la siguiente
slo tras finalizar con xito las tareas de verificacin y validacin propias
de la etapa. Si resulta necesario, nicamente se da marcha atrs hasta la
fase inmediatamente anterior.

Este modelo tradicional de ciclo de vida exige una aproximacin
secuencial al proceso de desarrollo del software. Por desgracia, esta
aproximacin presenta una serie de graves inconvenientes, entre los que
cabe destacar:
o Los proyectos reales raramente siguen el flujo secuencial de
actividades que propone este modelo.

o Normalmente, es difcil para el cliente establecer explcitamente
todos los requisitos al comienzo del proyecto (entre otras cosas,
porque hasta que no vea evolucionar el proyecto no tendr una
idea clara de qu es lo que realmente quiere).

o No habr disponible una versin operativa del sistema hasta
llegar a las etapas.

Finales del proyecto, por lo que la rectificacin cualquier decisin
tomada errneamente en las etapas iniciales del proyecto supondr un
coste adicional significativo, tanto econmico como temporal (y eso sin
tener en cuenta la mala impresin causada por un retraso en la fecha de
entrega).



Tal cual, el modelo de ciclo de vida en cascada no nos indica nada
acerca de la relacin contractual existente entre el cliente y la
organizacin encargada del desarrollo de software.
Desde el punto de vista de una empresa de desarrollo de software,
formalizar la firma de un contrato al final de la etapa de anlisis, por
ejemplo, puede ayudar a reducir el riesgo que supone elaborar un
presupuesto cuando an no se dispone de toda la informacin necesaria
para que la estimacin del esfuerzo requerido por el proyecto sea lo
suficientemente precisa.
Este tipo de contrato obliga a que el cliente se haga cargo de los costes
adicionales ocasionados por cambios en los requerimientos, mientras
que la empresa de desarrollo de software deber asumir los gastos
ocasionados si el producto finalmente entregado no cumple todas las
condiciones pactadas a la firma del contrato.

Por desgracia, un modelo contractual como el descrito en el prrafo
anterior no siempre resulta aceptable para el cliente, que puede verse
obligado a invertir dinero a cambio de nada.

Esto podra pasar si, tras la etapa de anlisis, el proyecto se desestima
por no ser tcnica o econmicamente viable. Es ms, si el cliente acepta
a regaadientes la firma de un contrato al final de la etapa de anlisis, la
imagen de la empresa desarrolladora de software puede verse seriamente
deteriorada en cuanto surja cualquier tipo de problema.

Para limar las asperezas que pueden surgir en la relacin cliente-
proveedor y mejorar el rendimiento del equipo del proyecto, hoy en da
se suele recurrir a modelos iterativos como los que se describirn a
continuacin.


- Desarrollo de prototipos

Normalmente, el cliente es capaz de definir un conjunto general de
objetivos para el sistema que hemos de construir, pero no identifica los
requisitos detallados. En otros casos, puede que nosotros no estemos
seguros de la eficiencia de un algoritmo, de la capacidad de nuestro
diseo para soportar los requerimientos del sistema o de la forma en que
debe disearse la interfaz de usuario. En cualquiera de estas situaciones,
resulta adecuado construir un prototipo.




El desarrollo de prototipos reduce el riesgo de que nuestro proyecto
fracase y facilita la especificacin de requerimientos de productos que
desconocemos. Sin embargo, tambin tiene sus inconvenientes: el cliente
puede pensar que el prototipo es el sistema definitivo, ignorando que un
prototipo no es un sistema acabado aunque tenga el mismo aspecto
externo.
Esto puede conducir a la consolidacin de aspectos de baja calidad de un
prototipo en el sistema final que se entrega si el prototipo no se desecha a
tiempo.

Fred Brooks nos aclara lo que hay que hacer cuando un prototipo ya ha
cumplido con su propsito: "En la mayora de los proyectos, el primer
sistema que se construye apenas resulta utilizable. Puede que sea
demasiado lento, demasiado grande, difcil de usar o las tres cosas a la
vez. No queda ms remedio que comenzar de nuevo y construir una
versin rediseada que resuelva los problemas. Cuando se utiliza un
concepto nuevo... hay que construir un sistema para desecharlo, porque
incluso la mejor planificacin no puede asegurar que vaya a salir bien la
primera vez. Por tanto, la cuestin no es si hay que construir un sistema
piloto y desecharlo. Se desechar. La nica cuestin es si planificar de
antemano la construccin de algo que se va a desechar, o prometer la
entrega del desecho a los clientes..." (The Mythical Man-Month, "El
mtico hombre-mes", 1975, uno de los libros de gestin de proyectos de
desarrollo de software ms populares que jams se han escrito).

A veces, los prototipos desechables no se llegan a desechar. Pero los
prototipos no siempre son desechables. En tal caso, estaremos utilizando
un modelo iterativo de refinamiento de prototipos en el que, tras varias
iteraciones, seremos capaces de construir un sistema que se adapte mejor
a las necesidades de nuestro cliente.


- Modelos iterativos

En 1994, el Departamento de Defensa de Estados Unidos (el mayor
contratista mundial de proyectos de desarrollo de software) cambi
oficialmente sus estndares de desarrollo de software y descart el
modelo en cascada para introducir el estndar 498, que utiliza un modelo
iterativo de desarrollo de software.

Los modelos iterativos consisten en descomponer un proyecto de
desarrollo de software en una serie de subproyectos de menor
envergadura. Estos subproyectos deben disearse de tal forma que cada
uno de ellos aporte funcionalidad nueva para el sistema desde el punto de
vista del usuario final del mismo.

Usualmente, las personas involucradas en el proyecto establecen
prioridades entre los requerimientos iniciales del sistema para decidir qu
parte del mismo se construir primero.
El cliente y los usuarios finales abogarn por darle prioridad a las
funciones ms tiles del sistema (o las ms "vendibles"). Por otro lado,
los diseadores del sistema debern determinar las dependencias
existentes entre sus distintos componentes y priorizar aqullos que
supongan un riesgo mayor para la viabilidad final del proyecto. Las
prioridades de unos y otros habrn de consensuarse razonablemente y
servirn para determinar el mbito de los subproyectos en que se
descompondr el proyecto inicial.

Los modelos iterativos de desarrollo de software permiten adelantar el
momento en el que se determina si un proyecto es tcnicamente viable o
no (con lo que se eliminan costes innecesarios si, finalmente, el proyecto
hubiese de cancelarse). Tambin promueven una mejor comunicacin
con el usuario/cliente, ya que se dispondr antes de una versin operativa
del sistema, aunque sea de funcionalidad reducida. Estas versiones
intermedias del producto ayudan a la eliminacin de malentendidos que
pueden surgir en la etapa de elicitacin de requerimientos. Adems,
ayudan a que el usuario se forme una idea ms clara de lo que realmente
necesita.


Secuencial o iterativo?

El modelo de desarrollo ms adecuado para un proyecto
depender del tipo de sistema que se ha de construir:

o En general, se elegir un modelo secuencial cuando los
requerimientos se conocen bastante bien y son estables,
cuando el diseo ser similar al de otros sistemas con los
que tenemos experiencia, cuando los integrantes del
equipo de desarrollo ya se conocen y estn familiarizado
con el entorno de desarrollo, o cuando el coste de tener
que cambiar algo en las etapas finales del proyecto
resultara prohibitivo.

o En la prctica, no obstante, los modelos iterativos se
adaptan mejor a la realidad del desarrollo de software
(especialmente en sistemas medianos y grandes). Nos
decantaremos por un modelo iterativo cuando los
requerimientos no se conocen con exactitud o se prev que
puedan cambiar en el futuro, cuando el diseo del sistema
es complejo o no tiene precedentes para nosotros, cuando
el proyecto en s es arriesgado econmicamente y cuando
podamos controlar el coste de futuros cambios en el
sistema (algo que siempre tendremos que hacer si tenemos
en cuenta lo que aprendimos al estudiar la etapa de
mantenimiento).

Al seguir un modelo iterativo, puede que le dediquemos muy
poco tiempo a las etapas iniciales del ciclo de vida de un sistema,
lo que puede causar una tasa de cambios tan alta que impida que
el proyecto progrese. Del mismo modo, si les dedicamos
demasiado tiempo, hasta el punto de seguir a pies juntillas los
requerimientos iniciales del sistema, puede que estemos negando
la realidad con la que nos encontramos y, de nuevo, impidamos
que el proyecto progrese adecuadamente.


Para planificar un proyecto que siga un modelo iterativo, primero se prepara
una descomposicin a grandes rasgos del proyecto en una serie de iteraciones,
cada una de las cuales se considerar como un proyecto independiente. En vez
de realizar una planificacin detallada de todo el proyecto, slo se detallar el
plan correspondiente a la primera iteracin.

S se establecern las fechas de inicio y finalizacin de las distintas iteraciones
y se definirn los objetivos principales de cada una de ellas. Llegado el caso,
estos objetivos se pueden redefinir conforme avance el proyecto.





A lo largo de los aos se han propuesto multitud de modelos iterativos de
desarrollo de software. A continuacin se describen algunos de los ms
conocidos:

o El modelo en espiral de Barry Boehm hace especial hincapi en la
prevencin de riesgos. Este modelo define cuatro actividades
principales: planificacin (determinar los objetivos, alternativas y
restricciones del proyecto), anlisis de riesgos (anlisis de alternativas e
identificacin/resolucin de riesgos), ingeniera (desarrollo del
producto) y evaluacin (revisin por parte del cliente y valoracin de los
resultados obtenidos de cara a la siguiente iteracin). En cada iteracin
alrededor de la espiral se construyen versiones cada vez ms completas
del software.

o Los modelos evolutivos (como el modelo Evo de Tom Gilb o los
modelos giles populares hoy en da, entre los que se encuentra la auto-
denominada programacin extrema) se caracterizan por realizar entregas
por etapas del sistema. Usualmente, el proyecto se descompone en
iteraciones de longitud fija (de 1 a 6 semanas) y cada iteracin ha de
proporcionar algn aspecto completo de la funcionalidad del sistema.
Cada ciclo se concentra en las funciones de mayor valor aadido. De
esta forma, si se cancelase el proyecto en cualquier momento, el usuario
siempre tendr lo mximo que se puede conseguir con los recursos
invertidos hasta el momento. Igualmente, se puede prorrogar el proyecto
si se considera interesante seguir aadindole funcionalidad al proyecto.

o Tambin existen otros modelos, conocidos por el nombre de modelos de
estabilizacin y sincronizacin, en los que se sigue la misma estrategia
que en los modelos iterativos pero sin llegar a realiza una entrega por
etapas del sistema.
ste es el caso, por ejemplo, del modelo de desarrollo de software
utilizado internamente en empresas como Microsoft.


I I . Planificacin estratgica de sistemas de informacin y de comunicaciones

El Plan de Sistemas de Informacin constituye una herramienta, permanentemente
viva, de mejora en los procesos de negocio, optimizando la funcin informtica, el
conjunto de la organizacin y los mtodos utilizados, y estableciendo las lneas
estratgicas para los sistemas, con objeto de dar un soporte gil y eficiente a las
necesidades evolutivas de la organizacin.

Un Plan Estratgico de Sistemas de Informacin se elabora:

Partiendo de los objetivos estratgicos a corto y medio plazo de la empresa.

Recogiendo las necesidades y requerimientos de los usuarios, en base a los
procesos de negocio.

Valorando los escenarios tecnolgicos existentes que aporten el menor
riesgo, la mayor proteccin de las inversiones y los mximos beneficios.


Un efectivo plan estratgico ayuda a balancear estos tres conceptos, a reconocer
potencialidades y limitaciones, a aprovechar los desafos y a encarar los riesgos.
La secuencia de las Actividades de la Planificacin Estratgica de Sistemas de
Informacin es la siguiente:




La evolucin de la Planificacin de sistemas de informacin se ha dado a lo largo de
los aos debido a cuatro factores importantes que son:

o La introduccin de la informtica en la organizacin. Debido a la aparicin
masiva de la informtica en la empresa, inicialmente los ordenadores eran
mquinas de grandes dimensiones que necesitaban una infraestructura
excepcional, y su manejo era reservado para especialistas. Esta situacin
condujo al aislamiento del departamento de Procesamiento de Datos,
conocido inicialmente, creando as el ambiente de que informtica era
nicamente para servir demandas de mecanizacin de los procesos de la
empresa y debido al ambiente en que se trabajaba con los computadores,
nadie se involucraba demasiado.

El objetivo principal de los directivos de las empresas al incorporar la
informtica a estas era la reduccin de costos del procesamiento de la
informacin. Debido a que ese era su nico objetivo no se vea la necesidad
de crear Planes de Procesos de Datos. El departamento de dedicaba
nicamente a recoger demandas de desarrollo de aplicaciones y a
desarrollarlas eficientemente, y las nicas decisiones a tomarse eran sobre
qu proyectos desarrollar antes y con qu recursos se contaba a nivel del
departamento y los costes eran planteados a nivel econmico de la
administracin general.

Es por esto que la situacin actual del departamento de Sistemas de
Informacin, como se lo conoce actualmente, en cuanto a su posicin en el
organigrama de la empresa, se sigue situando en una posicin dependiente
de los servicios administrativos. Adems debido a esta situacin se ha creado
una barrera de comunicacin directa entre los estamentos directivos y la
direccin del departamento de Sistemas de Informacin.


o La expansin de las aplicaciones informticas. Habindose resuelto el
problema de mecanizacin de los procesos de las empresas, el departamento
de informtica tuvo la necesidad de enfrentar las peticiones de los usuarios,
que cada vez son ms complejos e implicados con el funcionamiento del
negocio, los cuales son desarrollados de manera ineficiente debido al poco
conocimiento de los encargados del departamento de SI sobre las reglas del
negocio.

El departamento de SI sigue encargado de asignar los recursos dentro del
mismo y las prioridades a las diferentes peticiones sin estas estar acorde con
los objetivos estratgicos de la organizacin.


o Coordinacin SI - objetivos de la empresa. La eficiencia del departamento
de SI en cuanto al correcto funcionamiento de las aplicaciones desarrolladas
no es la esperada debido a la barrera que existe entre el departamento y el
resto de la organizacin, estas quejas y los altos costos de mantenimiento de
las instalaciones informticas hacen que la alta direccin de la empresa
afronte el problema de SI de una manera global.

La solucin propuesta es la de asignar los recursos dentro del departamento
de SI al nivel correspondiente dentro de la organizacin.

Esta manera de funcionar resta las responsabilidades planteadas inicialmente
al director del departamento de SI y crea confusin entre los involucrados en
dicho departamento sobre quien toma las decisiones en el departamento.
Para solucionar estos problemas se llega al acuerdo de desarrollar
procedimientos formales de planificacin de Sistemas de Informacin,
similares a los existentes en otras reas funcionales de la organizacin.
A partir de ese momento se establecen planes sistemticos de definicin de
necesidades de informacin coherentes con los objetivos estratgicos de las
unidades funcionales de la organizacin.

Se llega a derribar la barrera existente entre el departamento de SI y el resto
de la organizacin, llevando a una situacin en la que se establece una
comunicacin directa entre los planes de la organizacin y los planes de SI,
incluyendo adems las prioridades de la organizacin para la asignacin de
recursos en el rea de tecnologa de informacin para poder tomar decisiones
dentro de la misma.

A partir de esta elaboracin de la planificacin de SI, el responsable del
departamento ya no toma decisiones en cuanto a prioridades segn su
parecer, sino que es un coordinador del equipo que elabora el Plan de
Sistemas, la cual luego de ser aprobada por los directivos de la empresa, fija
los presupuestos, las polticas a aplicarse y el perodo de desarrollo.



Formulacin de planes de Tecnologa y Sistemas de Informacin
conjuntamente con los planes estratgicos de la organizacin.


o Interdependencia entre la estrategia de la organizacin y las Tecnologas y
Sistemas de Informacin. Ya superado el problema de aislamiento del
departamento de SI del resto de la organizacin, se plantea sacar el mximo
provecho de las tecnologas de informacin, ya que se vuelve difcil obtener
ventajas competitivas sostenibles sin los planes TI/SI, por esto es preciso
pasar a una situacin de cooperacin TI / SI estrategia de organizacin.



Formulacin de Planes de Sistemas de Informacin conjuntamente con los planes
estratgicos de la organizacin




Importancia de la planificacin estratgica de sistemas de informacin

La importancia dentro de una organizacin de poseer un Plan Estratgico de
Sistemas de Informacin fundamentalmente radica en alinear a la funcin
tecnologas de Informacin acordes a la estrategia corporativa, a objeto de hacer
eficiente y eficaz la inversin en tecnologa y sistemas de informacin. Esto es
muy til en el momento de pronosticar requerimientos de recursos con mayor
precisin y la asignacin de los mismos, tanto en recursos materiales como en
recuro humano.

Necesidad y beneficios del plan estratgico

o Necesidad
La decisin de realizar un estudio en profundidad de los Sistemas de
Informacin y recursos informticos de una organizacin parte de la
necesidad de conseguir unos objetivos de carcter general, que pueden
resumirse en los siguientes puntos:

Determinar la estrategia general de los Sistemas de Informacin.

Adecuar los sistemas actuales, tanto desde el punto de vista
organizativo como desde el tecnolgico.

Definir un horizonte hacia el que evolucionar a corto, medio y largo
plazo.

Potenciar la eficacia de la organizacin, interna y externamente.

Favorecer la mejora de la calidad profesional y de la gestin interna.

Reducir los costes de transformacin.


o Beneficios

Establecer el rumbo de la organizacin, sus objetivos, sus
prioridades, sus metas y sus estrategias.

Conocer con rigurosidad la realidad actual de la Organizacin y el
entorno que influye en ella.

Enmarcar el mejoramiento de la calidad y la acreditacin dentro de
un plan realista objetivo y factible.

Involucrar y sensibilizar a todas las reas funcionales de la
Organizacin en las respuestas a los problemas que la aquejan.
Alinear las actividades y optimizar el uso de los recursos de la
Organizacin en busca de una mayor eficiencia y aprovechamiento.


I I I . El plan de sistemas de informacin

El Plan de Sistemas de Informacin tiene como objetivo la obtencin de un marco
de referencia para el desarrollo de sistemas de informacin que responda a los
objetivos estratgicos de la organizacin.
Este marco de referencia consta de:
o Una descripcin de la situacin actual, que constituir el punto de partida del
Plan de Sistemas de Informacin. Dicha descripcin incluir un anlisis
tcnico de puntos fuertes y riesgos, as como el anlisis de servicio a los
objetivos de la organizacin.

o Un conjunto de modelos que constituya la arquitectura de informacin.

o Una propuesta de proyectos a desarrollar en los prximos aos, as como la
prioridad de realizacin de cada proyecto.

o Una propuesta de calendario para la ejecucin de dichos proyectos.

o La evaluacin de los recursos necesarios para los proyectos a desarrollar en
el prximo ao, con el objetivo de tenerlos en cuenta en los presupuestos.
Para el resto de proyectos, bastar con una estimacin de alto nivel.

o Un plan de seguimiento y cumplimiento de todo lo propuesto mediante unos
mecanismos de evaluacin adecuados.

Es fundamental que la alta direccin de la organizacin tome parte activa en la
decisin del Plan de Sistemas de Informacin con el fin de posibilitar su xito. La
direccin debe convencer a sus colaboradores ms directos de la necesidad de
realizacin del plan; de su apoyo de forma constructiva, mentalizndose de que la
ejecucin del mismo requerir la utilizacin de unos recursos de los cuales son
responsables.
La presentacin del Plan de Sistemas de Informacin y la constitucin del equipo
supone el arranque del proyecto y es fundamental que las ms altas instancias de la
organizacin estn implicadas en ambos, dando el apoyo necesario y aportando todo
tipo de medios. Explicar el plan a las personas de la organizacin y a las unidades
organizativas afectadas sobre las que recaer el Plan, el apoyo de los altos directivos
y la cualificacin de los recursos de las distintas unidades implicadas, sern factores
crticos de xito del Plan de Sistemas de Informacin.
El nivel de detalle con el que se har el estudio de la situacin actual depender de
la existencia de documentacin actual, de si hay personas que conozcan dicha
documentacin y de la predisposicin a una sustitucin total o parcial por sistemas
de informacin nuevos. En cualquier caso, como paso previo para detectar aspectos
importantes que puedan afectar a la organizacin, es necesario investigar sus puntos
fuertes, reas de mejora, riesgos y amenazas posibles y hacer un diagnstico de los
mismos.
Para la elaboracin del Plan de Sistemas de Informacin se estudian las necesidades
de informacin de los procesos de la organizacin afectados por el Plan, con el fin
de definir los requisitos generales y obtener modelos conceptuales de informacin.
Por otra parte se evalan las opciones tecnolgicas y se propone un entorno.
Tras analizar las prioridades relacionadas con las distintas variables que afectan a
los sistemas de informacin, se elabora un calendario de proyectos con una
planificacin lo ms detallada posible de los ms inmediatos. Adems, se propone
una sistemtica para mantener actualizado el Plan de Sistemas de Informacin para
incluir en l todos los cambios necesarios, garantizando el cumplimiento adecuado
del mismo.





Actividades

- PSI 1: Inicio del Plan de Sistemas de Informacin

El objetivo de esta actividad es determinar la necesidad del Plan de
Sistemas de Informacin y llevar a cabo el arranque formal del mismo,
con el apoyo del nivel ms alto de la organizacin. Como resultado, se
obtiene una descripcin general del Plan de Sistemas de Informacin que
proporciona una definicin inicial del mismo, identificando los objetivos
estratgicos a los que apoya, as como el mbito general de la
organizacin al que afecta, lo que permite implicar a las direcciones de
las reas afectadas por el Plan de Sistemas de Informacin.



- PSI 2: Definicin y Organizacin del PSI

En esta actividad se detalla el alcance del plan, se organiza el equipo de
personas que lo va a llevar a cabo y se elabora un calendario de
ejecucin. Todos los resultados o productos de esta actividad constituirn
el marco de actuacin del proyecto ms detallado que en PSI 1 en cuanto
a objetivos, procesos afectados, participantes, resultados y fechas de
entrega.



- PSI 3: Estudio de la Informacin Relevante

El objetivo de esta actividad es recopilar y analizar todos los
antecedentes generales que puedan afectar a los procesos y a las unidades
organizativas implicadas en el Plan de Sistemas de Informacin, as
como a los resultados del mismo. Pueden ser de especial inters los
estudios realizados con anterioridad al Plan de Sistemas de Informacin,
relativos a los sistemas de informacin de su mbito, o bien a su entorno
tecnolgico, cuyas conclusiones deben ser conocidas por el equipo de
trabajo del Plan de Sistemas de Informacin.





- PSI 4: Identificacin de Requisitos

El objetivo final de esta actividad va a ser la especificacin de los
requisitos de informacin de la organizacin, as como obtener un
modelo de informacin que los complemente.
Para conseguir este objetivo, se estudia el proceso o procesos de la
organizacin incluidos en el mbito del Plan de Sistemas de Informacin.
Para ello es necesario llevar a cabo sesiones de trabajo con los usuarios,
analizando cada proceso tal y como debera ser, y no segn su situacin
actual, ya que sta puede estar condicionada por los sistemas de
informacin existentes.
Del mismo modo, se identifican los requisitos de informacin, y se
elabora un modelo de informacin que represente las distintas entidades
implicadas en el proceso, as como las relaciones entre ellas.


- PSI 5: Estudio de los Sistemas de Informacin Actuales

El objetivo de esta actividad es obtener una valoracin de la situacin
actual al margen de los requisitos del catlogo, apoyndose en criterios
relativos a facilidad de mantenimiento, documentacin, flexibilidad,
facilidad de uso, etc. En esta actividad se debe tener en cuenta la opinin
de los usuarios, ya que aportarn elementos de valoracin, como por
ejemplo, su nivel de satisfaccin con cada sistema de informacin.
Se seleccionan los sistemas de informacin actuales que son objeto del
anlisis y se lleva a cabo el estudio de los mismos con la profundidad y
el detalle que se determine conveniente en funcin de los objetivos
definidos para el Plan de Sistemas de Informacin. Este estudio permite,
para cada sistema, determinar sus carencias y valorarlos. Esta valoracin
se utilizar en la actividad Diseo del Modelo de Sistemas de
Informacin (PSI 6), donde se analizar la cobertura de los sistemas de
informacin actuales con respecto a los requisitos.


- PSI 6: Diseo del Modelo de Sistemas de Informacin

El objetivo de esta actividad es identificar y definir los sistemas de
informacin que van a dar soporte a los procesos de la organizacin
afectados por el Plan de Sistemas de Informacin. Para ello, en primer
lugar, se analiza la cobertura que los sistemas de informacin actuales
dan a los requisitos recogidos en el catlogo elaborado en las
actividades Estudio de la Informacin Relevante (PSI 3) e Identificacin
de Requisitos (PSI 4). Esto permitir efectuar un diagnstico de la
situacin actual, a partir del cual se seleccionan los sistemas de
informacin actuales considerados vlidos, identificando las mejoras a
realizar en los mismos.
Por ltimo, se definen los nuevos sistemas de informacin necesarios
para cubrir los requisitos y funciones de los procesos no soportados por
los sistemas actuales seleccionados.
Teniendo en cuenta los resultados anteriores, se elabora el modelo de
sistemas de informacin vlido para dar soporte a los procesos de la
organizacin incluidos en el mbito del Plan de Sistemas de Informacin.

- PSI 7: Definicin de la Arquitectura Tecnolgica

En esta actividad se propone una arquitectura tecnolgica que de soporte
al modelo de informacin y de sistemas de informacin incluyendo, si es
necesario, opciones. Para esta actividad se tienen en cuenta
especialmente los requisitos de carcter tecnolgico, aunque es necesario
considerar el catlogo completo de requisitos para entender las
necesidades de los procesos y proponer los entornos tecnolgicos que
mejor se adapten a las mismas.



- PSI 8: Definicin del Plan de Accin

En el Plan de Accin, que se elabora en esta actividad, se definen los
proyectos y acciones a llevar a cabo para la implantacin de los modelos
de informacin y de sistemas de informacin, determinados en las
actividades Identificacin de Requisitos (PSI 4) y Diseo del Modelo de
Sistemas de Informacin (PSI 6), con la arquitectura tecnolgica
propuesta en la actividad Definicin de la Arquitectura Tecnolgica (PSI
7). El conjunto de estos tres modelos constituye la arquitectura de
informacin.
Dentro del Plan de Accin se incluye un calendario de proyectos, con
posibles alternativas, y una estimacin de recursos, cuyo detalle ser
mayor para los ms inmediatos. Para la elaboracin del calendario se
tienen que analizar las distintas variables que afecten a la prioridad de
cada proyecto y sistema de informacin. El orden definitivo de los
proyectos y acciones debe pactarse con los usuarios, para llegar a una
solucin de compromiso que resulte la mejor posible para la
organizacin.
Por ltimo, se propone un plan de mantenimiento para el control y
seguimiento de la ejecucin de los proyectos, as como para la
actualizacin de los productos finales del Plan de Sistemas de
Informacin.




- PSI 9: Revisin y Aprobacin del PSI
Esta actividad tiene como objetivo contrastar con los responsables de la
direccin del Plan de Sistemas de Informacin la arquitectura de
informacin y el plan de accin elaborados anteriormente, para mejorar
la propuesta si se considera necesario y por ltimo, obtener su
aprobacin final.




I V. Requisitos de los sistemas de informacin y de comunicaciones

Se definen en diferentes mbitos y con diferentes niveles de detalle.
Consideraremos las siguientes facetas para tipificar requisitos:

1. Entradas y salidas: Los requisitos de un sistema de informacin estn
esencialmente constituidos y organizados entorno a los mensajes de entrada
y de salida que el sistema requiere para cumplir sus funciones.

2. Eventos y objetos: Los requisitos de un sistema de informacin pueden
derivarse de expresiones que describen de dos maneras la realidad.
Expresiones en las que se describen los fenmenos del mundo como objetos
a travs de sus propiedades caractersticas o expresiones sobre los cambios
que se producen en los objetos del mundo.

3. Los mbitos: definen diferentes niveles desde los que se pueden considerar
los requisitos. Todo requisito debe adscribirse a un tipo de componente o
encapsulamiento sistmico.
En principio consideraremos tres mbitos distinguidos: reas de negocio,
procesos de negocio e interacciones comunicativas.

4. Genericidad de un requisito: Los requisitos se expresan en un cierto mbito
pero pueden ser genricos o especficos. Los requisitos de cualquiera de los
mbitos presentados deben concretarse mediante requisitos ms especficos.
Existen dos formas de concrecin de requisitos: la propagacin y el
refinamiento.

- Un requisito es propagable cuando afecta a una clase de elementos de
un mbito. Por ejemplo: En el proceso de facturacin todos los
importes se calcularn con una precisin de 9 decimales es un
requisito expresado en el mbito del proceso de facturacin
propagable a todas las definiciones de dominio para atributos de
importe.

- Un requisito es refinable cuando se puede concretar mediante una
coleccin de requisitos de mbito menor. Por ejemplo, un requisito
de un mensaje de entrada (Suceso 3 El sistema permitir la
asignacin de vehculos y conductores a las hojas de expedicin) se
debe refinar mediante requisitos que definan la comunicacin y la
reaccin del suceso. Un suceso es un requisito. Lo que ocurre es que
es un requisito complejo. Los requisitos complejos se refinan dando
lugar a una estructura compleja de requisitos.

5. Criterios de satisfaccin

- Objetivos: Independiente de las personas que la verifican. En ese
caso existe alguna mtrica especfica, algn procedimiento normado
para comprobar que el requisito se ha satisfecho.

- Subjetivos: Dependiente de la persona que aplica el criterio. El
criterio es interpretable. Ya no es una propiedad del requisito sino
una propiedad de la relacin entre la persona y el requisito.


Entradas y salidas

El problema del anlisis de requisitos es tan trivial como preguntar a los
usuarios que informacin necesitan conocer y como quieren verla.

La necesidad de una organizacin es la informacin, el disponer de ella. El jefe
de compras de una empresa querr saber las previsiones de ventas de las
prximas semanas para poder establecer la poltica de compras. El jefe de
fabricacin querr conocer el detalle de los pedidos existentes para poder
planificar las rdenes fabricacin. El director comercial querr conocer la
variacin en las tendencias de pedidos de sus clientes para poder gestionar
eficazmente su poltica de ventas.
La informacin es requerida por diferentes miembros de una organizacin para
poder tener un mejor control y eficacia en las funciones que debe acometer.

Si todas estas personas pudieran prescindir de la informtica seran felices. Su
necesidad es saber su problema como poder disponer de este conocimiento. Es
decir un sistema de informacin tiene valor porque ofrece informacin adecuada
para el desempeo de las funciones de la organizacin. El sistema de
informacin tiene el inconveniente de que requiere que se le comuniquen todos
aquellos hechos que luego se quieren conocer. Esas suele ser, desde el punto de
vista de los usuarios, el mayor inconveniente. Introducir los datos.

Es decir, la esencia de un sistema de informacin son los mensajes de salida que
tiene que proporcionar a los miembros organizacin para facilitar les su trabajo.

Para poder suministrar estos mensajes de salida habr que definir que mensajes
entrada son necesarios. Es decir cmo queremos disponer de informacin habr
que organizar una red de chivatos que se ocupen de capturar y obtener la
informacin que necesitamos.

- El SI como sistema de comunicaciones

Un SI es un subsistema de un sistema social responsable de proporcionar
a los actores que lo requieran los datos necesarios para poder acometer
sus funciones.

Existen dos intenciones de comunicacin en el mbito del sistema de
informacin.

o Poner en conocimiento del sistema la existencia de nuevos
fenmenos que han ocurrido en el sistema objeto. Se trata de los
mensajes de entrada o sucesos constructores.
o Obtener informacin sobre los hechos conocidos por el sistema.
Los mensajes de salida o sucesos consultores.

Los procesadores de entrada y salida que propone el modelo ISO son
responsables de entablar estas comunicaciones.



Los mensajes de entrada se obtienen mediante la red de adquisicin de
informacin que el sistema despliega. Supone el estudio, a diferentes
niveles comunicativos, de los modos, tiempos y recursos ms adecuados
para captura la informacin. El subsistema de adquisicin de
informacin debe estar adaptado al quehacer organizacional.

El sistema de informacin debe tener mecanismos que le permitan
conocer los cambios que se producen en el sistema objeto.



Cuando un cambio se ha producido en el sistema objeto, cuando algo
sucede, cuando ocurre un suceso, algn agente del sistema debe informar
de lo sucedido. En ocasiones puede transcurrir un tiempo entre la
ocurrencia de las cosas y su comunicacin al sistema. En cualquier caso
la informacin sobre lo sucedido debe llegar de alguna forma a la
frontera del sistema de informacin. Debe llegar a su entorno que
pertenecer al sistema social.

Hablaremos de mensajes de salida o sucesos de consulta para referirnos a
las comunicaciones que el sistema ofrece a los diferentes actores sociales
cuando lo solicitan. En tal caso el sistema se convierte en un emisor que
transmite a los actores representaciones del conocimiento que acumula.
Aqu la comunicacin no viene determinada por la observacin directa
del sistema objeto. Se trata de una necesidad de informacin para el
desempeo de alguna funcin especfica.



Es de gran importancia para el anlisis de sistemas de informacin la
conciencia de las actitudes comunicativas. El analista debe comprender
el contexto de los mensajes comunicados entre usuarios y sistema. Es
decir, debe comprender el significado que cada mensaje tiene para los
diferentes tipos de usuario

Eventos y objetos

Los fenmenos que observamos del mundo son complejos y de carcter
dinmico. Los seres humanos observan estos fenmenos sabiendo que son
procesos pero los perciben y describen estticamente. Nuestras limitaciones
cognitivas nos llevan a considerarlos de forma esttica o discreta. La evidencia
del carcter dinmico de las cosas est presente desde los filsofos
presocrticos.

Una observacin sobre el mundo es una correspondencia entre procesos y
propiedades. Aunque el mundo pueda estar constituido por procesos slo
sabemos describirlo en trminos de objetos y propiedades.

Para Jon Sowa los procesos pueden ser continuos o discretos. Estos ltimos
estn constituidos por los eventos y por los estados.

El nico aspecto que percibimos de los procesos es su variabilidad. Variabilidad
que detectamos pero que no siempre identificamos. Cuando observamos una
catarata somos conscientes de percibir un proceso. Sin embargo no somos
capaces de identificar estados. Nuestra capacidad descriptiva est limitada por
nuestra capacidad de identificacin de cosas. Como no de identificadores para
las gotas de agua no podemos dar una descripcin de estado compositiva de la
catarata. Nuestra percepcin se limita a predicar propiedades estadsticas de los
componentes como el caudal.







- Percepcin de eventos e individuos

La composicin de objetos y propiedades es una forma de ver o intuir los
procesos. Un proceso es un fenmeno dinmico en el que somos capaces
de percibir objetos relacionados. Percibimos que existen patrones de
relaciones entre objetos que se repiten en el tiempo con ciertas analogas.
Esa percepcin es nuestra intuicin de los procesos. No sabemos si existe
un nico proceso universal. Creemos que existen diferentes procesos que
no se influyen o que estn dbilmente influidos.

Nuestra observacin se limita a aislar aquellas caractersticas
relacionadas que pensamos que describen un proceso. Nuestras
limitaciones cognitivas se traducen en una fragmentacin continua de los
fenmenos.

Dos son las percepciones que tenemos de los procesos: Eventos e
individuos.

Un individuo, un objeto, es el resultado de la observacin de un proceso
en el que no somos capaces de percibir fluctuaciones o no tenemos la
capacidad o el inters de constatarlas (aunque a veces podamos suponer
que ese individuo podr cambiar en otras observaciones). As percibimos
una montaa como un individuo, un objeto esttico. Aunque sabemos
que un monte como el Everest est cambiando continuamente.

Un evento es el resultado de una observacin de un proceso en la que
somos capaces de percibir fluctuaciones que describimos mediante
propiedades.

Cuando una organizacin se dota de un sistema de informacin los
fenmenos en el sistema objeto pueden ser percibidos de forma esttica o
dinmica. Incluso un mismo tipo de fenmenos puede ser percibido
estticamente por unas personas o dinmicamente por otras.

Ambos tipos de fenmenos estn relacionados. Todo fenmeno esttico
es siempre generado por, al menos, un fenmeno dinmico. Podemos
considerar a las personas como un fenmeno esttico (una entidad
persona) o como el resultado de fenmenos dinmicos (nacer morir).
Las percepciones dependen de su relacin con los tipos de fenmenos en
cuestin.
Individuos y eventos son formas complementarias de nuestra percepcin
del mundo.





mbitos de los requisitos



- El mbito sistema

Las descomposiciones iniciales de un sistema tienen siempre la intencin
de reducir la complejidad. Este tipo de refinamientos se denomina
tambin functional breakdowns.

Cuando refinamos un sistema podemos utilizar criterios diversos.
Orgnicos: las interacciones que se dan en un determinado departamento.
Funcionales: las interacciones que pueden ocurrir para llevar a cabo una
determinada gestin. Temporales: las interacciones que tienen lugar
antes de que se celebre un evento, las que pueden ocurrir durante su
celebracin y las que pueden ocurrir una vez finalizado. Objetuales: las
interacciones que afectan a un tipo de objeto dado. Es posible, incluso,
cambiar el criterio cada vez que procedemos a un refinamiento.

La intencin de reduccin de complejidad conduce a subsistemas cuyas
componentes no son interacciones bsicas, no son sucesos, ni requieren
un orden temporal entre ellas, aunque pueda existir. Por ejemplo en una
organizacin el subsistema o rea de comercial compuesta por la gestin
de pedidos, la gestin de compras y la gestin de incidencias nos permite
abordar el estudio de cada una de ellas de forma prcticamente
independiente de las otras, satisfaciendo as el criterio de reduccin de
complejidad.

- El mbito de proceso

Los procesos de negocio estn siempre vinculados a eventos e
individuos. Un proceso describe el conjunto de cambios, sucesos
comunicativos, a los que se somete un determinado individuo que
denominamos objeto de negocio. El trmino objeto de negocio no
coincide con el concepto de objeto que se utiliza para el modelado de
datos. Los objetos de datos, las clases de objetos, son formas
fragmentarias mediante las cuales podramos representar un objeto de
negocio. Un objeto de negocio es una estructura de informacin
compleja que para los usuarios adquiere sentido por su composicin y
propiedades y por los procesos que lo manipulan.

Pueden ser objetos de negocio un pedido, una factura, un expediente de
licitacin o un prstamo. Cada uno de estos objetos de negocio podra ser
descrito mediante un modelo de datos compuesto por varias clases de
objetos. En realidad los objetos de negocio corresponderan ms bien al
concepto de esquema externo o de vista utilizado en las bases de datos.
El proceso supone una ordenacin en el tiempo de los diferentes cambios
que puede sufrir el objeto de negocio hasta que se considera finalizado.

En el mbito de los procesos consideraremos por lo tanto dos aspectos
complementarios:

o El conjunto de cambios, aportaciones de valor o eventos que un
objeto puede sufrir.
o La estructura y caractersticas, es decir el estado, del objeto de
negocio que se procesa.

Los requisitos asociados a un proceso estn constituidos
fundamentalmente por mensajes de entrada y mensajes de salida.

o Las diferentes entradas que informan de los cambios que se
producen en un objeto de negocio.
o Las diferentes salidas que informan de estos cambios a quien lo
necesite.
o Las diferentes salidas que dan una visin del estado de los objetos
de negocio que estn siendo o han sido procesados en algn
momento dado.




- El mbito de las interacciones comunicativas

Delimitar adecuadamente el mbito de las interacciones es de gran
importancia para el establecimiento de los requisitos. En sistemas de
informacin para la gestin, las interacciones entre el sistema y el
entorno son comunicaciones que se establecen intercambiando mensajes.

Estos mensajes estn asociados a sucesos constructores que comunican la
ocurrencia de nuevos acontecimientos en el sistema objeto que interesa a
una organizacin. Los procesos de negocio tienen que ver sobre todo con
los cambios que se producen en un objeto de negocio y, por tanto, con
los sucesos constructores que informan de los cambios que se producen
en el mundo.

En las comunicaciones que se establecen entre el entorno y el sistema de
informacin aparecen, de forma esencial, tres de las funciones
comunicativas establecidas por el lingista ruso Roman Jakobson.

o La funcin de contacto porque la comunicacin de todo mensaje
requiere el establecimiento previo de una conexin, una toma de
contacto.
o La funcin descriptiva porque el objetivo de las comunicaciones
en los sistemas de informacin es describir fenmenos que
ocurren en el sistema objeto.
o La funcin de influencia porque la organizacin disea sus
comunicaciones para poder reaccionar, segn sus propsitos, ante
los fenmenos que ocurren.

Cada interaccin comunicativa es un requisito para el sistema que habr
que desarrollar. Es un requisito genrico que debe ser refinado a travs
de una estructura dictada por esas tres funciones: contacto, descripcin e
influencia.

Esos tres aspectos estn vinculados a la idea de evento o suceso habitual
en el modelado conceptual.

Un suceso comunicativo es una interaccin de comunicacin entre el
entorno y el sistema de informacin. El suceso comunicativo tiene lugar
porque algo ha ocurrido en el sistema objeto de inters que la
organizacin observa. Algn agente del entorno organizacional ha tenido
conocimiento del fenmeno ocurrido y lo comunica a la organizacin
que dispondr de un canal especfico para ello. Cuando la organizacin
conoce esta comunicacin reacciona segn reglas y protocolos
establecidos.



Un suceso comunicativo, una interaccin comunicativa requiere:

o Que un agente contacte con el sistema para establecer una
comunicacin. Es lo que denominamos estmulo o disparo del
suceso.
o Que el agente confeccione una descripcin del fenmeno que ha
observado o del que ha tenido noticia y la transmita por el canal
establecido.
o Que el sistema reaccione como est establecido al conocer que
ese fenmeno que le interesaba ha ocurrido.

- El mbito de uso

Suponga que usted acude al servicio de correos para poner un telegrama.
Lo primero que tiene que hacer es localizar dnde puede realizar esta
gestin. Posiblemente deba usted adems proveerse del formulario
correspondiente.

Una vez haya localizado el entorno adecuado es posible que requiera
usted ciertas informaciones previas que podran afectar a la forma o al
contenido de su mensaje. Por ejemplo la lista de precios. Imagnese que
los precios van por bloques de palabras. Usted intentar maximizar el
uso del bloque.

Comenzar un proceso editorial en el que usted participar como
aportador de informacin escribiendo el mensaje en el formulario
previsto para ello.
El proceso editorial continuar con la colaboracin de alguna persona de
correos que proceder a un cambio de formato introduciendo el texto que
usted le proporcion mediante un teclado en algn artefacto especfico.

Esta persona realizar ciertas validaciones. Comprobar, por ejemplo,
que la poblacin a la que usted quiere enviar su mensaje existe o que el
pas al que usted pretende enviarlo dispone de servicio telegrfico.

Calcular el importe contando las palabras y aplicando la tarifa
correspondiente. Registrar en algn soporte los datos que la
organizacin de correos considere necesarios. Probablemente registre los
datos del emisor, del receptor, el importe cobrado, la fecha y da de la
operacin.

Por ltimo emitir un recibo y una copia del mensaje enviado que le
sern entregados para acreditar la operacin.

La serie de actividades descritas en este ejemplo son habituales en
cualquier interaccin de un sistema de informacin; independientemente
de los tipos soportes.
Como vemos en el ejemplo anterior, la descripcin de sucesos tiene dos
mbitos descriptivos: los requisitos del dominio del problema y los
requisitos del entorno de uso.

Cuando nos movemos en el mbito del problema la cuestin se centra en
identificar las interacciones, los mensajes asociados y la reaccin del
sistema frente a esos mensajes.

Cuando trabajamos en el mbito de la solucin la cuestin se centra en
ofrecer un soporte eficiente a la comunicacin. Pero podemos observar
que aparecen requisitos que en el domino del problema, en el modelo del
negocio, ni se plantean. Cmo encuentra un usuario de mi servicio la
ventanilla adecuada? Cuantos recursos son necesarios para
cumplimentar un cuestionario? El entorno de uso incorpora aspectos
pragmticos que en el entorno del negocio resultan accesorios.

Una de las principales caractersticas del entorno de uso es facilitar la
edicin de los mensajes.
Hasta tal punto que una interfaz puede considerarse un mero editor de
estructuras. De hecho es lo que el usuario percibe. El usuario no
desencadena sucesos sino ms bien procesos editoriales que permiten
construir mensajes que se comunican al sistema. La mayor parte del
tiempo que un usuario pasa ante una interfaz la dedica a la edicin. Por
ello el concepto base de nuestra aproximacin es el contexto editorial.

- El mbito de la infraestructura tecnolgica

Las aplicaciones requieren de un soporte sobre el que se despliegan e
instalan que deben garantizar parte de esa continuidad. Por soporte fsico
entendemos el hardware, el software de base (sistema operativo, sistemas
de gestin de base de datos, servidores de aplicaciones, etc.) y las
relaciones entre todos ellos. La infraestructura tecnolgica tiene al menos
dos aspectos. La arquitectura lgica de componentes software, que
supone la eleccin de un determinado framework para el desarrollo y la
arquitectura fsica en que se ubican estas componentes.

En el momento actual la arquitectura para infraestructura es objeto de
amplio debate y existen diferentes propuestas al respecto.

Quiz uno de los criterios a establecer es el diseo de acceso a los datos,
el control de redundancia y la optimizacin de base de datos.

Aqu la problemtica est guiada por dos aspectos:

o Uno que afecta directamente a los usuarios. El rendimiento: la
forma en que elegimos las componentes fsicas y lgicas para que
se adecuen a los requisitos de rendimiento.
o Otro que afecta a los desarrolladores pero tambin, a la larga, a la
economa de los clientes. El diseo: la eleccin que hacemos de
la arquitectura de componentes para disponer de un sistema
cohesivo y poco acoplado. Es decir fcilmente modificable o
mantenible.


V. La metodologa de planificacin y desarrollo de sistemas de informacin

Para la realizacin del Plan Estratgico de Sistemas de Informacin se cuenta con
varias metodologas que ayudan en el desarrollo del mismo, las cuales sern
expuestas a continuacin:


Procedimientos de Alineamiento de los Planes de Tecnologas y Sistemas de
Informacin con la Estrategia de Negocio

Esta metodologa se concentra en el estudio previo de la organizacin para as tomar
decisiones sobre qu hacer en el futuro con los sistemas de informacin.

El Plan Estratgico de Sistemas debe incluir:

o Una lista de proyectos a desarrollas en los prximos 3 a 5 aos. Estos
proyectos sern probablemente proyectos informticos, ya que para su
implementacin se utilizar la informtica, pero este tipo de proyectos no
tienen mayor relevancia en el desarrollo de esta metodologa.

o Referida a la situacin en el momento de prepara el Plan. Es decir, reconocer
el punto de partida del cual debe arrancar el Plan, esto implica un juicio
crtico de la situacin inicial, no solo desde un punto de vista tcnico, sino
desde un punto de vista de negocios, es decir, la utilidad de los SI existentes
desde el punto de vista de quienes lo utilizan diariamente.

o Prioridad de cada proyecto. Esta debe contemplar tanto aspectos de
importancia para el negocio, como aspectos tcnicos relacionados con la
implementacin utilizando una determinada infraestructura.

o Detalle suficiente que permita la evaluacin de los proyectos a desarrollar en
el primer ao en trminos de recursos necesarios, con el objeto de poder
incluirlos en el presupuesto anual correspondiente. Indicar todos los recursos
necesarios para el desarrollo de los proyectos ayudar a que la organizacin
lo coloque como parte de su presupuesto anual y se le asignen recursos a
dichos proyectos.

o Mecanismos de evaluacin. Estos deben ser adecuados para permitir los
procedimientos de control necesarios en el seguimiento del plan, es decir,
fundamentalmente un calendario y un presupuesto detallado.

o Lista de actividades de la organizacin en la cual la TI pueda utilizarse
como herramienta de soporte para aumentar su eficacia o eficiencia. La
direccin de la organizacin, aunque en este proceso la direccin tcnica
debe participar de igual manera, y debido a que el Plan debe contemplar a
toda la organizacin, es debido que el equipo que lo desarrolle tenga
conocimiento de toda la organizacin.


Es importante observar que el Plan de SI es muy poco tecnolgico, los detalles
tecnolgicos de incluirn nicamente cuando es estrictamente necesario, la
perspectiva de desarrollo de un Plan de SI es fundamentalmente una perspectiva de
negocio, no una perspectiva tecnolgica.

Al cumplirse con las especificaciones anteriormente nombradas, el procedimiento
deber tener integradas unificadamente las directrices estratgicas de la empresa con
las funciones y procesos de negocio de las distintas unidades de la organizacin.


Esquema general del procedimiento

Para la utilizacin de esta metodologa se supone previamente que la organizacin a
la cual se le pretende hacer el Plan de SI es una organizacin mediana o grande, ya
que se hace referencia a la existencia de ciertas funciones o porque se proponen
soportes documentales o tamaos de equipos de trabajo grandes para empresas de
menor tamao.

Aunque esto no supone un impedimento para empresas pequeas, ya que es
necesario que estas tengan tambin tengan un Plan de SI y su elaboracin constituye
un trabajo ms fcil que en una de mayor tamao.

Las fases citadas a continuacin suponen que es algo que se debe hacer, mas no
cmo hacerlo, aunque algunas pueden resultar claramente aplicables en
determinadas situaciones.

- Fase I: Presentacin y compromiso del equipo

El objetivo de esta fase es constituir el equipo de trabajo que llevar a
cabo la planificacin y su presentacin a la organizacin. Este Plan no
requiere nicamente de la dedicacin de recursos por parte del equipo de
desarrollo, sino que una de las partes ms importantes proviene de la
colaboracin en cuanto a entrevistas y sesiones de trabajo con el equipo
de planificacin por parte de los responsables de cada departamento y
rea funcional de la organizacin.



Actividades:

o Decisin de obtener un Plan de TI
o Formacin del grupo de trabajo
o Identificacin de reas de anlisis para describir el Sistema de
Informacin existente.


- Fase II: Descripcin de la situacin actual

Una vez constituido el equipo de trabajo y comprometida la organizacin
en conjunto con el esfuerzo de planificacin, el primer paso consiste en
describir la situacin de la organizacin desde dos puntos de vista:

o El negocio
o Los sistemas existentes

La descripcin de las funciones y procesos de negocio son esenciales
para poder poner las necesidades de informacin que se recogern en la
fase siguiente de manera correcta paro ayudar a la toma de decisiones de
asignacin de recursos.

Actividades:

o Identificacin de las principales funciones y procesos de negocio
por rea.
o Descripcin de los sistemas existentes. Procesos y estructuras de
datos.
o Crtica de los sistemas existentes, desde el punto de vista tcnico
y de negocio.
o Elaboracin del informe acerca de los sistemas existentes.


Fase III: Elaboracin del Plan de Sistemas de Informacin

En esta fase se lleva a cabo la planificacin propiamente dicha.
El primer paso es documentar las necesidades de informacin de cada una de las
funciones y procesos de negocio descritas anteriormente.
Se debe enfatizar en aquellas necesidades que los sistemas actuales no cubren o
cubren de manera no satisfactoria e incompleta.

Con las necesidades ya documentadas se deben formular propuestas de
actuacin que incidan de manera directa en las lneas estratgicas ms
importantes de la organizacin.

El resultado ser una serie de acciones de SI a realizarse durante el tiempo de
vigencia del Plan.

Actividades:

o Preparacin del equipo de trabajo para el anlisis de necesidades.

o Necesidades de TI y SI por rea, funciones y procesos de negocio.

o Descripcin sistemtica de necesidades. Procesos y Estructuras de Datos.

o Integracin.

o Elaboracin de propuestas alternativas para el plan de TI/SI. Evaluacin
de recursos necesarios.

o Elaboracin y aprobacin del definitivo Plan de TI/SI.


Fase IV: Programacin de actividades

En esta fase se detallan las acciones especficas en forma de proyectos a llevar a
cabo durante el primer ao de vigencia del Plan, como se haba mencionado
anteriormente, esto se lo realiza para que se asigne el presupuesto y los recursos
requeridos por el Plan para el desarrollo de las actividades.

Actividades:

o Descripcin detallada del Plan de TI/SI acordado.

o Inclusin de proyectos en el presupuesto del perodo siguiente.

o Plan de evaluacin y revisin.


La metodologa descrita es extensa y prolija, el motivo para tales caractersticas
es que pretende ser general y no es pensado, como ha sido descrito
anteriormente, para organizaciones de tamao pequeo, en las cuales el equipo
de trabajo podra quedar reducido a una persona de la direccin general y otra en
representacin del rea de SI, lo cual no entregara resultados objetivos con
relacin a todas las dependencias de la organizacin.

Acerca de la duracin del proceso, no se tiene un tiempo ya estipulado en lo que
tiene que ver en la duracin del proceso, hasta la elaboracin del Plan.

Precisamente porque en organizaciones de distinto tamao el proceso puede
simplificarse mucho o a su vez, alargarse mucho, en cuyo caso es importante
que el director del proyecto lo planifique y controle porque de otro modo ste se
alargar ms.

En otro orden, se puede mencionar que actualmente las herramientas
informatizadas que ayudan al desarrollo de estos proyectos son muy variadas,
especialmente en los casos de proyectos grandes.

A la hora de elegir una de estas herramientas hay que tomar en cuenta que
existen herramientas que sirven para cuando el Plan ya est desarrollado como
es el caso de las herramientas CASE y herramientas de control de proyectos.

Las herramientas que convienen son ayudas de proceso de documentar y
estructurar la informacin, como paquetes que facilitan el mantenimiento de un
catlogo de las entidades de datos o diccionario de datos, sus relaciones entre s,
procesos, relaciones entre funciones de negocios y procesos, etc.


Business Systems Planning (BSP). IBM

Esta metodologa fue desarrollada en los 60 por IBM al reconocer la
posibilidad que nuevos sistemas de informacin mejoraban la planificacin y
control de los problemas que encaraban las empresas en esa poca y como un
camino para incorporar estrategias de sistemas de informacin en estrategias
organizacionales y estrategias de negocios.

Es por esta necesidad que IBM busc la manera de integrar las diferentes reas
de la organizacin con el fin de mejorar el desempeo de estas, aunque
inicialmente esta metodologa fue pensada nicamente para su propio uso.
Posteriormente entregada como una metodologa de planeacin, con manuales y
entrenamiento para los usuarios.

Esta metodologa se basa en primero mostrar cmo se debe analizar y atender
una organizacin, identificando las fuentes y destinos de toda la informacin, se
agrupan estos flujos de datos en archivos y luego en aplicaciones y se concentra
en la identificacin de los requerimientos necesarios para poner en marcha una
organizacin.

La metodologa BSP es un ordenamiento de conceptos que aplicados a una
determinada organizacin, mediante sesiones de trabajo, entrevistas, anlisis,
discusin y documentacin, permiten elaborar el plan para la arquitectura de
sistemas de informacin que debe apoyar a la organizacin. Adems, es
genrica, utilizable por cualquier organizacin e independiente de la instalacin
utilizada por la empresa. Se preocupa de entender las relaciones existentes entre
los procesos, organizaciones, clases de datos, sistemas funcionales de aplicacin
y plataformas de comunicacin de datos.




En esta metodologa se encuentran dos partes bien diferenciadas que son:

o Planificacin Top-Down: Donde se fijan los objetivos del negocio y
corporativos, trazados por los ejecutivos, y especialistas de sistemas de
informacin. Despus, se examinan los datos que se necesitaran y se
disea una arquitectura de informacin que define la relacin existente
entre los datos.

o Bottom-Up: Que son las actividades especficas de desarrollo de
aplicaciones y que hace operativas las bases de datos que componen esa
arquitectura. De esta manera se suministran los datos y la informacin
necesaria para traducir esos objetivos en las funciones y procesos del
negocio. En esta etapa la actividad de los especialistas en sistemas de
informacin es mucho mayor.

Objetivos de la Metodologa

El principal objetivo de la metodologa BSP es generar una aplicacin de los
sistemas de informacin que soporten las necesidades de informacin a corto y
largo plazo que se encuentre integrado con el plan general de la organizacin.

o Proporcionar seguridad a los sistemas de informacin basados en procesos y
reglas de negocio que son totalmente autnomos a los cambios
organizacionales.

o Proveer de un mtodo objetivo para administrar la asignacin de prioridades
a los sistemas de informacin sin intereses particulares.

o Permitir interactuar el rea de informtica con el usuario a travs de
aplicaciones que respondan a las necesidades y requerimientos.

o Identificar datos como un recurso comn que sea usado para un objetivo
comn.

o Proporcionar un medio para determinar las necesidades futuras de recursos
computacionales en base a prioridades.

o Asegurar que los sistemas de informacin sern orientados por las
necesidades de la administracin y de los usuarios.


Componentes

La metodologa BSP se ocupa de dos grandes reas:

Procesos de Negocio
Clases de Datos

Los procesos de Negocio son decisiones y actividades requeridas para
administrar o dirigir los recursos del negocio.
Una clase de datos son datos lgicamente interrelacionados necesarios para dar
soporte a las actividades de la organizacin.

Fases de la metodologa

1. Presentacin y compromiso del equipo: Se constituye el equipo de
trabajo que llevar a cabo el esfuerzo de planificacin, que provienen de
los departamentos y reas funcionales de la compaa, los cuales tienen
que ser conscientes que el plan de TI/SI es un plan de toda la
organizacin, y de la necesidad de su apoyo.

2. Descripcin de la situacin actual desde dos dimensiones: Estas dos
dimensiones son acerca de los datos manejados y los procesos que
configuran los subsistemas existentes.

La informacin que se precisa acerca de los procesos para obtener una
descripcin razonable de stos es, por un lado su agrupacin por
subsistemas, es decir, a la implementacin de qu subsistema de
informacin pertenece cada proceso, la especificacin de qu datos
utiliza cada proceso en su funcionamiento, es decir, los inputs, la lista de
los datos que se crean o modifican como resultado de la operacin de
dichos procesos, es decir, los outputs, y una descripcin de cmo cada
uno de ellos est implementado, es decir, si forma parte de un gran
subsistema y el procedimiento de tratamiento de datos que el proceso
requiere.

Despus de la descripcin, se debe hacer una evaluacin de los sistemas
de informacin, donde se critica desde la perspectiva tecnolgica las
reas en las que es posible mejorar, y por otro lado desde la perspectiva
de negocio.

3. Elaboracin del plan de TI/SI: Se documentan todas las necesidades de
informacin de cada una de las reas funcionales de la empresa,
valorando sobre todo aquellas necesidades que los sistemas actuales no
cubren. El comit de sistemas aprueba el plan y se estima el coste
econmico de su implantacin.

4. Programacin de actividades: Esta programacin contendr el detalle
de las acciones en forma de proyectos a realizar durante el primer ao
del plan.

Se debe procurar proyectar las necesidades de informacin que se vayan
identificando, e registrar sobre la marcha las principales entidades de
datos que vayan saliendo, e ir imaginando los procesos necesarios para
generar la informacin cuya necesidad detectada. Una vez recogidas las
necesidades de informacin se debe realizar una labor de gabinete
dirigido a analizar las descripciones elaboradas antes para identificar la
estructura global del sistema de informacin.

Despus de analizar las necesidades de informacin queda claro qu
proyectos informticos son necesarios para implementar el sistema de
informacin de la empresa.

Ventajas:

o Determina la necesidad de nuevos sistemas de informacin y su
prioridad.

o Participacin tanto del nivel directivo como del personal de las
diferentes reas de la organizacin.

o Las aplicaciones informticas propuestas estn sustentadas en
una arquitectura de informacin de subsistemas que involucran la
participacin de procesos, clases de datos y la relacin entre
ellos.

o Se cuenta con un plan alternativo.

Desventajas:

o En la organizacin se implementa una sola arquitectura de
informacin, donde no se detecta de forma estratgica las reas
de ventaja potencial y no se explota de forma adecuada
aplicaciones informticas en beneficio de alcanzar los objetivos
de la organizacin.

o No propone mecanismos claros para realizar el anlisis o crear el
rea informtica dentro de la organizacin.

o El BSP sigue una secuencia de pasos que son de forma arbitraria
para determinar las clases de datos, los procesos, los datos, no
centrndose en los factores estratgicos de la organizacin.

o No especfica de forma adecuada los componentes necesarios que
soporten la produccin y mantenimiento de los planes
informticos como los son el hardware, el software, las
plataformas, el personal, etc.




Planificacin Estratgica de Sistemas de Informacin.
(PESI) Price Waterhouse

Fue desarrollada por Price Waterhouse en los 80. Busca obtener ventaja
competitiva para la empresa, actuando sobre las fuerzas que mueven el mercado a
travs de la aplicacin de tecnologa en informtica y de incentivar los mtodos
orientados a los datos.
Busca obtener ventaja competitiva para la empresa, actuando sobre las fuerzas que
mueven el mercado a travs de la aplicacin de tecnologa en informtica.

Caractersticas principales:

o Garantiza un desarrollo eficiente, viable y sistemtico.

o Alinea las acciones y las hace consistentes unas con otras.

o Planea la asignacin de recursos.

o Sienta las bases para controlar los proyectos, y equilibrar costos y
beneficios.

o Se encarga de establecer de una concordancia entre las estrategias de
negocios y las estrategias de TI, creando una ventaja estratgica y
otra competitiva.


Etapas del Desarrollo de la Metodologa:

o Etapa I: Definicin del por qu se efectuarn las inversiones en el
rea informtica y determinar las necesidades de la empresa.

o Etapa II: Definicin del qu es lo que informtica debe entregar y
cuales son las metas informticas.

o Etapa III y IV: Se baja progresivamente de nivel de abstraccin a
travs de la definicin de una estrategia para las aplicaciones y la
infraestructura tecnolgica y organizacional.


Ventajas:

o Obtiene soluciones de manera rpida, evitando el tiempo necesario
para llevar a cabo derivaciones.

o Permite evaluar soluciones, cuando no existe ningn mtodo
algortmico disponible.

o Provee soluciones completas, sin necesidad de contar con una
representacin total del dominio del problema.

o No genera una solucin si no puede ser recuperado un caso adecuado
a las circunstancias.

o Previene la toma de acciones para evitar errores pasados.


Desventajas:

o No es posible generar una arquitectura de informacin ya que se
carece de un modelo y normas para esto.

o Ayuda a no caer en errores pasados pero no encamina a no cometer
nuevos.

o La inexistencia de un trayecto simple desde la planificacin inicial
hasta la implementacin de la misma no es factible debido a que las
aplicaciones objetivos estn fundamentadas en factores estratgicos y
no en los requerimientos que satisfagan las necesidades de los
subsistemas de informacin que abarquen los procesos, clases de
datos e identidades respectivas.


FRONT Strategy. Deloitte, Haskins & Sells y Holland Systems Corporation

Fue desarrollada por Deloitte, Haskins & Sells y Holland Systems Corporation.
Esta Metodologa para la planificacin estratgica de sistemas de informacin
incluye:

o Mtodo.
o Soporte.
o Software.

Caractersticas principales:

El producto final de esta metodologa permite obtener o definir una arquitectura de
datos, una arquitectura de aplicaciones, una estrategia de tecnologas y un conjunto
de proyectos ordenados por prioridad. La metodologa est basada en el desarrollo
de un modelo de funciones que representan las acciones de la organizacin, ms un
anlisis de los objetivos de la sta, factores crticos de xito, prioridades
organizacionales, evaluacin de los sistemas de informacin actuales de la
organizacin, infraestructura tecnolgica y evaluacin de la administracin de
recursos informticos.


Fases de desarrollo:

o Desarrollo del modelo organizacional.
o Desarrollo de arquitecturas de datos y aplicaciones.
o Determinar los niveles de requerimientos de servicios.
o Inventariar los sistemas de informacin actuales.
o Evaluacin de los sistemas de informacin actuales.
o Desarrollar una estrategia de sistemas de informacin.
o Ampliar el modelo funcional y refinar arquitectura.
o Definir y dar prioridades a los proyectos.

Ventajas:

o Permite el correcto desarrollo de nuevos proyectos conociendo la
arquitectura de informacin actual.
o Crear relaciones entre las necesidades organizacionales y la situacin actual.

Desventajas:

o Evala los sistemas de informacin actuales pero no plantea la opcin de
conocer la necesidad de nuevos sistemas o subsistemas
o nicamente analiza la infraestructura actual y la arquitectura de
informacin, mas no da soluciones.


Strategic Information Planning. Arthur Andersen & Co

Fue desarrollada por Arthur Andersen & Co. El producto final de esta
metodologa permite obtener bsicamente una estrategia tecnolgica de
informacin para la empresa y un plan de implementacin. Este plan de
implementacin define los proyectos requeridos para la empresa, cataloga las
aplicaciones o subsistemas a ser desarrollados, destaca las necesidades de apoyo
de una organizacin en cuanto al uso efectivo de las tecnologas de informacin
e identifica las tecnologas para implementar el plan.

La metodologa se compone de 9 fases, detalladas a continuacin:

o Determinacin del alcance del proceso y organizacin.
o Evaluacin de los negocios y la competitividad.
o Evaluacin de la situacin actual.
o Generacin de oportunidades a travs de Tecnologas de
Informacin.
o Establecer plan estratgico de Tecnologas de Informacin.
o Establecer el plan organizacional.
o Establecer el plan tecnolgico.
o Establecer el plan de aplicaciones y datos.
o Establecer el plan de implementaciones.
COBIT7

COBIT ha sido desarrollado como un estndar generalmente aplicable y
aceptado para las buenas prcticas de seguridad y control en Tecnologa de
Informacin.

Este estndar es relativamente pequeo en tamao, con el fin de ser prctico y
responder, en la medida de lo posible, a las necesidades de negocio,
manteniendo al mismo tiempo una independencia con respecto a las plataformas
tcnicas de TI adoptadas en una organizacin. El proporcionar indicadores de
desempeo (normas, reglas, etc.), ha sido identificado como prioridad para las
mejoras futuras que se realizarn al marco referencial.

Objetivos:

Se determin que las mejoras a los objetivos de control originales deberan
consistir en:

o El desarrollo de un marco referencial para control en TI como
fundamento para los objetivos de control en TI y como una gua para la
investigacin consistente en el control de TI.

o Una alineacin del marco referencial general y de los objetivos de
control individuales, con estndares y regulaciones internacionales
existentes de hecho y de derecho.

o Una revisin crtica de las diferentes actividades y tareas que conforman
los dominios de control en TI y, cuando fuese posible, la especificacin
de indicadores de desempeo relevantes (normas, reglas, etc.)


Caractersticas principales:

o Orientado a los objetivos del negocio.

o Basado en los procesos, siguiendo el principio de reingeniera de
negocios.
o Considera a la informacin como el resultado de la aplicacin
combinada de recursos relacionados con la Tecnologa de Informacin
que deben ser administrados por procesos de TI.


Metodologa Cobit



Ventajas:

o Conduce a reas de investigacin que normalmente sin un marco
referencial o modelo no seran tratadas.

o Puede desarrollarse una planeacin y secuencia de entrevistas ms lgica
conforme se avanza en el proceso.

o Con los objetivos de control ayuda al estudio de todas las partes de la
organizacin, sin dejar a un lado ninguna necesaria.

Desventajas:

o La naturaleza detallada de la metodologa hace difcil la aplicacin
inicial, especialmente cuando se est verificando la consumacin y
aplicabilidad de los objetivos de control para el rea bajo revisin.

o Requiere de cierto formalismo como registrar informacin previa, que
puede parecer innecesario y tedioso.



VI . Mtricas y evaluacin para la calidad del software. La implantacin de la funcin
calidad

Muchas de las medidas que maximizan la calidad producen como efecto colateral
una diminucin en el coste, y viceversa. Tradicionalmente se piensa que aumentar la
calidad es aumentar el coste en tiempo. Pero muchas veces el tiempo invertido en
aumentar la calidad (robusto, flexible, mantenible, escalable) repercute en el futuro
en un menor coste de desarrollo o mantenimiento.
Valores abstractos del software:
o Robusto: libre de errores.

o Flexible: permite reutilizacin y adaptacin a nuevos requisitos.

o Mantenible: permite entender el cdigo tiempo despus de haber sido
escrito y/o por personas que no lo escribieron (estndares de sintaxis
y documentacin).

o Escalabilidad y rendimiento: al aumentar el nmero de usuarios, el
rendimiento no disminuye exponencialmente.

o Seguridad: existen herramientas que enfrentan a tu cdigo a una base
de datos de vulnerabilidades conocidas.
Las variables medibles (mtricas) que se ponen a continuacin estn centradas en el
cdigo, no en la gestin de proyectos (no se incluyen mtricas como esfuerzo del
equipo, etc.). Tampoco en temas propiamente web como la accesibilidad ni el
diseo de interfaces (usabilidad).
o Nmero de lneas de cdigo: tiene una utilidad limitada. Depende de la
forma de escribir el cdigo, la misma sentencia se puede escribir en una
o varias lneas, en diferentes lenguajes la misma funcionalidad puede
tener diferente cantidad de lneas, etc. Pero si se utiliza para comprar el
nmero de lneas de cdigo entre dos versiones del mismo software, se
puede observar si el crecimiento en lneas de cdigo es lineal o no. Si no
lo es, puede valer la pena investigar por qu.

o Cyclomatic Complexity y Npath Complexity: Se trata de analizar todos
los caminos que llevan al mismo cdigo y medir cuantos caminos hay.
Da una medida de la reutilizacin que se hace del cdigo. No se busca ni
maximizarla ni minimizarla, sino mantenerla entorno a una cifra.

o Code coverage: Porcentaje de cdigo cubierto por las pruebas. Se aplica
de forma prctica en las pruebas unitarias. Los principales frameworks
xUnit dan datos de code coverage. Se busca maximizarla.

o Cohesin: Mide la relacin entre las responsabilidades de las clases de
un mismo mdulo. Se busca maximizarla.

o Acoplamiento: Si dos clases estn poco acopladas, si se hace un cambio
en una de las clases repercutir poco o nada en la otra clase. Si estn muy
acopladas, un cambio en una clase supondr cambios importantes en la
otra. Se busca software con alta cohesin y bajo acoplamiento. El
acoplamiento se puede medir en funcin del nmero de imports
(includes), extends, implements, que relaciona a unas clases y mdulos
con otras.

Un software cuyo cdigo tiene una cohesin alta, un acoplamiento bajo, tiene un
alto porcentaje de cdigo cubierto por pruebas unitarias y/o funcionales, tiene
cdigo que se reutiliza desde diferentes partes y cuyas lneas crecen de manera
controlada, es un cdigo que permitir aadir funcionalidades fcilmente
(reduciendo el coste de aadirlas) y permitir mantener ms fcilmente el cdigo
existente.
Reingeniera de los procesos

Tanto la reingeniera de procesos comerciales, BRP (Business Process
Re-Engineering) como la reingeniera comercial, BRE (Business
ReEngineering) plantean nuevos desafos y tareas a los profesionales de
Tecnologa de la Informacin. Estos desafos son reflejo a su vez de
aquellos a los que se enfrentan las empresas:
- Alcanzar mejoras radicales en las reas de costos.
- Calidad.
- Servicio.
- Rapidez.

La tecnologa de objetos no resuelve estas tareas mediante una mejora
creciente de la forma en que se crean Sistemas de Informacin sino
cambiando radicalmente la estructura de estos.

a) La funcin frente al proceso

Una de las caractersticas bsicas de la reingeniera BRP es que
observa o analiza la empresa en trminos de procesos que cortan
las funciones tradicionales de los departamentos. Esto se
consigue observando internamente los departamentos funcionales
monolticos y encadenando esas actividades entre los diversos
departamentos, para culminar con el suministro de valor de los
clientes o con la obtencin de valor de los proveedores.
Los sistemas de informacin tradicionales se han inclinado sobre
todo por unidades funcionales monolticas, dando lugar a
aplicaciones que son ellas mismas monolticas. En contraste, los
sistemas orientados a objetos contienen conjunto de objetos en
cooperacin, que pueden ser empaquetados en aplicaciones y ser
compartidos por estas. Estos objetos pueden ser grandes o
pequeos, y tan sencillos o complejos como las actividades que
automatizan o soportan.

En ltima instancia, los sistemas orientados a objetos desecharan
el bagaje funcional de las aplicaciones y se concentraran en
suministrar objetos con los que los usuarios debern interactuar
en algn momento durante un proceso comercial, bien para
realizar algn computo o para extraer/manipular alguna
informacin. El fraccionamiento de la estructura monoltica de
las aplicaciones tendr efectos profundos en la forma en que se
definen los sistemas de informacin, en cmo se realice su
reingeniera, y en como sean construidos.

b) Modelizacin de sistemas

El cambio desde una visin funcional a una visin de proceso
plantea nuevos requerimientos respecto a la forma en que se
especifican y disean sistemas. Ya no ser suficiente con
descomponer funcionalmente la lgica de una aplicacin,
mantenindola separada de los datos sobre las que acta. Lo que
se necesita es un enfoque en la creacin de modelos que pueda
ser utilizado tanto para la conversin o mapping de procesos
comerciales como para modelizar los objetos necesarios para el
soporte de esos procesos. La tarea cambiara, desde el soporte de
una funcin comercial a soportar un flujo de trabajo o workflow a
lo largo de un proceso comercial. Los sistemas workflow
convencionales, que intentan orquestar el trabajo entre
aplicaciones monolticas y tareas manuales, no podrn en ltima
instancia ofrecer la flexibilidad que requieren las iniciativas BPR.
En contraste, los sistemas creados utilizando objetos estn
fundados inherentemente en un modelo workflow explicito que
anima a los diseadores de sistemas a distribuir el trabajo entre
mltiples objetos que actan en cooperacin.
La tecnologa de orientacin a objetos ofrece tcnicas de
modelizacin que permiten definir objetos y relacionarlos de
manera que puedan desarrollarse tanto procesos comerciales
como sistemas de informacin. Como existe un lenguaje
uniforme para expresar procesos comerciales y procesos de
informacin es posible establecer una relacin entre ambos.
As los procesos comerciales pueden actuar interactivamente con
objetos software, y el modelo de workflow puede establecerse
explcitamente de manera que muestre los cambios entre tareas
manuales y automticas.

La utilizacin de tcnicas de modelizacin para describir
empresas y actividades comerciales no es nueva, y ya se han
utilizado tcnicas de modelizacin de datos tradicionales para
crear modelos de empresa. Sin embrago, a diferencia de los
enfoques tradicionales, las tcnicas orientadas a objetos no
obligan a quienes crean los modelos de procesos comerciales a
dividir sus modelos artificialmente en datos y procesos, sino que
los objetos contienen todos los aspectos de los datos y de su
comportamiento, y pueden utilizarse para representar entidades
comerciales estticas, como departamentos, tareas comerciales
como aprobaciones de crditos, y subprocesos como tramitacin
de pedidos. Una consecuencia importante de esta aproximacin
de modelado uniforme es que, con el tiempo, el ajuste entre el
funcionamiento comercial y los sistemas de informacin se
mejorara. Es este aspecto de reconfigurabilidad el que esta
posicionando a los proyectos BPR como una ventaja comercial
progresiva, en lugar de cmo los puntos de revolucin aislados
que eran percibidos hasta ahora.

Reingeniera de sistemas

Los cambios incrementales en los procesos comerciales quedaran
reflejados en cambios en el modelo de objeto comercial y pueden dar
lugar a cambios en el modo de objeto de software. Los cambios radicales
en los procesos comerciales pueden dar lugar a la creacin de modelo de
objetos comerciales y de software radicalmente diferentes.
Tambin aqu, es posible reconstruir los modelos reutilizando objetos
que hayan sido previamente definidos y re orquestando la forma en que
actan interactivamente entre s. Adems, pueden introducirse nuevos
objetos que presenten nuevas prcticas comerciales, y relacionarlos con
objetos antiguos.
Para este proceso de reutilizacin de modelos de objetos existentes es de
importancia crtica la estructuracin o empaquetamiento y la gestin de
toda la variedad y numero de objetos. Por ejemplo, resultara
inmanejable considerar a cada objeto comercial como una tarea
elemental dentro de un proceso comercial. Las tcnicas de modelizacin
de objetos permiten estructurar los objetos como componentes de otros
objetos (acumulaciones) y tambin permiten que los objetos sean
refinamientos u optimizaciones de otros objetos. Estos dos mecanismos
de estructuracin hacen posible crear y desarrollar modelos e objetos en
formas que resulten ms tiles y significativas.
La acumulacin o suma de objetos permite agruparlos para formar
objetos mayores, mientras que el refinamiento de los objetos hace
posible la portabilidad de modelos de objetos, bien entre empresas y
organizaciones de un mismo sector, o entre organizaciones de diferentes
sectores.
As, un modelo de objeto que representase la atencin a clientes en el
sector hotelero, si fuera lo suficientemente general podra ser refinado
por dos cadenas de hoteles para introducir prcticas y conceptos
comerciales especficos, o podra ser utilizado por una organizacin
(tambin con los refinamientos apropiados) en el sector de los viajes de
empresa.
En trminos de reingeniera comparar procesos comerciales dentro de
sectores y entre sectores en un medio importante de mejoras de
reingeniera. La entrega de modelos de objetos comerciales genricos
con sus correspondientes modelos software permitir a las empresas una
rpida reingeniera de los sistemas de informacin que soportan los
procesos comerciales. En el caso de reingeniera BRE, es decir, los
programas de reingeniera comercial (en los que las empresas consideran
la posibilidad de pasar a nuevas actividades), resulta aun ms atractiva la
utilidad de los modelos de objetos comerciales estndar para el
desarrollo de nuevos sistemas.

Desarrollo de sistemas

Para el xito de la reingeniera es de importancia crucial el proceso de
ingeniera. Muchos procesos comerciales son el resultado de una simple
evolucin en el tiempo, y no han sido objeto de ingeniera alguna, por lo
que con frecuencia surge la confusin entre qu pasos de proceso existen
y como se ejecutan esos pasos. En la mayora de los enfoques BPR
existe una primera etapa en la que se separa el que del como de los
procesos comerciales.
La utilizacin de tcnicas de modelizacin de objetos en este proceso
resulta til, ya que la separacin entre lo que hace un objeto y como lo
hace es fundamental en la definicin de todas las descripciones de
objetos. As, tanto los modelos de objetos comerciales como los modelos
de objetos de software heredan esta separacin. Por otra parte, esta
separacin permite adoptar un enfoque elegante para una mejora
permanente de la eficiencia de los sistemas de informacin que soportan
los procesos comerciales. Segn van apareciendo formas de implementar
software, pueden introducirse una a una sin necesidad de producir
alteraciones en todo el sistema.
En el caso de los objetos de software, la separacin entre lo que hace un
objeto y como lo hace ofrece tambin otros beneficios dentro del
contexto de la creacin de sistemas. La organizacin OMG ha
especificado mecanismos tecnolgicos (conocidos como CORBA,
Common Object Request Broking Architecture) que permiten a los
objetos de software interactuar unos con otros en base a un mtodo
estndar (conocido como IDL, Interface Definition Language) capaz de
describir lo que hace un objeto independientemente de cmo lo hace.
Esto significa que pueden adquirirse objetos de software procedentes de
mltiples fuentes sin preocuparse por la incompatibilidad en la
implantacin, y que en las implantaciones de objetos de software no es
necesario utilizar lenguajes orientados a objetos, lo que significa a su vez
que el software antiguo tiene el potencial de ser reutilizado si puede ser
descrito utilizando el lenguaje IDL. Esto permitir a las empresas
concentrarse en desarrollar software para obtener una ventaja
competitiva e integrarlo con software corriente adquirido y adaptable a
medida de las propias necesidades o con sistemas antiguos ya existentes.
Al alcanzarse una masa crtica en el nmero de empresas y
organizaciones que desarrollan sistemas de informacin utilizando
objetos de software, tambin ser posible la interfuncionalidad o
interoperabilidad con sistemas de proveedores y clientes. Este nivel de
interfuncionalidad permitir la reingeniera de sistemas de cara a un
rediseo de la red comercial, en que las empresas deciden colaborar con
los proveedores o con los clientes con el fin de modificar los lmites y
fronteras de sus procesos comerciales internos.
Esto podr requerir una ampliacin de los procesos comerciales con el
fin de comprar directamente a los proveedores, por ejemplo bajo un
mtodo JIT (Just In Time).
Alternativamente, puede requerir tambin la contratacin de procesos
comerciales permitiendo a los clientes pedir productos o utilizar
servicios directamente, como en el caso de las operaciones bancarias
desde el hogar. Se conocen casos de fusiones y adquisiciones de
empresas que han fracasado por la incompatibilidad de sus sistemas de
informacin.
Eliminar procesos comerciales y someterlos a reingeniera con el fin de
obtener una ventaja competitiva conducir a la necesidad de una
reingeniera de sistemas de soporte. La tecnologa de objetos reduce al
mnimo el esfuerzo de desarrollo para nuevos sistemas al permitir la
reutilizacin de componentes de sistemas antiguos mientras se permite la
inclusin de nuevos componentes.
Si se est considerando acometer las reingeniera BRP, deber analizarse
los beneficios de la tecnologa de orientacin a objetos o correr el riesgo
de que los sistemas de informacin se conviertan en una carga para la
efectividad en la implantacin de procesos comerciales que hayan sido
objeto de reingeniera.

Bioreingenieria

La bio-reingenieria es un modelo biolgico de transformacin
empresarial y constituye un paso ms all de la reingeniera de procesos
que lidera Michael Hammer. La reingeniera y la calidad total parecen
estar afianzndose ms cada da en el mundo empresarial, constituyendo
una revolucin en la forma de hacer negocios.
La bio-reingenieria o transformacin empresarial es un nuevo concepto
aportado por Francis Gouillart y James Kelly en su obra Transforming
the Organization. La tesis central de estos autores es que si las empresas
quieren mantener o asumir una posicin de liderazgo tienen que
transformarse y no simplemente modificar sus procesos o su gestin
empresarial. Es el viraje del simple cambio o la trasformacin lo que
brinda un interesante valor agregado a las tesis sobre reingeniera. Este
valor agregado consiste en colocar el cambio dentro del contexto cultural
de la empresa, constituyndose en una transformacin empresarial
integralmente considerada.
El vehculo que se utiliza para lograr la integracin en la bio-reingenieria
consiste en comparar las empresas con organismos vivos, bajo la premisa
de que las sociedades, al igual que los seres vivientes, nacen, crecen,
maduran, se envejecen, se enferman, se recuperan, y finalmente mueren.
Las empresas, al igual que las personas, tienen su propio carcter: unas
son ms inteligentes, algunas ms solidas, otras ms rpidas, ms de una
ms productiva, etc.


Ingeniera inversa

El anlisis de un sistema para identificar sus componentes actuales y las
dependencias que existen entre ellos, para extraer y crear abstracciones de dicho
sistema e informacin de su diseo [Chifofsky, 1990].

El proceso de analizar el cdigo, documentacin y comportamiento de un
sistema para identificar sus componentes actuales y sus dependencias para
extraer y crear una abstraccin de sistema e informacin de diseo. El sistema
en estudio no es alterado, sino que se produce conocimiento adicional acerca del
sistema [SEI, 2004].

Ingeniera Inversa, un proceso de reingeniera

La ingeniera inversa tiene la misin de desentraar los misterios y
secretos de los sistemas en uso. Consiste principalmente en recuperar el
diseo de una aplicacin a partir del cdigo.
Esto se realiza principalmente mediante herramientas que extraen
informacin de los datos, procedimientos y arquitectura del sistema
existente.

Es aplicable a sistemas con las siguientes caractersticas:

- Documentacin inexistente o totalmente obsoleta.

- Programacin en bloque de cdigos muy grandes y/o sin
estructurar.

- Inexistencia de documentacin interna en los programas, o bien
esta es incomprensible o est desfasada.

- La aplicacin cubre gran parte de los requisitos y del
rendimiento esperado.

- La aplicacin est sujeta a cambios frecuentes, que pueden
afectar a parte del diseo.

- Se prev que la aplicacin pueda tener aun larga vida.

La ingeniera inversa puede extraer informacin de diseo del
cdigo fuente, pero el nivel de abstraccin, la completitud de la
documentacin, el grado con el cual trabajan al mismo tiempo las
herramientas y el analista humano, y la direccionalidad del proceso
son sumamente variables [Cass, 1988].

o Nivel de abstraccin

El nivel de abstraccin de un proceso de ingeniera inversa y las
herramientas que se utilizan para realizarlo aluden a la
sofisticacin de la informacin de diseo que se puede extraer del
cdigo fuente. El nivel de abstraccin ideal deber ser lo ms alto
posible, es decir, el proceso de ingeniera inversa debe ser capaz
de derivar:

- Sus representaciones de diseo de procedimiento (con un
bajo nivel de abstraccin).

- La informacin de las estructuras de datos y de programas
(un nivel de abstraccin ligeramente ms elevado).
- Modelos de flujo de datos y de control (un nivel de
abstraccin relativamente alto).

- Modelos de entidades y de relaciones (un elevado nivel de
abstraccin).

A medida que crece el nivel de abstraccin se proporciona al
ingeniero de software informacin que le permitir
comprender ms fcilmente estos programas [Pressman,
2003].


o Completitud

La completitud de un proceso de ingeniera inversa alude al nivel
de detalle que se proporciona en un determinado nivel de
abstraccin. En la mayora de los casos, la completitud decrece a
medida que aumenta el nivel de abstraccin. Por ejemplo, dado
un listado del cdigo fuente, es relativamente sencillo desarrollar
una representacin de diseo de procedimientos completa.
Tambin se pueden derivar representaciones sencillas del flujo de
datos, pero es mucho ms difcil desarrollar un conjunto
completo de diagramas de flujo de datos o un diagrama de
transicin de datos.

La completitud mejora en proporcin directa a la cantidad de
anlisis efectuado por la persona que est efectuando la
ingeniera inversa [Pressman, 2003].

o Interactividad

La interactividad alude al grado con el cual el ser humano se
integra con las herramientas automatizadas para crear un proceso
de ingeniera inversa efectivo. En la mayora de los casos, a
medida que crece el nivel de abstraccin, la interactividad deber
incrementarse, o si no la completitud se ver reducida [Pressman,
2003].

o Direccionalidad

Si la direccionalidad del proceso de ingeniera inversa es mono
direccional, toda la informacin extrada del cdigo fuente se
proporcionara a la ingeniera del software que podr entonces
utilizarla durante la actividad de mantenimiento. Si la
direccionalidad es bidireccional, entonces la informacin se
suministrara a una herramienta de reingeniera que intentara
reestructurar o regenerar el viejo programa [Pressman, 2003].
o El proceso de ingeniera inversa

El proceso de ingeniera se representa en la siguiente figura.
Antes de que puedan comenzar las actividades de ingeniera
inversa, el cdigo fuente no estructurada (sucia) se reestructura
para que solamente contenga construcciones de programacin
estructurada. Esto hace que el cdigo fuente sea ms fcil de leer,
y es lo que proporciona la base para todas las actividades
subsiguientes de ingeniera inversa.



El ncleo de la ingeniera inversa es una actividad denominada
extraccin de abstracciones. El ingeniero tiene que evaluar el viejo
programa y a partir del cdigo fuente (que no suele estar
documentado) tiene que extraer una especificacin significativa
del proceso que se realizara, la interfaz de usuario que se aplica y
las estructuras de datos de programa o de base de datos que se
utiliza [Pressman, 2003].

o Reestructuracin

la transformacin desde una forma de representacin a otra en el
mismo nivel de abstraccin, preservando las caractersticas
externas del sistema (funcionalidad y semntica) [Chifofsky,
1990].

La reestructuracin de software modifica el cdigo fuente y/o los
datos en un intento de adecuarlo a futuros cambios. En general, la
reestructuracin no modifica la arquitectura global del programa.
Tiene a centrarse en los detalles de diseo de mdulos
individuales y en estructuras de datos locales definidas dentro de
los mdulos. Si el esfuerzo de la reestructuracin se extiende ms
all de los lmites de los mdulos y abarca la arquitectura del
software, la reestructuracin pasa a ser ingeniera directa.

Arnold define un cierto nmero de beneficios que se pueden
lograr cuando se reestructura el software:

- Programas de mayor calidad con mejor documentacin
y menos complejidad, y ajustados a las practicas y
estndares de la ingeniera del software moderna.

- Reduce la frustracin entre ingenieros del software que
deban trabajar con el programa, mejorando por tanto la
productividad y haciendo ms sencillo el aprendizaje.

- Reduce el esfuerzo requerido para llevar a cabo las
actividades de mantenimiento.

- Hace que el software sea ms sencillo de comprobar y de
depurar.

La reestructuracin se produce cuando la arquitectura bsica
de la aplicacin es solida, aun cuando sus interioridades
tcnicas necesitan un retoque. Comienza cuando existen
partes considerables del software que son tiles todava, y
solamente existe un subconjunto de todos los mdulos y datos
que requieren una extensa modificacin.

o Redocumentacion

La redocumentacion es tambin una forma de ingeniera inversa. Es el
proceso mediante el que se produce documentacin retroactivamente
desde un sistema existente. Si la redocumentacion toma la forma de
modificacin de comentarios en el cdigo fuente, puede ser considerada
una forma suave de reestructuracin. Sin embargo, puede ser
considerada como una sub-rea de la ingeniera inversa porque la
documentacin reconstruida es usada para ayudar al conocimiento del
programa.
Se piensa en ella como una transformacin desde el cdigo fuente a
pseudocdigo y/o prosa, esta ultima considerada como ms alto nivel de
abstraccin que la primera.
Aunque la aparicin de multitud de herramientas facilita las labores de la
ingeniera inversa, es la labor humana (humanware) la decisiva a la hora
de completar el estudio del sistema [Tilley, 1995].