1.1 El software y su importancia.

1.1.1 Evolucin del Software.

Para que el hardware o parte del material de una computadora pueda funcionar,
es necesario tener un conjunto de normas y rdenes para coordinar todos los
procesos que realicen. Este conjunto se denomina Software o parte inmaterial del
sistema. Gracias al Software (integrado por multitud de programas que interactan
unos con otros) pueden ser manejados todos los recursos de que dispone un
sistema para resolver cualquier aplicacin Informtica.
El software es el material que convierte a una computadora en una herramienta.
Sin el software, una computadora es justo un grande, caro, intil, pedazo corto y
grueso de plstico, acero y silicn.
El software es lo que hace a una computadora comprtese la manera que se
necesita. Por ejemplo, el software del procesador de palabras (Word) hace a la
computadora comportarse como una mquina de escribir. El software de un
sistema informtico es el conjunto de elementos lgicos necesarios para realizar
las tareas encomendadas al mismo.
Podemos definirlo del siguiente modo: El software es la parte lgica que dota al
equipo fsico de capacidad para realizar cualquier tipo de trabajos.
Para nombrar al software de un modo ms formal tomaremos la siguiente
definicin:
Software: Definido por la IEEE como "programas de computadora,
procedimientos, documentacin asociada y datos relativos a la operacin de un
sistema informtico".

1.1.1 Evolucin del Software.

Las etapas de evolucin que sufri el software a travs de los aos se peden
clasificar como a continuacin se muestra:
Primera era:
Durante los primeros aos lo normal era que el hardware fuera de propsito
general. Por otra parte, el software se diseaba a medida para cada aplicacin y
tena una distribucin relativamente pequea. El software como producto (es decir,
programas desarrollados para ser vendidos a uno o ms clientes) estaba en su
infancia. La mayora del software se desarrollaba y era utilizado por la misma
persona u organizacin. La misma persona lo escriba, lo ejecutaba y, si fallaba, lo
depuraba. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban
seguros de que esa persona estar all cuando se encontrara algn error. Debido
a este entorno personalizado del software, el diseo era un proceso implcito,
realizado en la mente de alguien, y la documentacin normalmente no exista.
Segunda era:
La segunda era en la evolucin de los sistemas de computadora se extiende
desde la mitad de la dcada de los sesenta hasta finales de los setenta. La
multiprogramacin y los sistemas multiusuario introdujeron nuevos conocimientos
de interaccin hombre-mquina. Las tcnicas interactivas abrieron un nuevo
mundo de aplicaciones y nuevos niveles de sofisticacin del hardware y del
software. Los sistemas de tiempo real podan recoger, analizar y transformar datos
de mltiples fuentes, controlando as los procesos y produciendo salidas en
milisegundos en lugar de en minutos. Los avances en los dispositivos de
almacenamiento en lnea condujeron a la primera generacin de sistemas de
gestin de bases de datos.
La segunda era se caracteriz tambin por el establecimiento del software como
producto y la llegada de las casas del software . El software ya se desarrollaba
para tener una amplia distribucin en un mercado multidisciplinario. Los
programas se distribuan para computadoras grandes y para minicomputadoras, a
cientos e incluso a miles de usuarios.
Tercera era:
La tercer era en la evolucin de los sistemas de computadora comenz a
mediados de los aos setenta y continu ms all de una dcada. El sistema
distribuido, mltiples computadoras, cada ejecutando funciones concurrentemente

y comunicndose con alguna otra, incremento notablemente la complejidad de los

sistemas informticos .
Las redes de rea local y de rea global, las comunicaciones digitales de alto y
ancho de banda y la creciente demanda de acceso instantaneo a los datos,
supusieron una fuerte presin sobre los desarrolladores del software. An ms, los
sistemas y el software que lo permitan continuaron residiendo dentro de la
industria y de la academia. El uso personal era extrao.
La conclusin de la tercera se caracteriz por la llegada y amplio uso de los
microprocesadores. El microprocesador ha producido un extenso grupo de
productos inteligentes, desde automviles hasta hornos de microondas, desde
robots industriales hasta equipos de diagnstico de suero sanguneo, pero
ninguno ha sido ms importante que la computadora personal.
Cuarta era:
La cuarta era de la evolucin de sistemas informticos se aleja de las
computadoras individuales y de los programas de computadoras, dirigindose al
impacto colectivo de las computadoras y del software. Potentes mquinas
personales controladas por sistemas operativos sofisticados, en redes globales y
locales, acompaadas por aplicaciones de software avanzadas se han convertido
en la norma. Las arquitecturas informticas estn cambiando de entornos
centralizados de grandes computadoras a entornos descentralizados
cliente/servidor. De hecho Internet se puede observar como un software al que
pueden acceder usuarios individuales.

Resumen de la evolucin del Software:

Primera Era

Segunda Era

Tercera Era

Cuarta Era

Sistemas personales
Sistemas Distribuidos. potentes.
Orientacin por lotes
(batch).
Distribucin Limitada.
Software a medida.

Multiusuario.
Tiempo Real.
Bases de Datos.
Producto de software.

Incorporacin de
"Inteligencia"
Hardware de bajo
costo.
Impacto en el
consumo.

Tecnologas Orientadas
a Objetos.
Sistemas expertos.
Computacin en
Paralelo.
Redes de computadora

Sin embargo, un conjunto de problemas relacionados con el software ha persistido

a travs de la evolucin de los sistemas basados en computadora, y estos
problemas continan aumentando.
1. Los avances del software continan dejando atrs nuestra habilidad de
construir software para alcanzar el potencial del hardware.
2. Nuestra habilidad de construir nuevos programas no pueden ir al ritmo de la
demanda de nuevos programas, ni podemos construir programas lo
suficientemente rpido como para cumplir las necesidades del mercado y
de los negocios.
3. El uso extenso de computadoras ha hecho de la sociedad cada vez ms
dependiente de la operacin fiable del software. Cuando el software falla,
pueden ocurrir daos econmicos enormes y ocasionar sufrimiento
humano.
4. Luchamos por construir software informtica que tenga fiabilidad y alta
calidad.
5. Nuestra habilidad de soportar y mejorar los programas existentes se ve
amenazada por diseos pobres y recursos inadecuados.

.2 Caractersticas y Aplicaciones.

1.2.1 Evolucin hacia la Industria del Software.

Caractersticas del software

