P. 1
ingenieria de sistemas software por gls

ingenieria de sistemas software por gls

4.38

|Views: 19.042|Likes:
Publicado porAndres
Útil para Desarrollo de Software
Útil para Desarrollo de Software

More info:

Published by: Andres on Nov 01, 2007
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/18/2014

pdf

text

original

Definimos tecnología de software como un conjunto integrado
de notaciones, herramientas y métodos, basados en unos sólidos funda-
mentos, que permiten el desarrollo de un producto software en un
contexto organizativo dado.

Una tecnología de software puede considerarse constituida por
los siguientes componentes (ver Figura 14):

Tecnologías de software

INGENIERÍA DE SISTEMAS DE SOFTWARE

76

A)Marco de razonamiento. Por marco de razonamiento nos
referimos al conjunto de conceptos y mecanismos que una
tecnología de software posee para asegurar que el sistema
en desarrollo satisfaga las propiedades que se deseen. Se
basa en la existencia de unos conceptos rigurosos y bien
relacionados o, mejor aún, de un modelo matemático para
representar la ejecución de un programa. Este modelo
matemático, convenientemente manipulado, permite obtener
información sobre el sistema en construcción.

Idealmente, una tecnología de software debería permitir
asegurar a lo largo de todo el proceso de desarrollo que el
sistema satisfaga los requisitos exigidos, tanto funcionales
como no funcionales. Desgraciadamente, esto no sucede así
con las tecnologías actuales. Por un lado, el razonamiento
en las fases iniciales del ciclo de vida exige una precisión en
la descripción del sistema de la que se carece con las técnicas
usualmente utilizadas (en todo caso, se dispone de
descripciones funcionales); por otra, las decisiones tomadas
en la etapa de diseño arquitectónico se pierden en la maraña
de decisiones de bajo nivel que es necesario adoptar en la
fase de implementación (unas por razones de eficiencia, otras
por las propias limitaciones de los lenguajes empleados).

Pocos diseñadores hacen uso explícito del marco de razona-
miento que les ofrece la tecnología que utilizan. Casi siempre
se relega en la funcionalidad de las herramientas software
empleadas.

B)Notaciones. Lenguajes para poder describir el sistema en
desarrollo. En el desarrollo de un sistema complejo coexisten
diversas notaciones empleadas en las diferentes fases del
modelo de ciclo de vida seleccionado dado que no es posible
con una única notación cubrir las necesidades de cada una
de las fases.

77

Contar con la notación adecuada constituye además el
vehículo para poder razonar sobre el sistema en desa-
rrollo. Esta es la razón por la que ambas cosas (notación
y marco de razonamiento) se confunden en la práctica
del desarrollo de software. Todos los lenguajes ejecutables
empleados poseen una definición semántica con la que
es posible determinar si una descripción concreta es
correcta.

C)Herramientas. Un sistema implementado implica un contrato
con la máquina sobre la que se ejecuta. Este contrato fuerza
a disponer de sistemas software que traduzcan la descripción
efectuada por el diseñador en otra adaptada para la máquina
y generada automáticamente a partir de una descripción de
más alto nivel.

Esta necesidad, surgida desde los comienzos de la
informática (y motivada por la necesidad de alejarse de los
lenguajes de la máquina) no sólo requiere del desarrollo de
un traductor (compilador o intérprete) sino también de un
conjunto de herramientas software que soporten diferentes
actividades durante el desarrollo de un sistema: editores
sensibles al lenguaje, depuradores, optimizadores,
generadores de casos de prueba, etc. Estas herramientas
no son tampoco elementos aislados puesto que sus entradas
y salidas son también salidas y entradas de otras herra-
mientas llegando a constituir entornos integrados de
herramientas. Estas herramientas son dependientes de la
infraestructura de ejecución (hardware/software) como se
expuso en el Capítulo 1.

D)Método de desarrollo. Disponer de notaciones y
herramientas no implica que los diseñadores conozcan cómo
diseñar un sistema de relativa complejidad. Ello implica
también disponer de procedimientos para pasar de los

Tecnologías de software

INGENIERÍA DE SISTEMAS DE SOFTWARE

78

requisitos al diseño y de éste a la implementación, aprove-
chando las notaciones y herramientas disponibles y sabiendo
cómo dividir el trabajo entre los componentes del equipo
humano de desarrollo.

Los métodos proporcionan una disciplina en el proceso de
refinamiento que guía al diseñador a lo largo de varias fases,
desde la descripción de los requisitos en lenguaje natural
hasta su completa especificación. Posteriormente, a esa
especificación se le añaden las decisiones de diseño
continuando el proceso de refinamiento hasta poder
implementar el sistema en un lenguaje convencional.