Para poder comprender lo que es el software (y consecuentemente la ingeniera
del software) es importante examinar las caractersticas del software que lo
diferencian de otras cosas que los hombres pueden construir. El software es un
elemento del sistema que es lgico, en lugar de fsico, por tanto el software tiene
unas caractersticas considerablemente distintas a las del hardware:
1. El software se desarrolla, no se fabrica en sentido clsico. Aunque
existen similitudes en el desarrollo del software y la construccin del
hardware, ambas actividades son fundamentalmente diferentes. En ambas
actividades la buena calidad se adquiere mediante un buen diseo, pero la
fase de construccin del hardware puede introducir problemas de calidad
que no existen (o son fcilmente corregibles) en el software. Ambas
actividades dependen de las personas, pero la relacin entre las personas
dedicadas y trabajo realizado es completamente diferente para el software.
Ambas actividades requieren la construccin de un "producto", pero los
mtodos son diferentes.

2. El software no se "estropea". El hardware exhibe relativamente muchos

fallos al principio de su vida (estos fallos son atribuibles normalmente a
defectos del diseo o de la fabricacin); una vez corregidos los defectos, la
tasa de los fallos cae hasta un nivel estacionario (bastante bajo con un poco
de optimismo) donde permanece durante un cierto periodo de tiempo. Sin
embargo, conforme pasa el tiempo, los fallos vuelven a presentarse a
medida que los componentes del hardware sufren los efectos acumulativos
de la sociedad, la vibracin. Los malos tratos, las temperaturas extremas y
muchos otros males externos. Sencillamente, el hardware comienza a
estropearse. El software no es susceptible a los males del entorno, que
hacen que el hardware se estropee. Por tanto, los defectos no detectados
harn que falle el programa durante las primeras etapas de su vida. Una
vez que se corrigen estos errores, se llega a un nivel optimo de trabajo y
podemos afirmar que el software no se estropea. Pero se deteriora!. Esto
que parece una contradiccin, durante su vida el software, sufre cambios
(mantenimiento). Conforme se hacen los cambios, es bastante probable
que se introduzcan nuevos defectos, lentamente, el nivel mnimo de fallos
comienza a crecer, el software se va deteriorando debido a los cambios.
Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el

software. Cuando un componente de hardware se estropea, se sustituye

por una "pieza de repuesto". No hay piezas de repuesto para el software.
Cada fallo en el software indica un error en el diseo o en el proceso
mediante el que se tradujo el diseo a cdigo mquina ejecutable. Por
tanto, el mantenimiento del software tiene una complejidad
considerablemente mayor que la del mantenimiento del hardware.

3. La mayora del software se construye a medida, en vez de ensamblar

componentes existentes. Se puede comprar software ya desarrollado
pero slo como una unidad completa, no como componentes que pueden
reensamblarse en nuevos programas. Aunque se ha escrito mucho sobre
"Reutilizacin de Sotware" slo estamos comenzando a ver la primera
implementaciones con xito de este concepto.
Aplicaciones del software
El software puede aplicarse en cualquier situacin en la que se haya definido
previamente un conjunto especifico de pasos procedimientos (es decir, un
logaritmo). El contenido y determinismo de la informacin son factores importantes
a considerar para determinar la naturaleza de una aplicacin del software. El
contenido se refiere al significado y a la forma de la informacin de entrada y de
salida. Algunas veces es difcil establecer categoras genricas para las
aplicaciones del software que sean significativas. Las siguientes reas del
software indican la amplitud de as aplicaciones potenciales:
Software de sistemas. El software de sistemas es un conjunto de programas que
han sido escritos para servir a otros programas. Algunos programas de sistemas
(p. Ej.: compiladores, editores y utilidades de gestin de archivos) procesan
estructuras de informacin complejas pero determinadas. Otras aplicaciones de
sistemas (p. Ej.: ciertos componentes del sistema operativo, utilidades de manejo
de perifricos, procesadores de telecomunicaciones) procesan datos en gran
medida indeterminados. En cualquier caso el rea del software de sistemas se
caracteriza por una fuerte interaccin con el hardware de la computadora; una
gran utilizacin por mltiples usuarios; una operacin concurrente que requiere
una planificacin, una comparacin de recursos y una sofisticada gestin de
procesos; unas estructuras de datos complejas y mltiples interfaces externas.
Software de tiempo real. El software que mide/analiza/controla sucesos del
mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos
del software de tiempo real se incluyen: un componente de adquisicin de datos
que recolecta y da formato a la informacin recibida del entrono externo, un
componente de anlisis que transforma la informacin segn lo requiera la
aplicacin, un componente de control/salida que responda al entorno externo y un
componente de monitorizacin que coordina todos los dems componentes, de
forma que pueda mantenerse la respuesta en tiempo real (tpicamente en el rango

de 1 milisegundo a 1 minuto). Un sistema de tiempo real debe responder dentro de

unas ligaduras estrictas de tiempo.
Software de gestin. El procesamiento de informacin comercial constituye la
mayor de las reas de aplicacin del software. Los sistemas discretos (p. Ej.:
nminas, cuentas de haberes/dbitos, inventarios, etc.) han evolucionado hacia el
software de sistemas de informacin de gestin (SIG), que accede a una o ms
bases de datos grandes que contienen informacin comercial. Las aplicaciones en
esta rea reestructuran los datos existentes para facilitar las operaciones
comerciales o gestionar la toma de decisiones. Adems de las tareas
convencionales de procesamiento de datos, las aplicaciones de software de
gestin tambin realizan clculo interactivo (p. Ej.: procesamiento de
transacciones en puntos de ventas).
Software de ingeniera y cientfico. El software de ingeniera y cientfico esta
caracterizado por los algoritmos de manejo de nmeros. Las aplicaciones van
desde la astronoma a la vulcanologa, desde el anlisis de la presin de los
automotores a la dinmica orbital de las lanzaderas espaciales y desde la biologa
molecular a la fabricacin automtica. Sin embargo, las nuevas aplicaciones del
rea de ingeniera/ciencia se han alejado de los algoritmos convencionales
numricos.
Software empotrado. Los productos inteligentes se han convertido en algo
comn en casi todos los mercados de consumo e industriales. El software
empotrado reside en memoria de slo lectura y se utiliza para controlar productos
y sistemas de los mercados industriales y de consumo. El software empotrado
puede ejecutar funciones muy limitadas y curiosas (p. Ej.: el control de las teclas
de un horno de microondas) o suministrar una funcin significativa y con
capacidad de control (p. Ej.: funciones digitales en un automvil, tales como
control de gasolina, indicaciones en el salpicadero, sistemas de frenado, etc.).
Software de computadoras personales. El mercado del software de
computadoras personales ha germinado en la pasad dcada. El procesamiento de
textos, las hojas de clculo, los grficos por computadora, multimedia,
entretenimientos, gestin de bases de datos, aplicaciones financieras, de negocios
y personales, y redes o acceso a bases de datos externas son algunas de los
cientos de aplicaciones.
Software de Inteligencia Artificial. El software de inteligencia artificial (IA) hace
uso de algoritmos no numricos para resolver problemas complejos para los que
no son adecuados el clculo o el anlisis directo. Actualmente, el rea ms activa
de la IA es la de los sistemas expertos, tambin llamados sistemas basados en el
conocimiento. Sin embargo, otras reas de aplicacin para el software de IA es el
reconocimiento de patrones (imgenes y voz), la prueba de teoremas y juegos. En
los ltimos aos se ha desarrollado una rama del software de IA llamada redes
neuronales artificiales.

1.2.1 Evolucin hacia la Industria del Software

A inicios de la informtica la preocupacin de desarrollo se centraba en el

hardware, se buscaba mejorar su costo y eficiencia; el software era visto como un
"complemento", se viva la poca de desarrollo de software como "ARTE" , el
desarrollo del software estaba supeditado a la disponibilidad de recursos, de
programas, de hardware y a la concepcin y capacidad del programador. En este
contexto surgieron problemas tanto para el programador como par los usuarios.
Problemas para el Usuario

Problemas para el Desarrollador

Programas de software complejos y difciles de

Gran inversin en aprendizaje, pues el software resultaba comprender.
difcil de manejar, los usuarios a parte del costo del
software, deban incurrir en costos de capacitacin.
Reutilizacin de cdigo muy limitada. Mantenimiento
complejo.
Mantenimiento del Software caro.
Aplicaciones no portables, el software se desarrollaba
Sistemas independientes, no se enlazaban unos con para funciones en un determinado equipo; las plataformas
otros "ni siquiera dentro de un departamento" por lo que eran independientes, las tecnologas propietarias.
pensar en enlazar sistemas con otras empresas era
imposible.
El software desarrollado no era amigable, el diseo y la
interfaz variaban segn la aplicacin.

Hoy en da, el software agrega valor a la empresa, pues es uno de los principales
encargados del manejo de la informacin. Vivimos en le "era de la informacin" ,
las empresas se preocupan por la correcta administracin de su informacin, la
tecnologa de informacin desempea funcin primordial en las organizaciones,
convirtindose en el factor que marca la diferencia para el logro de "ventaja
competitiva" . As, el software realiz su propia revolucin industrial, variando en
su entorno de tal manera que es inconcebible cometer los errores de desarrollo
que se presentaban en la poca del desarrollo de software como "Arte".

1.3 Mitos del Software

Muchas de las causas de las crisis del software se pueden encontrar en una
mitologa que surge durante los primeros aos del desarrollo del software. Hoy, la
mayora de los profesionales competentes consideran a los mitos por lo que son
actitudes errneas que han causado serios problemas, tanto a los gestores como
a los tcnicos. Sin embargo, las viejas actitudes y hbitos son difciles de
modificar, y todava se cree en algunos restos de los mitos del software.
Mitos de gestin.
Los gestores con responsabilidad sobre el software, como los gestores en la
mayora de las disciplinas, estn normalmente bajo la presin de cumplir los
presupuestos, hacer que no se retrase el proyecto y mejorar la calidad.
Mito.
Tenemos ya un libro que esta lleno de estndares y procedimientos para construir
software. No le proporciona ya a mi gente todo lo que necesita saber?.
Realidad.
Esta muy bien que el libro exista, pero se usa?, conocen los trabajadores su
existencia?, refleja las prcticas modernas de desarrollo de software?, es
completo?. En muchos casos, la respuesta a todas estas preguntas es "no".
Mito.
Mi gente dispone de las herramientas de desarrollo de software ms avanzadas,
despus de todo, les compramos las computadoras ms modernas.
Realidad.
Se necesita mucho ms que el ltimo modelo de computadora grande (o de PC)
para hacer desarrollo de software de gran calidad. Las herramientas de ingeniera
del software asistida por computadora (CASE), aunque la mayora todava no se
usen, son ms importantes que el hardware para conseguir buena calidad y
productividad.
Mito.
Si fallamos en la planificacin, podemos aadir ms programadores y adelantar el
tiempo perdido (el llamado algunas veces "concepto de la horda mongoliana").

Realidad.
El desarrollo de software no es un proceso mecnico como la fabricacin. En
palabras de Brooks [BRO75]: << ... aadir gente a un proyecto de software
retrasado lo retrasa an ms>>. Al principio, esta declaracin puede parecer un
contra sentido. Sin embargo, cuando se aaden nuevas personas, le necesidad de
aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad
de tiempo gastado en el desarrollo productivo. Puede aadirse gente, pero slo de
una manera planificada y bien coordinada.
Mitos del cliente.
Un cliente que solicita una aplicacin de software puede ser una persona del
despacho de al lado, un grupo tcnico de la sala de abajo, el departamento de
ventas o una compaa exterior que solicita un software bajo contrato. Los mitos
conducen a que el cliente se cree una falsa expectativa y finalmente, quede
insatisfecho con el que desarrolla el software.
Mito.
Una declaracin general de los objetivos es suficiente para comenzar a escribir los
programes; podemos dar los detalles ms adelante.
Realidad.
Una mala definicin inicial es la principal causa del trabajo baldo en software. Es
esencial una descripcin formal y detallada del mbito de la informacin,
funciones, rendimiento, interfaces, ligaduras del diseo y criterios de validacin.
Estas caractersticas pueden determinarse slo despus de una exhaustiva
comunicacin entre el cliente y el analista.
Mito.
Los requisitos del proyecto cambian continuamente, pero os cambios pueden
acomodarse fcilmente, ya que el software es flexible.
Realidad.
Es verdad que los requisitos del software cambian, pero el impacto del cambio
vara segn el momento en que se introduzca. La Figura 1.5 ilustra el impacto de
los cambios. Si se pone cuidado al dar la definicin inicial, los cambios solicitados
al principio pueden acomodarse fcilmente. El cliente puede revisar los requisitos
y recomendar las modificaciones con relativamente poco impacto en el costo.
Cuando los cambios se solicitan durante el diseo del software, el impacto en el
costo crece rpidamente. Ya se han acordado los recursos a utilizar y se ha
establecido un esqueleto del diseo. Los cambios pueden producir trastornos que

requieran recursos adicionales e importantes modificaciones del diseo; es decir,