En este sentido, los métodos no son independientes del
modelo de ciclo de vida elegido ya que tienen que soportar
el desarrollo a lo largo de algunas de sus fases y proporcionar
los heurísticos de refinamiento asociados.

E)Directrices de aplicación industrial. Las peculiaridades
de un dominio de aplicación quedan reflejadas en
conjuntos de soluciones probadas y difundidas entre la
comunidad de diseñadores para aspectos parciales de
los sistemas requeridos. El conocimiento del dominio de
aplicación se concreta en conceptos, elementos, interco-
nexiones y datos que solucionan aspectos concretos.
Estas soluciones toman la forma de módulos ampliamente
utilizados y, por tanto, reutilizables, patrones de diseño
de gran aceptación e incluso formas de utilizar los
lenguajes y herramientas adaptados al dominio de
aplicación considerado.

En muchos dominios de aplicación se han consolidado
bibliotecas de componentes (por ejemplo, funciones
matemáticas o para realizar interfaces gráficas)
reutilizables que simplifican y reducen el tiempo de

79

desarrollo. Podemos decir que el saber-hacer de una
organización en un determinado dominio de aplicación
se manifiesta en su capacidad para buscar soluciones
eficientes para los productos en desarrollo dentro de ese
dominio.

Obsérvese que son las relaciones entre las componentes las
que permiten hablar de una tecnología de software. Sus
componentes son como piezas de un «puzzle» que deben encajar
unas en otras. En otras palabras, la relación entre los componentes
implica la existencia de una imbricación entre ellas basada en la
integración conceptual de los elementos de cada componentes y no
simplemente del uso que cada diseñador le dé; globalmente deben
contribuir al desarrollo del sistema de software de una forma
coordinada.

En el lenguaje cotidiano, algunas veces se habla de una
tecnología de software cuando sólo afecta a una parte del desarrollo.
Esta situación es común cuando las notaciones, herramientas, etc.,
sólo permiten abordar el desarrollo en una de las fases. Para el resto
de las fases deberían utilizarse otras «tecnologías». Esta visión de
ámbito reducido de la tecnología implica que para el desarrollo completo
de un sistema será necesario utilizar diversas tecnologías de software
de ámbito reducido encadenadas.

De la discusión anterior se desprende que el impacto de una
tecnología de software (o su alcance) no siempre es el mismo. Con
independencia de las consecuencias que eso tendrá para la adopción
de nuevas tecnologías (Capítulo 6), el impacto nos permite analizar la
complementariedad entre tecnologías de software.

El impacto de la tecnología se puede entender desde tres
perspectivas complementarias: fases del ciclo de vida soportadas,
rango de sistemas en los que es aplicable y perfiles técnicos o
equipos de desarrollo afectados por la misma.

Tecnologías de software

INGENIERÍA DE SISTEMAS DE SOFTWARE

80

La Figura 15 refleja esta visión en dónde se representan tres
tecnologías diferentes. La tecnología A sólo soporta las fases finales
del ciclo de vida (implementación y pruebas asociadas), su utilización
está ligada a un único componente del equipo de trabajo y su utilización
es válida para un tipo muy concreto de sistemas (por ejemplo, sistemas
de información (SI)). Por el contrario, la tecnología C tiene un impacto
mucho mayor al afectar a varias fases, implicar a personas con diferen-
tes perfiles técnicos y poder aplicarse a un rango mucho mayor de
sistemas (por ejemplo, sistemas distribuidos (DIST)).

Finalmente, la tecnología B se encuentra en una posición
intermedia enfocada a las fases de diseño e implementación (por
ejemplo, para Sistemas de Tiempo Real (STR)).

Si consideramos el proceso de desarrollo en su conjunto, puede
ser necesario emplear diferentes tecnologías adaptadas a diferentes
fases del ciclo de vida. De esta manera, se utilizan progresivamente
notaciones, herramientas, métodos y formas de razonar sobre el sistema
dentro de un dominio de aplicación dado aportados por las diferentes
tecnologías consideradas. Cada actividad, asimismo se detalla en un
conjunto de procesos cuya imbricación, controles, entradas y salidas
permiten obtener el sistema deseado.

La Tabla 1 relaciona estos elementos con las fases de un ciclo
de vida. En cada una de las celdas de la tabla indicamos el objetivo
del componente.

3.3.Panorama de los componentes tecnológicos

Antes de analizar en el Capítulo 4 el empleo de algunas
tecnologías concretas para el caso de los Sistemas de Tiempo Real,
vamos a describir la situación actual en cada una de las componentes
indicadas. Ello nos permitirá analizar la situación en la que se encuentran
y su posible evolución futura.

81

Tecnologías de software

INGENIERÍA DE SISTEMAS DE SOFTWARE

82

83

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->