costo adicional. Los cambios en la funcin, rendimiento, interfaces u otras
caractersticas, impacto importante sobre el costo. Cuando se solicitan al final de
un proyecto, los cambios pueden producir un orden de magnitud ms caro que el
mismo cambio pedido al principio.
Mitos de los desarrolladores.
Los mitos en los que an creen muchos desarrolladores se han ido fomentando
durante cuatro dcadas de cultura informtica. Durante los primeros das del
desarrollo del software, la programacin se vea como un arte. Las viejas formas y
actitudes tardan en morir.
Mito.
Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha
terminado. Realidad. Alguien dijo una vez: << cuanto ms pronto se comience a
escribir cdigo, tardara en terminarlo >>. Los datos industriales indican que entre
el cincuenta y el sesenta por ciento de todo el esfuerzo dedicado a un programa
se realizar despus de que se le haya entregado al cliente por primera vez.
Mito.
Hasta que no tengo el programa << ejecutndose >> realmente no tengo forma de
comprobar su calidad.
Realidad.
Desde el principio del proyecto se puede aplicar uno de los mecanismos ms
efectivos para garantizar la calidad del software: la revisin tcnica formal. La
revisin del software es un << filtro de calidad >> que se ha comprobado que es
ms efectivo que la prueba, para encontrar ciertas clases de defectos en el
software.
Mito.
Lo nico que se entrega al terminar el proyecto es el programa funcionando.
Realidad.
Un programa funcionando es slo parte de una configuracin del software que
incluye programas, documentos, y datos. La documentacin es la base de un buen
desarrollo y, lo que es ms importante, proporciona guas para la tarea de
mantenimiento del software.

Mucho profesionales del software reconocen la falacia de los mitos descritos

anteriormente. Lamentablemente, las actitudes y mtodos habituales, fomentan
una pobre gestin y malas prcticas tcnicas, incluso cuando la realidad dicta un
mtodo mejor. El reconocimiento de la s realidades del software es el primer paso
hacia la formulacin de soluciones practicas para su desarrollo.

1.4 Ingeniera del Software.

La respuesta ms concreta contra la creacin y la generalizacin de nuevos mitos

se encuentra en la ceracin de una rama de la ingeniera que se encargar de las
cuestiones que ataen al software, de esta manera surge la ingeniera del
software:
[La ingeniera del software] es el establecimiento y uso de principios robustos de
la ingeniera a fin de obtener econmicamente software que sea fiable y que
funcione eficientemente sobre mquinas reales.
E1 IEEE [IEEE93] ha desarrollado una definicin ms completa. Ingeniera de
software: (1) La aplicacin de un enfoque sistemtico, disciplinado y cuantificable
hacia el desarrollo, operacin y mantenimiento del software; es decir, la aplicacin
de ingeniera al software. (2) El estudio de enfoques como en (1).
Para este curso en particular tomaremos la siguiente definicin como nuestra lnea
base para todo el desarrollo futuro:
Ingeniera de Software: Es el establecimiento y la utilizacin de las tcnicas de
ingeniera orientadas a la elaboracin de nsoftware econmico, confiable y
eficiente. La ingeniera de Software define estndares para el desarrollo de
software de calidad.
Una visin general de la ingeniera del software
La ingeniera es el anlisis, diseo, construccin, verificacin y gestin de
entidades tcnicas (o sociales). Con independencia de la entidad a la que se va a
aplicar ingeniera, se deben cuestionar y responder las siguientes preguntas:
Cul es el problema a resolver?
Cules son las caractersticas de la entidad que se utiliza para resolver el
problema?
Cmo se realizar la entidad (y la solucin)?
Cmo se construir la entidad?
Qu enfoque se va a utilizar para no contemplar los errores que se cometieron
en el diseo y en la construccin de la entidad?
Cmo se apoyar la entidad cuando usuarios soliciten correcciones,
adaptaciones y mejoras de la entidad?

El trabajo que se asocia a la ingeniera del software se puede dividir en tres fases
genricas, con independencia de rea de aplicacin, tamao o complejidad del
proyecto. Cada fase se enfrenta con una o varias cuestiones de las destacadas
anteriormente.
La fase definicin se centra sobre el qu. Es decir, durante la definicin, el que
desarrolla el software intenta identificar qu informacin ha de ser procesada, que
funcin y rendimiento se desea, qu comportamiento del sistema, qu interfases
van a ser establecidas, qu restricciones de diseo existen, y que criterios de
validacin se necesitan para definir un sistema correcto. Por tanto, han de
identificarse los requisitos clave del sistema y del software. Aunque los mtodos
aplicados durante la fase de la definicin variarn dependiendo del paradigma de
ingeniera del software (o combinacin de paradigmas) que se aplique, de alguna
manera tendrn lugar tres tareas principales:
Ingeniera de sistemas o de informacin.
Planificacin del proyecto del software.
Anlisis de los requisitos.
La fase de desarrollo se centra en el cmo. Es decir, durante el desarrollo un
ingeniero de software intenta definir cmo han de disearse las estructuras de
datos, cmo ha de implementarse la funcin como una arquitectura del software,
cmo han de implementarse detalles procedimentales , cmo han de
caracterizarse las interfaces, cmo ha de traducirse el diseo el un lenguaje de
programacin (o lenguaje no procedimental) y cmo ha de realizarse la prueba.
Los mtodos aplicados durante la fase de desarrollo variarn, aunque las tres
tareas especficas tcnicas deberan ocurrir siempre:
Diseo del software.
Generacin de cdigo.
Prueba del software.
La fase de mantenimiento se centra en el cambio. Que va asociado a la
correccin de errores, a las adaptaciones requeridas a medida que evoluciona el
entorno del software, y a cambios debidos a las mejoras producidas por los
requisitos cambiantes del cliente. La fase de mantenimiento vuelve a aplicar los
pagos de las fases de definicin y de desarrollo, pero con el contexto del software
ya existente. Durante la fase de mantenimiento se encuentran cuatro tipos de
cambios:

Correccin. Incluso llevando a cabo la mejores actividades de garanta de

calidad, es muy probable que el cliente descubra defectos en el software. El
mantenimiento correctivo modifica el software para corregir lo defectos.
Adaptacin. Con el paso del tiempo, es probable que cambie el entorno original
(p. Ej.: CPU, el sistema operativo, las reglas de empresa, las caractersticas
externas de productos) para el que se desarroll el software. El mantenimiento
adaptativo produce modificacin en el software para acomodarlo a los cambios de
su entorno externo.
Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir
funciones adicionales que van a producir beneficios. El mantenimiento perfectivo
lleva al software ms all de sus requisitos funcionales originales.
Prevencin. El software de computadora se deteriora debido al cambio, y por esto
el mantenimiento preventivo tambin llamado reingeniera del software, se debe
conducir para permitir que el software sirva para las necesidades de los usuarios
finales. En esencia, el mantenimiento preventivo hace cambios en programas de
computadora a fin de que se puedan corregir, adaptar y mejorar ms fcilmente.

1.5 Paradigmas de la Ingeniera de Software.

Definicin de Paradigma: Para la Ingeniera de Software el paradigma es una

agrupacin de mtodos, herramientas y procedimientos con el fin de describir u
modelo.
Un "paradigma" es un modelo para comprender la realidad, que nos permite
relacionarnos con el mundo circundante y tener un sentido de identidad dentro de
lo que percibimos que es "el mundo real".
Fases Generales del Proceso de Desarrollo de Software:
Independientemente del procedimiento de desarrollo, la aplicacin del software y
el tamao del proyecto; el desarrollo de software contiene tres fases genricas
definicin, desarrollo y mantenimiento, desde la concepcin de desarrollo
estructurado de software.

Fase general

Descripcin
Parte fundamental del desarrollo de software.

De definicin.

Identifica los requisitos clave del sistema.

Producto final: el ERS , documento base para el control del cumplimiento de
requerimientos de usuario.
Referida a cmo han de disearse los componentes del software.

De desarrollo.

De
mantenimiento

Comprende etapas como diseo de estructuras, modelo de requisitos, diseo

de interfaz, estructura de la base de datos, codificacin y prueba por parte del
programador y del cliente.
Fase post implantacin.
Aplica las etapas de las fases de definicin y desarrollo sobre el software final.

Los paradigmas de la ingeniera de software conservan estas fases generales,

variando los mtodos, las herramientas y procedimientos para aplicarlos.
Paradigmas de la Ingeniera de Software:
La ingeniera del Software define paradigmas de desarrollo estructurado como
base a seguir en un proyecto de Software. Si ninguno de estos paradigmas se

adecua al problema por resolver, entonces el desarrollador se ver obligado a

combinar los paradigmas o definir uno nuevo.
Para resolver los problemas reales de una industria, un ingeniero del software o un
equipo de ingenieros deben incorporar una estrategia de desarrollo que acompae
al proceso, mtodos, capas de herramientas.
La estrategia a menudo se llama modelo de proceso o paradigma de ingeniera del
software. Se selecciona un modelo de proceso para la ingeniera del software
segn la naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas
a utilizarse, y los controles y entregas que se requieren.
Raccoon [RAC95] sugiere un << modelo del caos >> que describa el << desarrollo
del software como una extensin desde le usuario hasta el desarrollador y la
tecnologa >>. Conforme progresa el trabajo hacia un sistema completo, las
etapas descritas anteriormente se aplican recursivamente a las necesidades, del
usuario y a la especificacin tcnica del desarrollador del software.
Modelo Lineal Secuencial o Cascada Pura (Waterfall)
Por supuesto Royce en 1970; es el paradigma ms antiguo y fue el ms utilizado
durante la hegemona del mtodo estructurado. El nmero de etapas propuestas
vara de acuerdo al proyecto a desarrollar, aunque existen etapas comunes para
este paradigma.
Anlisis de los requisitos del software. El proceso de reunin de requisitos se
intensifica y se centra especialmente en el software. Para comprender la
naturaleza de el (los) programa (s) a construirse, el ingeniero (<< analista >>) del
software debe comprender el dominio de informacin del software (descrito en el
Capitulo 1.1), as como la funcin requerida, comportamiento, rendimiento e
interconexin. El cliente documenta y repasa los requisitos del sistema y del
software.
Diseo. El diseo del software es real mente un proceso de muchos pasos que se
centra en cuatro atributos de un programa: estructura de datos, arquitectura del
software, representaciones de interfaz y detalle procedimental (algoritmo). El
proceso de diseo traduce requisitos en una representacin del software que se
pueda evaluar por calidad antes de que comience la generacin del cdigo. Al
igual que los requisitos, el diseo se documenta y se hace parte de la
configuracin del software.
Generacin de cdigo. El diseo se debe traducir en una forma legible por la
mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si lleva a cabo
el diseo de una forma detallada, la generacin de cdigo se realiza
mecnicamente.

Pruebas. Una vez que se ha generado un cdigo, comienzan las pruebas del
programa. El proceso de pruebas se centra en los procesos lgico internos del
software, asegurando que todas las sentencias se han comprobado, yen los
proceso externos funcionales, es decir, la realizacin de las pruebas para le
deteccin de errores y el sentirse seguro de que la entrada definida produzca
resultados reales de acuerdo con los resultados requeridos.
Mantenimiento. El software indudablemente sufrir cambios despus de ser
entregado al cliente (una excepcin posible es el software empotrado). Se
producirn cambios porque se han encontrado errores, porque el software debe
adaptarse para acoplarse a los cambios de su entorno externo (p. Ej.: se requiere
un cambio debido a un sistema operativo o dispositivo perifrico nuevo), o porque
el cliente requiere mejoras funcionales o de rendimiento. El mantenimiento vuelve
a aplicar cada una de las fases precedentes a un programa ya existente y no a
uno nuevo.
Este paradigma concibe las fases de desarrollo como proceso independientes en
el tiempo, es decir, no se pueden realizar de manera simultnea; cada fase
empieza cuando se ha terminado la fase anterior y para poder pasar a otra fase es
necesario haber conseguido todos lo objetivos de la etapa previa.
Las etapas de este paradigma se desarrollan en forma secuencial y cuando se
detecta algn error en alguna etapa, lo ms probable ser abandonar todo lo
avanzado y regresar a la etapa primera de anlisis de requisitos del sistema; pues,
aunque la vuelta atrs por etapas es posible, sta demanda mucho esfuerzo y
puede terminar en el colapso.
El paradigma de cascada puro presenta las siguientes ventajas y desventajas.

Ventajas

Desventajas

Permite un mejor control de cada

actividad, en cuanto a fechas de
entrega,
costos,
revisiones
y
productos desarrollados.
Minimiza los gastos
planificacin del proyecto.

de

la

Los proyectos de software rar vez siguen un flujo secuencial.

No involucra al usuario en el desarrollo del producto.
Requiere mucho tiempo para el desarrollo del proyecto.
Si el usuario olvida especificar un requerimiento se incurre
un elevado costo.

La aplicacin de este paradigma es recomendada para proyectos donde cada

etapa sea independiente de la siguiente, para proyectos donde los requerimientos
de informacin se puedan determinar de manera clara y exacta, y stos no sean
modificados conforme pase el tiempo, para proyectos donde nos enfrentemos a
clientes pacientes, pues el software no estar disponible hasta el final del ciclo,

para proyectos donde se cuente con herramientas de calidad para el

levantamiento acertado de informacin.
Modelos en Funcin de Prototipos
Cuando en la etapa de anlisis se necesitan de tcnicas amigables para la
elaboracin del ERS, es recomendable el empleo de herramientas de
levantamiento de informacin como son los prototipos o modelos previos. Los
modelos previos pueden ser en papel o computadora para mostrar la interaccin
hombre-mquina; un modelo que muestra algunas funciones del software; o, algn
software anterior (parte o todo) parecido al que se desea, que luego ser
modificado y adaptado segn los requerimientos del usuario.
El paradigma de construccin de prototipos comienza con la recoleccin de
requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales
para el software, identifican los requisitos conocidos, y las reas del esquema en
donde es obligatoria ms definicin. Entonces aparece un << diseo rpido >>.
El diseo rpido se centra en una representacin de esos aspectos del software
que sern visibles para el usuario/cliente (p. Ej.: enfoques de entrada y formatos
de salida). El diseo rpido lleva a la construccin de un prototipo. El prototipo lo
evala el cliente/usuario y lo utiliza para refinar los requisitos del software a
desarrollar. La interaccin ocurre cuando el prototipo satsface las necesidades del
cliente, a la vez que permite que el desarrollador comprenda mejor lo que se
necesita hacer.
Lo ideal sera que el prototipo sirviera como un mecanismo para identificar los
requisitos del software. Si se construye un prototipo de trabajo, el desarrollador
intenta hacer uso de los fragmentos del programa ya existentes o aplica
herramientas (p. Ej.: generadores de informes, gestores de ventanas, etc.) que
permiten generar rpidamente programas de trabajo.
El paradigma de la elaboracin por prototipos resulta una alternativa para el
desarrollo rpido de aplicaciones de software; pues el analista acorta en tiempo
entre la determinacin de los requerimientos de informacin y la entrega de un
sistema funcional, adems que el usuario podr modificar y depurar sus
requerimientos conforme avance el desarrollo del proyecto.

El paradigma de desarrollo por prototipos presenta las siguientes ventajas y

desventajas.

Ventajas

Desventajas

El
desarrollador
debe
dar
forma
Permite la retroalimentacin por parte del usuario. prematuramente a un sistema, incluso antes
de comprender de manera bsica el problema
y su funcionamiento.
Desarrollo rpido.
El usuario se siente parte del grupo.

El usuario puede creer que un prototipo es

un software final.

El paradigma de prototipos es aplicable a proyectos de anlisis acelerado, donde

slo se cuente con requisitos generales; a proyectos con clientes impacientes de
ver algo funcionando; a proyectos con clientes dispuestos a reaccionar
abiertamente con el prototipo. No es recomendable aplicarlo a proyectos con
clientes exigentes de calidad, pues los prototipos son susceptibles a muchos
fallos, y el cliente se puede formar una idea equivocada de la seriedad del
desarrollador.
Modelo de Desarrollo rpido de Aplicacin (DRA)
Este es un modelo de proceso de desarrollo del software lineal, secuencias que
enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una
adaptacin a << alta velocidad >> del modelo lineal secuencial en el que se logra
el desarrollo rpido utilizando un enfoque de construccin basado en
componentes. Si se comprenden bien los requisitos y se limita el mbito del
proyecto, el proceso DRA permite al equipo de desarrollo crear un << sistema
completamente funcional >> dentro de periodos cortos de tiempo (p. Ej.: de 60 a
90 das) [MAR9]. Cuando se utiliza principalmente para aplicaciones de sistemas
de informacin, el enfoque DRA comprende las siguientes fases:
Modelado de Gestin. El flujo de informacin entre las funciones de gestin se
modela de forma que responda a las siguientes preguntas: Qu informacin
conduce el proceso de gestin?, Qu informacin se genera?, Quin la
genera?, A dnde va la informacin?, Quin la procesa?.
Modelado de Datos. El flujo de informacin definido como parte de la fase de
modelado de gestin se refina como un conjunto de objetos de datos necesarios
para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
Modelado de Proceso. Los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de informacin necesario para

implementar una funcin de gestin. Las descripciones del proceso se crean para
aadir, modificar, suprimir o recuperar un objeto de datos.
Generacin de Aplicaciones. El DRA asume la utilizacin de tcnicas de cuarta
generacin. En lugar de crear software con lenguajes de programacin de tercera
generacin, el proceso DRA trabaja para volver a utilizar componentes de
programas ya existentes (cuando es posible) o a crear componentes reutilizables
(cuando sea necesario). En todos los casos se utilizan herramientas automticas
para facilitar la construccin del software.
Pruebas y Entrega. Como el proceso DRA enfatiza la reutilizacin, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo
de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
El modelo de proceso DRA se ilustra en la Figura 2.6. Obviamente las limitaciones
de tiempo impuestas en un proyecto DRA demandan <<mbito en escalas>>
[KER94]. Si una aplicacin de gestin puede modularse de forma que permita
completarse cada una de las funciones principales en menos de tres meses
(utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una
de las funciones pueden ser afrontadas por un equipo DRA diferente y ser
integradas en un solo conjunto.
Desventajas:
Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos
suficientes como para crear el nmero correcto de equipos DRA.
DRA requiere clientes y desarrolladores comprometidos en las rpidas
actividades necesarias para complementar un sistema en un marco de tiempo
abreviado. Si o hay compromiso, por ninguna de las partes constituyentes, los
proyectos DRA fracasarn.

No todos los tipos de aplicaciones son apropiados para DRA. No es adecuado

cuando los riesgos tcnicos son altos. Esto ocurre cuando una nueva aplicacin
hace uso de tecnologas nuevas, o cuando el nuevo software requiere un alto
grado de interoperatividad con programas de computadora ya existentes. DRA
enfatiza el desarrollo de componentes de programas reutilizables.
Modelos de Procesos Evolutivos de Software
Modelo Incremental
Definido por Lehman en 1984; constituye una de las variantes del modelo en
cascada puro; el modelo incremental o de cascada con subproyectos, corrige la
necesidad de una secuencia no lineal de pasos de desarrollo.
El modelo Incremental se va creando el Software aadiendo componentes
funcionales al sistema: incrementos.
Los sistemas presentan alguna reas que incluyen sorpresas al momento de
definir o desarrollar el producto, pero tambin presentan otras reas que hemos
implementado varias veces y no incluyen sorpresas, entonces, por qu retrasar la
implementacin de estas reas que son fciles de modelar solamente porque
estamos considerando que en el proyecto existen algunas reas difciles.
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un
producto esencial (ncleo). Es decir, se afrontan requisitos bsicos, pero muchas

funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El

cliente utiliza el producto central (o sufre la revisin detallada). Como un resultado
de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente.
Este proceso se repite siguiendo la entrega de cada incremento, hasta que se
elabore el producto completo. En este paradigma el software se ve como una
integracin de resultados sucesivos obtenidos despus de cada interaccin. Este
modelo se adecua a entornos de alta incertidumbre.
Ventaja: Para desarrollos donde no se determinen de forma clara los
requerimientos de usuario al comenzar el sistema.
Desventaja: El problema de este modelo radica en que los errores en los
requisitos propuestos se detectan tarde y su correccin resulta tan costosa como
en el modelo en cascada.
Modelo en Espiral
Propuesto por Boehm en 1988 con la finalidad de paliar los inconvenientes del
modelo en cascad y adecuar el desarrollo por prototipos a problemas complejos.
Este paradigma combina el paradigma de cascada y el de construccin por
prototipos, agregando una etapa de "anlisis de riesgo" . El paradigma de espiral
es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software
en mini-proyectos y donde cada mini-proyecto se centra en uno o ms riesgos
importantes hasta que todos estos estn controlados. Este modelo se realiza en
varias iteraciones; se parte de una escala pequea la cual comienza con la
identificacin de objetivos, alternativas y restricciones; en medio de la espiral, se
localizan riesgos, se genera un plan para manejarlos, y a continuacin se
establece una aproximacin a la siguiente iteracin.
Se proporciona el potencial para el desarrollo rpido de versiones incremntales
del software. En el modelo espiral, el software se desarrolla en una serie de
versiones incremntales. Durante las primeras iteraciones, la versin incrementar
podra ser un modelo en papel prototipo. Durante las ltimas iteraciones, se
producen versiones cada vez ms completas de ingeniera del sistema. El modelo
en espiral se divide en un nmero de actividades estructurales tambin llamadas
guiones de tareas. Estas inclusive pueden variar de 3 a 6 tareas.
Cuando empieza este proceso evolutivo, el equipo de ingeniera del software gira
alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el
centro. El primer circuito de la espiral produce el desarrollo de una especificacin
de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar
un prototipo y progresivamente versiones ms sofisticadas del software. Cada
paso de la regin de planificacin produce ajustes en el plan del proyecto. El costo
y la planificacin se ajustan segn la reaccin ante la evaluacin del cliente.
Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones
requeridas para completar el software.

En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativo

hasta que el software de se retira. Hay veces en que el proceso est inactivo, pero
siempre que se inicie un cambio, el proceso arranca en el punto de entrada
adecuado (p. Ej.: mejora el producto). El modelo en espiral es un enfoque realista
del desarrollo de sistemas y de software a gran escala. Como el software
evoluciona, a medida que progresa el proceso, el desarrollador y el cliente
comprenden y reaccionan mejor ante riesgos en cada uno de los niveles
evolutivos. El modelo en espiral utiliza la construccin de prototipos como
mecanismos de reduccin de riesgos, pero lo que es ms importante, permite a
quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier
etapa de evolucin del producto. Mantiene el enfoque sistemtico de los pasos
sugeridos por el ciclo de vida clsico, pero lo incorpora al marco de trabajo
interactivo que refleja de forma ms realista el mundo real. El modelo en espiral
demanda una consideracin directa de los riesgos tcnicos en todas las etapas del
proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se
conviertan en problemticos.
El paradigma espiral, al igual que los dems modelos, se puede combinar con
otros paradigmas.
El paradigma de espiral presenta las siguientes ventajas y desventajas.

Ventajas
Mientras los costos del modelo
aumentan, los riesgos de proyecto
disminuyen.

Desventajas
Es un modelo complicado.

Exige desarrolladores con mucha experiencia para

Buen control sobre el desarrollo del manejar la complejidad de los problemas que enfrenta.
proyecto.

El modelo espiral es aplicable a proyectos donde no se trabaje bajo contrato, es

decir, proyectos que no involucren fuentes externas de software.
Este paradigma es poco recomendable para grupos de trabajo donde no se cuenta
con un equipo experto en anlisis de riesgos, o para proyectos donde los riesgos
sean menores y no se justifique la flexibilidad y gestin de riesgos que ofrece este
paradigma.
El paradigma ms adecuado para este caso es el espiral, debido a la complejidad
y el riesgo elevado del proyecto (de fallar la aplicacin se perderan vidas
humanas) a desarrollar.

Modelo de Ensamblaje de Componentes

Las tecnologas de objetos proporcionan el marco de trabajo tcnico para un
modelo de proceso basado en componentes para la ingeniera del software. El
paradigma de orientacin a objetos enfatiza la creacin de clases que encapsula
tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se
disean y se implementan adecuadamente, las clases orientadas a objetos son
reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados
en computadora.
El modelo ensamblador de componentes configura aplicaciones desde
componentes preparados de software (algunas veces llamados << clases >>). La
actividad de la ingeniera comienza con la identificacin de clases candidatas. Esto
se lleva a cabo examinando los datos que se van a manejar por parte de la
aplicacin y el algoritmo que se va a aplicar para conseguir el tratamiento. Los
datos y los algoritmos correspondientes se empaquetan en una clase.
El modelo de ensamblaje de componentes incorpora muchas de las caractersticas
del modelo en espiral. Es evolutivo por naturaleza [NIE92], y exige un enfoque
interactivo para la creacin del software. Sin embargo, el modelo ensamblador de
componentes configura aplicaciones desde componentes preparados de software
(algunas veces llamados << clases >>).
El modelo ensamblador de componentes lleva a la reutilizacin del software, y la
reutilizacin proporciona beneficios a los ingenieros del software.
Modelo de Desarrollo Concurrente
Definido por Davis y Sitaram [DAV94], el modelo de proceso concurrente se puede
representar en forma de esquema como una serie de actividades tcnicas
importantes, tareas, y estados asociados a ellas. Por ejemplo, la actividad de
ingeniera definida para el modelo en espiral, se lleva a cabo invocando las tareas
siguientes: modelado de construccin de prototipos y/o anlisis, especificacin de
requisitos, y diseo.
El modelo de proceso concurrente define una serie de acontecimientos que
disparan transiciones de estado a estado para cada una de las actividades de la
ingeniera del software.
El modelo de proceso concurrente se utiliza a menudo como el paradigma de
desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se
compone de un conjunto de componentes funcionales. Cuando se aplica a
cliente/servidor, el modelo de proceso concurrente define actividades en dos
dimensiones [SHE94]: una dimensin de sistemas y una dimensin de
componentes. Los aspectos del nivel de sistemas se afrontan mediante tres
actividades: diseo, ensamblaje y uso. La dimensin de componentes se afronta
con dos: diseo y realizacin. La concurrencia se logra de dos formas:

1. Las actividades de sistemas y de componentes ocurren simultneamente y

pueden moderarse con el enfoque orientado a objetos descrito
anteriormente.

2. Una aplicacin cliente/servidor tpica se implementa con muchos

componentes, cada uno de los cuales se pueden disear y realizar
concurrentemente.

En realidad, el modelo de proceso concurrente es aplicable a todo tipo de

desarrollo de software y proporciona una imagen exacta del estado actual de un
proyecto. En vez de confinar las actividades de ingeniera del software a una
secuencia de sucesos, define una red de actividades. Todas las actividades de la
red existen simultneamente con otras. Los sucesos generados dentro de una
actividad dada o en algn otro lugar en la red de actividad inicia la s transiciones
entre los estados de una actividad.
Modelo de Mtodos Formales
El modelo de mtodos formales acompaa a un conjunto de actividades que
conducen a la especificacin matemtica del software de computadora. Los
mtodos formales permiten que un ingeniero del software especifique, desarrolle y
verifique un sistema basado en computadora aplicando una notacin rigurosa y
matemtica.
La ambigedad, lo incompleto y la inconsistencia se descubren y se corrigen ms
fcilmente, no mediante una revisin a propsito para el caso, sino mediante la
aplicacin del anlisis matemtico. Cuando se utilizan mtodos formales durante
el diseo, sirven como base para la verificacin de programas y por consiguiente
permiten que el ingeniero del software descubra y corrija errores que no se
pudieron detectar de otra manera.
Aunque todava no hay un enfoque establecido, los modelos de mtodos formales
ofrecen la promesa de un software libre de defectos. Sin embargo, se ha hablado
de una gran preocupacin sobre su aplicabilidad en un entorno de gestin:
1. El desarrollo de modelos formales actualmente es bastante caro y lleva
mucho tiempo.

2. Se requiere un estudio caro porque pocos responsables del desarrollo de

software tiene los antecedentes necesarios para aplicar mtodos formales.

3. Es difcil utilizar los modelos como un mecanismo de comunicacin con

clientes que no tiene muchos conocimientos tcnicos.

No obstante, es posible que el enfoque a travs de mtodos formales tenga ms

partidarios entre los desarrolladores del software que deben construir software de
mucha seguridad (p. Ej.: los desarrolladores de avinica y dispositivos mdicos), y
entre los desarrolladores que pasan grandes penurias econmicas al aparecer
errores de software.
Tcnicas de Cuarta Generacin
Abarca un amplio espectro de herramientas de software que tienen algo en
comn: todas facilitan al ingeniero del software, la especificacin de lagunas
caractersticas del software de alto nivel. Luego, la herramienta genera
automticamente el cdigo fuente basndose en la especificacin del tcnico.
Cada vez parece ms evidente que en cuanto mayor sea el nivel en el que se
especifique el software, ms rpido se podr construir el programa. El paradigma
T4G para la ingeniera del software usando formas de lenguaje especializado o
notaciones graficas que describan el problema que hay que resolver en trminos
que los entienda el cliente.
Al igual que otros paradigmas, T4G comienza con el paso de reunin de
requisitos. Idealmente, el cliente describe los requisitos, que son, a continuacin,
traducidos directamente a un prototipo operativo. Estado actual de los enfoques de
T4G:
1. El uso de T4G ha crecido considerablemente en la ltima dcada y ahora
es un enfoque viable para muchas de las diferentes reas de aplicacin.
Junto con las herramientas de ingeniera de software asistida por
computadora (CASE) y los generadores de cdigo, T4G ofrece una solucin
fiable a muchos problemas de software.

2. Los datos recogidos en compaas que usan T4G parecen indicar que el
tiempo requerido para producir software se reduce mucho para aplicaciones
pequeas y de tamao medio, y que la cantidad de anlisis y diseo para
las aplicaciones pequeas, tambin se reduce.

3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de

software exige el mismo o ms tiempo de anlisis, diseo y prueba
(actividades de ingeniera del software), perdindose as un tiempo
sustancial que se ahorra mediante la eliminacin de la codificacin.

Tecnologa de Procesos
Las herramientas de tecnologa de procesos permiten que una organizacin de
software construya un modelo automatizado de la estructura comn del proceso,
conjunto de tareas, y actividades de proteccin.
El modelo, presentado normalmente como una red, se puede analizar para
determinar el flujo de trabajo tpico y para examinar estructuras alternativas de
procesos que pudieran llevar a un tiempo o costo de desarrollo reducidos. Una vez
que se ha creado un proceso aceptable, se pueden utilizar otras herramientas de
tecnologa de procesos para asignar, supervisar, e incluso controlar todas las
tareas de ingeniera del software definidas como parte del modelo de proceso.
Cada uno de los miembros de un equipo de proyecto de software pueden utilizar
tales herramientas para desarrollar una lista de control de tareas de trabajo a
realizarse productos de trabajo a producirse, y actividades de garanta de calidad
a conducirse.
Criterios Generales para Seleccionar un Paradigma:
El ingeniero de sistemas debe estar en capacidad de seleccionar de manera
correcta la utilizacin de alguno de los paradigmas anteriormente mencionados o
una combinacin de ellos, evaluando las principales caractersticas del problema
al cual se enfrentar.
Estas caractersticas se deben captar en la fase de anlisis general del sistema y
debern reforzarse en la etapa de anlisis detallado del sistema. Como puntos de
evaluacin para la seleccin del paradigma adecuado tenemos:
La naturaleza del proyecto, donde se agrupan criterios como la complejidad del
producto final, el conocimiento de la aplicacin por parte del grupo, la utilizacin
final del software, etc..
El control del proyecto y la importancia de los avances, directamente
relacionado con las caractersticas del cliente, sus perspectivas y deseos respecto
al software, la importancia de su inclusin en el grupo de desarrollo del producto,
etc..
Los mtodos y las herramientas disponibles para el desarrollo de cada una de
las fases a realizar.