INGENIERIA EN SISTEMAS COMPUTACIONALES

FUNDAMENTOS DE INGENIERA DE SOFTWARE

INVESTIGACION: UNIDAD 1: FUNDAMENTOS DE INGENIERA DE

SOFTWARE

NOMBRE DEL PROFESOR(A):

JOSUE BENJAMIN POOT PEA

ALUMNO:
MUCUL BEYTIA ELEAB EFREN

VS-5
ndice

Introduccin .............................................................................................................................. 3
Unidad 1.- Fundamentos de Ingeniera de Software ................................................................ 4
1.1 Conceptos bsicos .......................................................................................................... 4
1.2 Fases de la Ingeniera de Software ................................................................................. 5
1.3 Metodologas del desarrollo de software ......................................................................... 8
1.3.1 Clsica ...................................................................................................................... 9
1.3.2 Agiles ...................................................................................................................... 15
1.3.3 Otras filosofas ........................................................................................................... 21
1.4 Importancia de las herramientas CASE en la Ingeniera de software ........................... 21
Tipos de case .................................................................................................................. 22
Beneficios de las herramientas case ............................................................................... 25
Opciones de integracion .................................................................................................. 29
Componentes y funcionalidades de una herramienta case ............................................. 31
Conceptos de la orientacin a objetos ............................................................................. 34
Conclusin .............................................................................................................................. 36
Referencias Bibliogrficas ...................................................................................................... 37
 Introduccin
Desde el nacimiento del hombre como sociedad las organizaciones han tenido la necesidad
de ser cada vez ms competitivas para la obtencin de mayores recursos, en la actualidad
esto es lo que ha permitido el crecimiento econmico de las naciones su desarrollo. La
administracin de dichas organizaciones ha requerido de nuevas formas de trabajo para
generar productos y servicios de calidad. Un factor importante es el uso de las tecnologas de
la informacin (TI), las cuales ha permitido generar una ventaja competitiva sobre
organizaciones del propio giro. Esta ventaja se puede generar a travs de una planeacin
estratgica la cual busca que las tecnologas de la informacin vayan alineadas con los
objetivos y metas de la organizacin. Las tecnologas de la informacin permiten el
almacenamiento, anlisis y la generacin de la toma de decisiones con base de la informacin
obtenida de sus clientes, proveedores, competidores y su entorno. Esta sistematizacin de la
informacin se genera a travs de un elemento de las TI como lo es el software, el cual es la
parte lgica de una computadora y que ha sufrido en las ltimas tres dcadas una problemtica
la cual ha generado el no poder cumplir de manera adecuada con los objetivos y necesidades
que las organizaciones (clientes) requieren. Estas deficiencias han ido disminuyendo a travs
de los aos con el uso de metodologas y su control ha sido mejor con la administracin de
proyectos.
Es imposible operar el mundo moderno sin software. Las infraestructuras nacionales y los
servicios pblicos se controlan mediante sistemas basados en computadoras, y la mayora de
los productos elctricos incluyen una computadora y un software de control. La fabricacin y
la distribucin industrial estn completamente computarizadas, como el sistema financiero. El
entretenimiento, incluida la industria musical, los juegos por computadora, el cine y la
televisin, usan software de manera intensiva. Por lo tanto, l ingeniera de software es esencial
para el funcionamiento de las sociedades, tanto a nivel nacional como internacional.
Los sistemas de software son abstractos e intangibles. No estn restringidos por las
propiedades de los materiales, regidos por leyes fsicas ni por procesos de fabricacin. Esto
simplifica la ingeniera de software, pues no existen lmites naturales a su potencial. Sin
embargo, debido a la falta de restricciones fsicas, los sistemas de software pueden volverse
rpidamente muy complejos, difciles de entender y costosos de cambiar.
Cuando el software de computadora triunfa (al satisfacer las necesidades de las personas que
lo usan, trabajar sin fallos durante largos periodos, ser fcil de modificar e incluso ms fcil
de usar) puede y debe cambiar las cosas a fin de mejorar. Pero cuando el software fracasa
(cuando sus usuarios no estn satisfechos, es proclive al error, es difcil de cambiar e incluso
ms difcil de usar) pueden ocurrir, y ocurren, cosas malas.
 Unidad 1.- Fundamentos de Ingeniera de Software
1.1 Conceptos bsicos
El software es el conjunto de programas de cmputo, documentos asociados y esquemas de
configuracin necesarios para que estos programas operen. [Sommerville, 2001]
Pressman dice que el software de computadora es el producto que construyen los
programadores profesionales y al que despus le dan mantenimiento durante un largo tiempo.
Incluye programas que se ejecutan en una computadora de cualquier tamao y arquitectura,
contenido que se presenta a medida que se ejecutan los programas de cmputo e informacin
descriptiva tanto en una copia dura como en formatos virtuales que engloban virtualmente a
cualesquiera medios electrnicos. La ingeniera de software est formada por un proceso, un
conjunto de mtodos (prcticas) y un arreglo de herramientas que permite a los profesionales
elaborar software de cmputo de alta calidad.
El software distribuye el producto ms importante de nuestro tiempo: informacin. Transforma
los datos personales (por ejemplo, las transacciones financieras de un individuo) de modo que
puedan ser ms tiles en un contexto local, administra la informacin de negocios para mejorar
la competitividad, provee una va para las redes mundiales de informacin (la internet) y brinda
los medios para obtener informacin en todas sus formas.
En el ltimo medio siglo, el papel del software de cmputo ha sufrido un cambio significativo.
Las notables mejoras en el funcionamiento del hardware, los profundos cambios en las
arquitecturas de computadora, el gran incremento en la memoria y capacidad de
almacenamiento, y una amplia variedad de opciones de entradas y salidas exticas han
propiciado la existencia de sistemas basados en computadora ms sofisticados y complejos.
Cuando un sistema tiene xito, la sofisticacin y complejidad producen resultados
deslumbrantes, pero tambin plantean problemas enormes para aquellos que deben construir
sistemas complejos.
Diversos problemas que se presentaban en la vida cotidiana en aquel entonces llevo al
desarrollo de una nueva materia o disciplina, que es la ingeniera de software.
El concepto ingeniera de software se propuso originalmente en 1968, en una conferencia
realizada para discutir lo que entonces se llamaba la crisis del software (Naur y Randell,
1969). Se volvi claro que los enfoques individuales al desarrollo de programas no escalaban
hacia los grandes y complejos sistemas de software. stos no eran confiables, costaban ms
de lo esperado y se distribuan con demora.
Aunque existen muchas otras definiciones de lo que es la ingeniera de software, ya que cada
uno de ellos la ve de una manera distinta, aunque en algunos puntos concuerdan en si.
Segn Zelkovitz, define la Ingeniera de Software como el estudio de los principios y
metodologas para desarrollo y mantenimiento de sistemas de software.
En cambio Bohem, la define como la aplicacin prctica del conocimiento cientfico en el diseo
y construccin de programas de computadora y la documentacin asociada requerida para
desarrollar, operar y mantenerlos. Se conoce tambin como desarrollo de software o
produccin de software.
La ingeniera de software busca apoyar el desarrollo de software profesional, en lugar de la
programacin individual. Incluye tcnicas que apoyan la especificacin, el diseo y la evolucin
del programa, ninguno de los cuales son normalmente relevantes para el desarrollo de
software personal.
Esta disciplina trasciende la actividad de programacin, que es la actividad principal a la hora
de crear un software. El ingeniero de software se encarga de toda la gestin del proyecto para
que ste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.
La ingeniera de software, por lo tanto, incluye el anlisis previo de la situacin, el diseo del
proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementacin del sistema.
Los Ingenieros de Software deben:
Adoptar un enfoque sistemtico para llevar a cabo su trabajo.
Utilizar las herramientas y tcnicas apropiadas para resolver el problema planteado,
de acuerdo a las restricciones de desarrollo y a los recursos disponibles.
1.2 Fases de la Ingeniera de Software
Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a
crearse algn producto del trabajo. Una actividad busca lograr un objetivo amplio (por ejemplo,
comunicacin con los participantes) y se desarrolla sin importar el dominio de la aplicacin,
tamao del proyecto, complejidad del esfuerzo o grado de rigor con el que se usar la
ingeniera de software. Una accin (diseo de la arquitectura) es un conjunto de tareas que
producen un producto importante del trabajo (por ejemplo, un modelo del diseo de la
arquitectura). Una tarea se centra en un objetivo pequeo, pero bien definido (por ejemplo,
realizar una prueba unitaria) que produce un resultado tangible.
En el contexto de la ingeniera de software, un proceso no es una prescripcin rgida de cmo
elaborar software de cmputo. Por el contrario, es un enfoque adaptable que permite que las
personas que hacen el trabajo (el equipo de software) busquen y elijan el conjunto apropiado
de acciones y tareas para el trabajo. Se busca siempre entregar el software en forma oportuna
y con calidad suficiente para satisfacer a quienes patrocinaron su creacin y a aquellos que lo
usarn.
La estructura del proceso establece el fundamento para el proceso completo de la ingeniera
de software por medio de la identificacin de un nmero pequeo de actividades estructurales
que sean aplicables a todos los proyectos de software, sin importar su tamao o complejidad.
Adems, la estructura del proceso incluye un conjunto de actividades sombrilla que son
aplicables a travs de todo el proceso del software. Una estructura de proceso general para la
ingeniera de software consta de cinco actividades:
 Comunicacin: Antes de que comience cualquier trabajo tcnico, tiene importancia
crtica comunicarse y colaborar con el cliente (y con otros participantes).11 Se busca
entender los objetivos de los participantes respecto del proyecto, y reunir los
requerimientos que ayuden a definir las caractersticas y funciones del software.
Planeacin: Cualquier viaje complicado se simplifica si existe un mapa. Un proyecto de
software es un viaje difcil, y la actividad de planeacin crea un mapa que gua al
equipo mientras viaja. El mapa llamado plan del proyecto de software define el
trabajo de ingeniera de software al describir las tareas tcnicas por realizar, los riesgos
probables, los recursos que se requieren, los productos del trabajo que se obtendrn y
una programacin de las actividades.
Modelado: Ya sea usted diseador de paisaje, constructor de puentes, ingeniero
aeronutico, carpintero o arquitecto, a diario trabaja con modelos. Crea un bosquejo
del objeto por hacer a fin de entender el panorama general cmo se ver
arquitectnicamente, cmo ajustan entre s las partes constituyentes y muchas
caractersticas ms. Si se requiere, refina el bosquejo con ms y ms detalles en un
esfuerzo por comprender mejor el problema y cmo resolverlo. Un ingeniero de software
hace lo mismo al crear modelos a fin de entender mejor los requerimientos del software
y el diseo que los satisfar.
Construccin. Esta actividad combina la generacin de cdigo (ya sea manual o
automatizada) y las pruebas que se requieren para descubrir errores en ste.
Despliegue. El software (como entidad completa o como un incremento parcialmente
terminado) se entrega al consumidor que lo evala y que le da retroalimentacin, misma
que se basa en dicha evaluacin.
Estas cinco actividades estructurales genricas se usan durante el desarrollo de programas
pequeos y sencillos, en la creacin de aplicaciones web grandes y en la ingeniera de
sistemas enormes y complejos basados en computadoras. Los detalles del proceso de
software sern distintos en cada caso, pero las actividades estructurales son las mismas.
Para muchos proyectos de software, las actividades estructurales se aplican en forma iterativa
a medida que avanza el proyecto. Es decir, la comunicacin, la planeacin, el modelado, la
construccin y el despliegue se ejecutan a travs de cierto nmero de repeticiones del
proyecto. Cada iteracin produce un incremento del software que da a los participantes un
subconjunto de caractersticas y funcionalidad generales del software. Conforme se produce
cada incremento, el software se hace ms y ms completo. Las actividades estructurales del
proceso de ingeniera de software son complementadas por cierto nmero de actividades
sombrilla. En general, las actividades sombrilla se aplican a lo largo de un proyecto de software
y ayudan al equipo que lo lleva a cabo a administrar y controlar el avance, la calidad, el cambio
y el riesgo.
Es comn que las actividades sombrilla sean las siguientes:
Seguimiento y control del proyecto de software: permite que el equipo de software evale el
progreso comparndolo con el plan del proyecto y tome cualquier accin necesaria para
apegarse a la programacin de actividades.
Administracin del riesgo: evala los riesgos que puedan afectar el resultado del proyecto o la
calidad del producto. Aseguramiento de la calidad del software: define y ejecuta las actividades
requeridas para garantizar la calidad del software.
Revisiones tcnicas: evala los productos del trabajo de la ingeniera de software a fin de
descubrir y eliminar errores antes de que se propaguen a la siguiente actividad.
Medicin: define y rene mediciones del proceso, proyecto y producto para ayudar al equipo a
entregar el software que satisfaga las necesidades de los participantes; puede usarse junto
con todas las dems actividades estructurales y sombrilla.
Administracin de la configuracin del software: administra los efectos del cambio a lo largo
del proceso del software.
Administracin de la reutilizacin: define criterios para volver a usar el producto del trabajo
(incluso los componentes del software) y establece mecanismos para obtener componentes
reutilizables.
Preparacin y produccin del producto del trabajo: agrupa las actividades requeridas para
crear productos del trabajo, tales como modelos, documentos, registros, formatos y listas.
Ya se dijo en esta seccin que el proceso de ingeniera de software no es una prescripcin
rgida que deba seguir en forma dogmtica el equipo que lo crea. Al contrario, debe ser gil y
adaptable (al problema, al proyecto, al equipo y a la cultura organizacional). Por tanto, un
proceso adoptado para un proyecto puede ser significativamente distinto de otro adoptado para
otro proyecto. Entre las diferencias se encuentran las siguientes:
Flujo general de las actividades, acciones y tareas, as como de las interdependencias entre
ellas
Grado en el que las acciones y tareas estn definidas dentro de cada actividad estructural
Grado en el que se identifican y requieren los productos del trabajo
Forma en la que se aplican las actividades de aseguramiento de la calidad
Manera en la que se realizan las actividades de seguimiento y control del proyecto
Grado general de detalle y rigor con el que se describe el proceso
Grado con el que el cliente y otros participantes se involucran con el proyecto
Nivel de autonoma que se da al equipo de software
Grado con el que son prescritos la organizacin y los roles del equipo
Los modelos de proceso prescriptivo enfatizan la definicin, la identificacin y la aplicacin
detalladas de las actividades y tareas del proceso. Su objetivo es mejorar la calidad del
sistema, desarrollar proyectos ms manejables, hacer ms predecibles las fechas de entrega
y los costos, y guiar a los equipos de ingenieros de software cuando realizan el trabajo que se
requiere para construir un sistema. Desafortunadamente, ha habido casos en los que estos
objetivos no se han logrado. Si los modelos prescriptivos se aplican en forma dogmtica y sin
adaptacin, pueden incrementar el nivel de burocracia asociada con el desarrollo de sistemas
basados en computadora y crear inadvertidamente dificultades para todos los participantes.
Los modelos de proceso gil ponen el nfasis en la agilidad del proyecto y siguen un conjunto
de principios que conducen a un enfoque ms informal (pero no menos efectivo, dicen sus
defensores) del proceso de software. Por lo general, se dice que estos modelos del proceso
son giles porque acentan la maniobrabilidad y la adaptabilidad. Son apropiados para
muchos tipos de proyectos y son tiles en particular cuando se hace ingeniera sobre
aplicaciones web.
1.3 Metodologas del desarrollo de software
Segn Silva (2001) desde 1985 hasta el presente, han ido apareciendo herramientas,
metodologas y tecnologas que se presentaban como la solucin definitiva al problema de la
planificacin, previsin de costos y aseguramiento de la calidad en el desarrollo de software.
La dificultad propia de los nuevos sistemas, y su impacto en las organizaciones, ponen de
manifiesto las ventajas, y en muchos casos la necesidad, de aplicar una metodologa formal
para llevar a cabo los proyectos de este tipo. La ingeniera de software es una tecnologa
multicapa en la que, segn Pressman (2005), se pueden identificar: los mtodos, el proceso
(que es el fundamento de la Ingeniera de Software, es la unin que mantiene juntas las capas
de la tecnologa) y las herramientas (soporte automtico o semiautomtico para el proceso y
los mtodos). Como disciplina, establece el proceso de definicin de requerimientos en una
sucesin de actividades mediante las cuales lo que debe hacerse, se modela y analiza
(Choque, 2001).
Una parte importante de la ingeniera de software es el desarrollo de metodologas y modelos.
En la actualidad ha habido muchos esfuerzos que se han encaminado al estudio de los
mtodos y tcnicas para lograr una aplicacin ms eficiente de las metodologas y lograr
sistemas ms eficientes y de mayor calidad con la documentacin necesaria en perfecto orden
y en el tiempo requerido. Gacita (2003), plantea que una metodologa impone un proceso de
forma disciplinada sobre el desarrollo de software con el objetivo de hacerlo ms predecible y
eficiente. Una metodologa define una representacin que permite facilitar la manipulacin de
modelos, y la comunicacin e intercambio de informacin entre todas las partes involucradas
en la construccin de un sistema.
Goncalves (2005) plantea que la experiencia ha demostrado que los proyectos exitosos son
aquellos que son administrados siguiendo una serie de procesos que permiten organizar y
luego controlar el proyecto, considerando vlido destacar que aquellos procesos que no sigan
estos lineamientos corren un alto riesgo de fracasar. Es necesario destacar la importancia de
los mtodos, pero el xito del proyecto depende ms de la comunicacin efectiva con los
interesados, el manejo de las expectativas y las personas que participan en el proyecto.
Metodologa de desarrollo de software: es un enfoque estructurado para el desarrollo de
software que incluye modelos de sistemas, notaciones, reglas, sugerencias de diseo y guas
de procesos.
Las metodologas han evolucionado de manera significativa en las ltimas dcadas,
permitiendo as el xito o el fracaso de muchos de los sistemas desarrollados para distintas
reas.
1.3.1 Clsica
Hay una serie de metodologas que solemos llamar tradicionales, propuestas casi todas ellas
con anterioridad a los aos 90 del siglo XX, y que pretendan ayudar a los profesionales
indicando pautas para realizar y documentar cada una de las tareas del desarrollo del software.
Sin embargo, tienen casi todas ellas un gran lastre: asumen que un proyecto informtico es
casi una extensin de un proyecto burocrtico tradicional. As pues, los pasos que sugieren
para llevar a cabo cada tarea, aunque bienintencionados, estn cargados de burocracia,
reiteraciones, ambigedades... No suelen tener en cuenta cosas como la calidad, la
satisfaccin, la competitividad, los beneficios. Fueron metodologas creadas en los aos 70-80
pensando en los negocios de los aos 50.
Metodologa en cascada: Framework lineal
El modelo de desarrollo de Software en cascada, es una metodologa de la programacin muy
antigua. Si bien su creador nunca lo menciona como metodologa en cascada, el
funcionamiento y lineamiento de los procesos de la planeacin, son exactamente iguales.
Bsicamente, el estilo del modelo en cascada, es que no podrs avanzar a la siguiente fase,
si la anterior no se encuentra totalmente terminada, pues no tiene porque haber vuelta atrs.
Vamos a ver cules son las fases de desarrollo de software del modelo en cascada, para que
te puedas dar una idea.
1. Anlisis de Requisitos. El primer nivel del modelo cascado, es el anlisis de requisitos.
Bsicamente lo que se documenta aqu, son los objetivos de lo que el software debe hacer al
terminar el desarrollo, sin entrar en detalles de la parte interna, los cuales se vern durante el
proceso. Sin embargo, es importante sealar que una vez avanzado el paso de anlisis, no
puede haber vuelta atrs, pues la metodologa para el diseo de software con la cual se trabaja
no lo permitir.
2. Diseo del Sistema. Todo lo que conlleva el armado de un diseo para el sistema que vayas
a utilizar, es lo que continua despus del anlisis de requisitos. Aqu se elaborar lo que es la
estructura del sistema y se determinarn las especificaciones para cada una de las partes del
sistema que se planea desarrollar. Siendo del mismo modo, una fase a la cul ya no se podr
volver despus de haber bajado al nivel 3.
3. Diseo del Programa. En este punto, an no ingresamos a lo que es la escritura de cdigo,
sin embargo, ya se realizan los algoritmos que se van a utilizar en la programacin. Si bien
recuerdas, un algoritmo no necesariamente es cdigo, simplemente tomas una hoja de papel
y escribes el algoritmo que vas a utilizar. Esto es precisamente lo que se realiza en el paso
nmero 3.
4. Codificacin. Seguramente como programador, esta es la parte que estabas esperando,
pues ahora es momento de empezar a escribir todo el cdigo que ser necesario para el
desarrollo del software. Para este punto, la velocidad y el tiempo que se requiera, depender
mucho del lenguaje de programacin que vayas a utilizar. Pues algunos lenguajes de
programacin permiten utilizar componente, bibliotecas e incluso algunas funciones para
reutilizar cdigo, las cuales podrn acelerar el proceso de codificacin en gran manera.
5. Ejecucin de Pruebas. La codificacin ha terminado y ahora es momento de verificar que
nuestro sistema es realmente funciona, antes de que el cliente empiece a utilizarlo. Este es
precisamente el objetivo de la fase 5 de pruebas. Aqu es recomendable que intentes mover lo
ms que se pueda tu software, con el objetivo de daarlo intencionalmente, de este modo, si
supera las pruebas de dao realizadas por t, entonces estar listo para el usuario final.
6. Verificacin. Despus de haber realizado una gran cantidad de pruebas en la Fase 5,
debemos migrar a la verificacin. Esta fase consiste en la ejecucin del Software por parte del
usuario final. Si la fase cinco se realiz correcta y profundamente, el software no tendr ningn
tipo de problema y el usuario final quedar satisfecho con el resultado.
. Mantenimiento. Seguramente te has dado cuenta, de que las aplicaciones o el software
actual, constantemente se est actualizando. Esto se debe principalmente a que se le da
mantenimiento al software, se solucionan errores, se quitan algunos bugs, se aaden
funcionalidades, todo despus de que el usuario final ya lo ha probado y utilizado en su fase
final. Esta es posiblemente una de las fases ms tediosas del modelo de desarrollo de
software, pues debes estar atento a los comentarios de los usuarios, para ver que cosas son
las que no funcionan correctamente y a las cuales hay que darles mantenimiento
Cules son los Principios bsicos del modelo de cascada?
Como puedes ver, el proceso de desarrollo de software con el modelo de cascada es bastante
complejo. Sin embargo, uno de sus principios es que cada una de las fases elaboradas, se
encuentre documentada perfectamente, de este modo, si el desarrollo queda suspendido en
alguna fase, cualquier usuario que quiera continuar con el proyecto lo podr hacer leyendo la
documentacin.
As tambin, es muy comn encontrar metodologas para el desarrollo de software en cascada
con fechas de objetivos, tiempos o presupuestos para determinadas fases. Aprovechando el
hecho de que una vez que avanzaste de fase, es muy poco recomendable el volver atrs,
aunque regularmente se tiene un cierto nivel de tolerancia, pero lo correcto en la utilizacin del
modelo de cascada, es que no puedas ir atrs a realizar modificaciones de ningn tipo.
Mtodo de Prototipos
Esta metodologa de la programacin todava sigue siendo la favorita de muchos. Consiste
bsicamente en que en base a los requerimientos y necesidades que tiene el cliente, se realiza
de forma rpida un prototipo, este no vendr completo ni mucho menos terminado, pero si
permitir contar con las bases necesarias para que cualquier programador pueda seguir
trabajando en el hasta llegar al cdigo final.
Por si no lo sabes an, un prototipo es una versin no terminada del producto que se le
entregar al cliente o usuario final. Esto nos genera cierta ventaja en el desarrollo de productos
similares con funciones distintas, por ejemplo. Supongamos que vas a desarrollar un proyecto
para 3 clientes distintos, ambos con una estructura idntica, pero con funcionalidades muy
distintas, entonces lo que hacemos es crear un prototipo base y entorno a el mostrarlo a
nuestros clientes para que de ah se empiecen a desarrollar las dems funciones.
Mejor vamos a ver cuales son las etapas de desarrollo de software por las cuales tendrs que
pasar, en caso de utilizar la metodologa de prototipos.
1. Planeacin. A diferencia de otras metodologas, la planeacin debe ser muy rpida, en esta
fase no puedes demorarte mucho, pues recuerda que solamente ser un prototipo por el
momento.
2. Modelado. Nuevamente, una fase que deber ser suficientemente rpida como para que
nos nos quite nada de tiempo. Hacer el modelado ser simple y te sigo recordando que
solamente es un prototipo, almenos por ahora.
3. Elaboracin del Prototipo. Ya que contamos con la planeacin de lo que vamos a realizar y
el modelado rpido, entonces es momento de elaborar el prototipo. Para esta instancia, ya no
te dir que lo debes hacer rpido, puesto que te tomar el tiempo que tenga sea necesario
elaborarlo, recuerda que este ya se muestra al cliente, as que ya es una fase importante.
4. Desarrollo. Posterior a contar con el prototipo elaborado y mostrado al cliente, es momento
de comenzar el desarrollo. Este te tomar una gran cantidad de tiempo, dependiendo del
tamao del proyecto y el lenguaje de programacin que se vaya a utilizar.
5. Entrega y Retroalimentacin. Una de las cosas con las que cuenta el modelo de prototipos,
es que una ves entregado el proyecto, debemos darle al cliente cierta retroalimentacin sobre
como utilizarlo y ciertamente es una fase que se encuentra dentro de las etapas de desarrollo
de software esta metodologa.
6. Comunicacin con el Cliente. Es importante que una ves entregado el proyecto, tengamos
cierta comunicacin con el cliente, bsicamente para que nos indique si el proyecto es correcto
o si desea agregarle ciertas funciones, nuestra metodologa lo permite. Si fuera en modo
cascada, entonces seria algo realmente imposible de hacer.
7. Entrega del Producto Final. Por ltimo, solamente quedar entregar el sistema elaborado
mediante esta metodologa. Aqu tendrs la ventaja de que el cdigo es reutilizable, para que
as con el prototipo ya puedas simplemente empezar de nuevo y con una buena base de cdigo
que te acelerar el proceso.
Cules son los Principios Bsicos del mtodo de prototipos?
Por supuesto, te habrs dado cuenta de que el modelo de prototipos puede llegar a ser un
poco ms tedioso, aunque todo depender del mbito en que lo utilices. Sin embargo uno de
sus principios bsicos que seguramente habrs notado, es que con el mtodo de prototipos el
proyecto se va dividiendo en partes cada ves mas pequeas, para evitar el peligro ante los
riesgos frente a los que estamos expuestos.
Adems, otros de sus principios bsicos fundamentales, es que con la metodologa de
prototipos, el cliente final se involucra mucho ms en el proyecto que con otras metodologas,
haciendo de esta forma que el producto final llegue rpidamente aunque con un poco ms de
presin en el proceso. La ventaja es que conforme se van haciendo prototipos pequeos, poco
a poco se va llegando al producto final. Incluso en algn determinado momento podrs llegar
a crear un prototipo que con solo ajustar ciertos detalles, se podra convertir en el producto
que el usuario quiere.
Modelo Incremental o Iterativo y Creciente
El modelo Incremental, es una metodologa de la programacin muy utilizada hoy en da, pues
su comodidad de desarrollo permite que te obtenga un producto final mucho ms completo y
exitoso. Se trata especialmente de la combinacin de los modelos lineal e iterativo o bien,
modelo de cascada y prototipos. Bsicamente consiste en completar varias iteraciones de lo
que es el modelo de cascada, pero sin completar ninguna, haciendo iteraciones lo que se hace
es crear una evolucin en el producto, permitiendo que se agreguen nuevas especificaciones,
funcionalidades, opciones, funciones y lo que el usuario requiera despus de cada iteracin.
En pocas palabras, el Modelo Incremental repite el modelo de cascada una y otra ves, pero
con pequeas modificaciones o actualizaciones que se le puedan ir agregando al sistema. De
este modo el usuario final se ve sumamente sumergido en el desarrollo y puedes
proporcionarle un resultado ptimo.
Fases del Modelo Incremental
El modelo iterativo o incremental, cuenta con algunas fases de desarrollo de software que
realmente no tienen mucha complejidad, vamos a verlas:
1. Inicializacin. como en todo modelo de desarrollo, debe haber una inicializacin, aqu se
puede hablar de dar una idea, de tener algunos requisitos que se buscan en el proyecto y
ciertas especificaciones que se pueden manejar. No es necesario que se haga una lista total
de requerimientos pues recordemos que el proyecto se basa en iteraciones, as que el proyecto
puede ir evolucionando poco a poco.
2. Periodos de Iteracin. Durante el desarrollo del proyecto, es cuando damos inicio a las
iteraciones. La primera iteracin se realiza con las caractersticas iniciales, bsicamente al final
de la primer iteracin, queda un pequeo prototipo de lo que ser el proyecto, pero se puede
volver a inicializar la iteracin y realizar modificaciones en los procesos, como el anlisis y las
especificaciones o funciones que el usuario final requiere para su sistema.El nmero de
iteraciones que se realicen son ilimitadas y depender tanto del desarrollador como del usuario
final. Si nuestro objetivo es que el cliente o la persona que necesita el trabajo quede
completamente satisfecha, entonces nos veremos en la necesidad de hacer la cantidad de
iteraciones que se requieran al final del da.
3. Lista de Control. Es importante que conforme se vaya realizando cada iteracin, se vaya
llevando un control del mismo en una lista. Como si fuera un programa que recibe
actualizaciones constantemente. Cada una de las actualizaciones o iteraciones deber ser
documentada y de ser posible, guardada en sus respectivas versiones, para que sea sencillo
volver atrs, en caso de que una iteracin no sea exitosa o el usuario ya no la requiera.
Principios bsicos del Modelo Incremental
Es importante definir los siguientes principios fundamentales, pues nos permiten saber con
claridad por donde va la idea de la metodologa.
La idea de un modelo incremental, es utilizar una serie de mini modelos de desarrollo de
software en cascada, segmentando requerimientos y permitiendo que el usuario vaya de la
mano con el proyecto durante la realizacin.
Bsicamente las fases de cada iteracin, son las mismas que se manejan en el modelo de
cascada, aunque tambin se pueden agregar algunas, pero su objetivo es completar cada fase
de la iteracin, para que esta se vaya complementando poco a poco y no se genere un
desarrollo tedioso y cansado que puede alargar la duracin del proyecto en demasa.
Debes saber, que cada iteracin te generar un prototipo cada ves mas evolucionado, estos
debers guardarlos por si en determinado momento deseas volver atrs, pues a diferencia del
modelo de cascada, podemos retroceder cuando se requiera y los prototipos se pueden volver
a utilizar una y otra ves, pues el cdigo fuente es reutilizable.
Modelo en Espiral
El modelo en espiral, fue utilizado y diseado por primera ves por Barry Boehm en 1986. Se
trata nuevamente de una combinacin entre el modelo lineal o de cascada y el modelo iterativo
o basado en prototipos, sin embargo a este sistema lo que debemos aadirle es la gestin de
riesgos, algo que en los modelos anteriores ni siquiera se menciona.
Este modelo, consiste en ciertas fases que se van realizando en modo de espiral, utilizando
procesos de la misma forma en que se utilizan en el modelo de cascada, sin embargo aqu
estos no son obligatorios y no llevan precisamente el orden establecido. Bsicamente se trata
de un modelo evolutivo, que conforme avancen los ciclos, ir incrementando el nivel de cdigo
fuente desarrollado, un incremento en la gestin de riesgos y por supuesto un incremento en
los tiempos de ejecucin y planificacin del sistema, esto es lo que tiene el modelo en espiral.
Para que tengas una idea ms clara, el modelo en espiral es principalmente utilizado para el
desarrollo de grandes proyectos como la creacin de un sistema operativo. Sin embargo
necesitas de ciertos requisitos, como el hecho de contar con personal completamente
capacitado para las funciones que se requieran. Mejor veamos cuales son las las fases o tareas
dentro del modelo de espiral.
1. Determinar Objetivo. Es importante que siempre consideres una planeacin inicial, esta solo
se realizar una ves. Sin embargo el proceso de determinar objetivos se har constantemente
durante cada iteracin que se vaya realizando con el modelo espiral. Esto se debe a que poco
a poco se ir incrementando ms el tamao del manual de usuario, los requisitos, las
especificaciones e incluso las restricciones. Todo esto entra en lo que es la tarea de objetivos
y con cada vuelta en el espiral entraremos a esta tarea, la cual como todas las dems, es
fundamental.
2. Anlisis de Riesgo. Una etapa donde incluso una lluvia de ideas podra ayudar, el anlisis
de riesgos. Aqu debers tener en cuenta todo aquello que pueda daar a tu proyecto, ya sea
que se trate de ciertas amenazas o de posibles daos que se puedan ocasionar, teniendo
adems un Plan B por as decirlo, para que en caso de que ocurra algo inesperado, tener a la
mano la solucin para continuar con el proyecto.En esta fase del modelo espiral, podemos
agregar lo que son la creacin de prototipos, pues siempre es bueno tener un respaldo de
nuestro cdigo, se esta forma en caso de que algo malo suceda, volvemos a la versin anterior.
As que cada vez que vayamos a ingresar a la fase de pruebas e implementacin, ser
necesario contar con un prototipo que nos respalde.
3. Desarrollar, Validar y Probar. Bsicamente en esta fase, la forma en que se estar
desarrollando el proyecto, depender del anlisis de riesgos, pues siempre se va a ir
desarrollando el proyecto enfocndose en los riesgos que podemos evitar en nuestro software,
es decir, si la situacin de riesgo ms obvia se encuentra en la interfaz del usuario, entonces
hay que trabajar con prototipos para este enfoque, creando evoluciones proporcionales, para
ir evitando ese tipo de riesgos. Esto no significa que ignoremos el resto del proyecto o del
desarrollo, sin embargo el modelo en espiral si acomoda un poco ms las prioridades al
momento, independientemente de todo lo dems. Por lo que siempre en cada vuelta o iteracin
que se le de al modelo de espiral, tu avance siempre depender del anlisis de riesgo, hasta
que este sea mnimo y el desarrollo pueda continuar de forma normal.
4. Planificacin. Antes de proceder a realizar otra iteracin o vuelta al espiral, debemos prestar
atencin a lo que sucedi en la vuelta anterior. Debemos analizar detalladamente si los riesgos
encontrados ya tuvieron solucin, lo cual debe ser lo ideal, puesto que ahora habra que
analizar ms especificaciones y ms requisitos del sistema para continuar con el desarrollo.
Bsicamente la fase de planificacin, nos servir para determinar el avance de nuestro
proyecto y indicar hacia donde vamos a dirigirnos en la prxima iteracin.
Principios bsicos del modelo en Espiral
Est claro que el modelo en espiral, es sumamente distinto a los dems. Encontramos por
fuera cuatro fases bien organizadas, las cules siempre deben llevar ese orden que se estipula
desde el principio. Una determinacin de objetivos, un anlisis de riesgos, el desarrollo y las
pruebas, junto con la planificacin, la cual depender de los resultados de la iteracin para
saber cmo se actuar en la siguiente vuelta a la espiral.
Bsicamente, en el modelo de espiral, toda la atencin est enfocada hacia el anlisis de
riesgos, pues el objetivo primario ser reducir los riesgos que se vayan generando, de otra
forma el sistema no llegar a ser seguro jams.
Algo muy importante que debes ver en el modelo de espiral, es que los interesados deben
estar involucrados prcticamente en cada vuelta que se de al espiral, para crear lo que son los
requisitos antes de realizar una vuelta ms y al final en la fase de planificacin, se determinan
los logros obtenidos, el avance y lo que se esperar de una siguiente vuelta.
RAD: Desarrollo Rpido de Aplicaciones (Rapid Application Development)
A diferencia de otras metodologas para el desarrollo de software, la metodologa RAD o
desarrollo rpido de aplicaciones, no cuenta con una serie de fases ordenadas por as decirlo.
Aunque si est basada en lo que es el modelo de cascada y la creacin de prototipos, sin
embargo el proceso es muy independiente a contar con ciertas fases estipuladas como los
modelos que hemos visto anteriormente. As que vamos a ver los principios del modelo RAD.
Principios bsicos del Modelo RAD
Del mismo modos que modelos anteriores, el Modelo RAD, est basado en el uso de las
iteraciones y principalmente en el manejo de prototipos. Sin embargo a diferencia del resto, la
metodologa RAD hace uso de las Herramientas CASE, las cuales permitirn acelerar el
proceso considerablemente.
Del mismo modo que el modelos espiral y el de prototipos, RAD se subdivide en pequeas
secciones, las cuales se irn optimizando y de esta forma se ir avanzando mucho ms rpido
que con grandes segmentos que pueden volverse difciles dentro de un proceso acelerado
como lo este este modelo.
Una de las ventajas del RAD, es que el enfoque y las prioridades van hacia la fase de
desarrollo, a diferencia de modelos como el espiral, que se enfoca en que los riesgos al
momento sean mucho menores. Ac con el RAD, se hace lo contrario, si hay riesgos reducimos
los requerimientos para reducir los riesgos, no como en el espiral, que entre ms riesgos, ms
requisitos aportamos para que se incremente. Ac la idea es reducir tiempos y no riesgos, o
si, tal ves tambin, pero la reduccin de riesgos es totalmente inversa al modelo espiral.
Por supuesto, como en todos los modelos, vas a requerir de ciertos factores documentados,
de preferencia todo lo que se pueda, para que en caso de que alguien ms venga a continuar
con este proyecto, tenga a la mano toda la informacin que necesita y con unas cuentas
lecturas pueda empezar a desarrollar lo que se haba quedado pendiente en un determinado
momento.
1.3.2 Agiles
Actualmente los negocios operan en un entorno global que cambia rpidamente. Tienen que
responder a nuevas oportunidades y mercados, condiciones econmicas cambiantes y la
aparicin de productos y servicios competidores. El software es parte de casi todas las
operaciones de negocio, por lo que es fundamental que el software nuevo se desarrolle
rpidamente para aprovechar nuevas oportunidades y responder a la presin competitiva.
Actualmente el desarrollo y entrega de manera rpida son los requerimientos ms crticos de
los sistemas. De hecho, muchas organizaciones estn dispuestas a obtener una prdida en la
calidad del software y en el compromiso sobre los requerimientos en favor de una entrega
rpida del software.
Los procesos de desarrollo del software basados en una completa especificacin de los
requerimientos, diseo, construccin y pruebas del sistema no se ajustan al desarrollo rpido
de aplicaciones. Cuando los requerimientos cambian o se descubren problemas con ellos, el
diseo o implementacin del sistema se tiene que volver a realizar o probar. Como
consecuencia, normalmente se prolonga en el tiempo un proceso en cascada convencional y
el software definitivo se entrega mucho tiempo despus al cliente con el que inicialmente se
pact. En un entorno de negocios tan cambiante, esto puede causar verdaderos problemas.
Para cuando est disponible el software, la razn original de su adquisicin puede ser que
haya cambiado de forma radical que en realidad ste sea intil. Dicha metodologa combina
una filosofa y un conjunto de directrices de desarrollo. La filosofa busca la satisfaccin del
cliente y la entrega temprana de software incremental, equipos pequeos con alta motivacin,
mtodos informales y una simplicidad general del desarrollo. Los procesos de desarrollo rpido
de software estn diseados para producir software til de forma rpida. Generalmente, son
procesos interactivos en los que se entrelazan la especificacin, el diseo, el desarrollo y las
pruebas.
En los aos 80 y principios de los 90, exista una opinin general de que la mejor forma de
obtener un software de calidad era a travs de una planificacin cuidadosa del proyecto y de
la utilizacin de mtodos de anlisis y diseo soportados por herramientas CASE (Computer
Aided Software Engineering). Esta opinin vena fundamentalmente de la comunidad de
ingenieros de software implicado en el desarrollo de grandes sistemas y que normalmente se
componan de un gran nmero de programas individuales. Este software era desarrollado por
grandes equipos que trabajaban para compaas diferentes y que a menudo estaban dispersos
geogrficamente y trabajaban durante largos periodos de tiempo.
Sin embargo, cuando este enfoque era aplicado a sistemas de negocios pequeos y de tamao
medio, el esfuerzo invertido era tan grande que algunas veces dominaba el proceso de
desarrollo del software, es decir, se pasaba ms tiempo pensando en cmo se deba
desarrollar el sistema que en cmo programar el desarrollo y cmo hacer las pruebas
pertinentes. El descontento de esto produjo que varios desarrolladores propusieran nuevos
mtodos que eran ms giles. Aunque estos mtodos se basan principalmente en la nocin
del desarrollo y en las entregas incrementales, proponen procesos diferentes para alcanzar el
objetivo.
En una reunin celebrada en febrero de 2001 en Utah-EEUU, nace el trmino "gil" aplicado
al desarrollo de software. En esta reunin participan un grupo de diecisiete expertos de la
industria del software, incluyendo algunos de los creadores o impulsores de metodologas de
software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos
a desarrollar software rpidamente y respondiendo a los cambios que podran surgir a lo largo
de los proyectos. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en
cada una de las actividades desarrolladas. Varias de las denominadas metodologas giles ya
estaban siendo utilizadas con xito en proyectos reales, pero les faltaba una mayor difusin y
reconocimiento. Tras esta reunin se cre The Agile Alliance (2001), una organizacin, sin
nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de
software y ayudar a las organizaciones para que adopten dichos conceptos.
El punto de partida fue el manifiesto gil, un documento que resume la filosofa "gil". A
continuacin, vamos a enumerar las principales diferencias de una Metodologa gil respecto
a las Metodologas Tradicionales (llamadas peyorativamente no giles o pesadas). Estas
diferencias que no se refieren slo al proceso en s, sino tambin al contexto de equipo y
organizacin que es ms favorable a cada uno de estas filosofas de procesos de desarrollo
de software.
Si bien la idea de participacin del cliente en el proceso de desarrollo es atractiva, el xito
depender de tener un cliente que est dispuesto y lo ms importante pueda pasar tiempo con
el equipo de desarrollo para as presentar a todos los implicados del sistema, los clientes estn
sometidos a otras presiones y no pueden participar plenamente en el desarrollo del software.
El cliente es el punto clave, solicita los requerimientos que se deben de incluir. Los miembros
individuales del equipo pueden no tener la personalidad propia para una participacin intensa.
Por lo tanto, es posible que no se relacionen adecuadamente con los otros miembros del
equipo. Priorizar los cambios puede ser extremadamente difcil, especficamente en sistemas
en los que existen muchos implicados.
Mantener la simplicidad requiere un trabajo extra. Cuando se trabaja bajo presin por las
agendas de entregas, los miembros del equipo no pueden tener a tiempo las especificaciones
del sistema. Por consiguiente, los mtodos giles tienen que depender de contratos donde el
cliente paga por el tiempo necesario para el desarrollo del sistema en lugar de por el desarrollo
de un conjunto de requerimientos especficos. Siempre y cuando el proyecto vaya caminando
en forma, esto beneficiar tanto al cliente como al desarrollador. Todos los mtodos tienen
lmites y los mtodos giles son apropiados para algunos tipos de desarrollo de sistemas. Son
los ms idneos para el desarrollo de sistemas para pequeos negocios y medianas empresas.
No son adecuados para el desarrollo de sistemas a gran escala con equipos de desarrollo
situados en diferentes lugares geogrficamente hablando ya que puede haber complejas
interacciones con otros sistemas o hardware.
Los mtodos giles no se deben de utilizar para el desarrollo de sistemas crticos en los que
es necesario generar un anlisis detallado de todos los requerimientos del sistema para as
comprender mejor sus implicaciones de seguridad o de proteccin. El crecimiento de los
mtodos giles y su penetracin ocurre a un ritmo pocas veces visto en la industria: en tres o
cuatro aos, segn el Cutter Consortium, el 50% de las empresas define como giles ms de
la mitad de los mtodos empleados en sus proyectos (Charette, 2004). Algunas de las
metodologas agiles ms usadas en la actualidad se describen a continuacin.
 Metodologa XP programacin extrema
La programacin extrema XP es posiblemente el mtodo gil ms conocido y ampliamente
utilizado. El nombre de XP fue acuado por Beck (2000), debido a que el enfoque fue
desarrollado utilizando las mejores prcticas del desarrollo iterativo y con la participacin
extrema del cliente. La programacin extrema (XP), que algunos consideran una innovacin
extraordinaria y otros creen cnica (Rakitin, 2001). En la metodologa extrema, todos los
requerimientos se expresan como escenarios (llamados historias de usuario), los cuales se
implementan directamente como una serie de tareas. Los programadores trabajan en parejas
y desarrollan pruebas para cada tarea antes de escribir el cdigo. Todas las pruebas se deben
ejecutar satisfactoriamente cuando el cdigo nuevo se integra al sistema. Existe un pequeo
espacio de tiempo entre las entregas del sistema.
El desarrollo incremental se lleva a travs de entregas pequeas y frecuentes del sistema y
por medio de un enfoque que sirve para la descripcin de requerimientos basado en las
historias del clientes o escenarios que pueden ser la base para el proceso de planificacin.
La participacin del cliente se lleva a cabo a travs del compromiso y del tiempo completo del
cliente en el equipo de desarrollo. Los colaboradores directos de los clientes participan en el
desarrollo y son los responsables de definir las pruebas necesarias que servirn para la
aceptacin del sistema. El inters de las personas, en vez de los procesos, se lleva a travs
de la programacin en parejas, la propiedad colectiva del cdigo y un proceso de desarrollo
sostenible que no implique excesivas jornadas de trabajo. El cambio se lleva a cabo a travs
de las entregas regulares del sistema, un desarrollo previamente probado y la integracin
continua. El mantenimiento se lleva a cabo a travs de una recta actualizacin constante para
mejorar la calidad del cdigo y la utilizacin de diseos sencillos que no prevn cambios futuros
en el sistema.
En XP, los clientes estn implicados en la especificacin y establecimiento de prioridades de
los requerimientos del sistema. Dichos requerimientos no se especifica como una lista de
funciones requeridas en el sistema. Ms bien, los clientes del sistema son parte fundamental
del equipo de desarrollo esto permite que discutan escenarios con todos los miembros del
equipo. Desarrollar conjuntamente tarjetas de historia (story card) que recogen las
necesidades del cliente. Por ende el equipo de desarrollo intentar implementar esos
escenarios en una entrega futura del software. Un punto fundamental en la ingeniera del
soporte tradicional es que se debe de disear para futuros. Esto es que se deben de prever
los cambios futuros y disear ste de forma que tales cambios se puedan implementar
fcilmente. La metodologa XP ha descartado este principio partiendo del hecho de que disear
para el cambio es a menudo un esfuerzo intil. Con frecuencia los cambios previstos nunca se
materializa y realmente se efectan peticiones de cambios completamente diferentes. La
metodologa extrema aborda este problema sugiriendo que se debe revisar constantemente el
software. Esto es, que el equipo de programacin busca posibles mejoras y las implementa de
forma inmediata as lo que se busca es que siempre sea fcil de entender y cambiar cuando
simplemente nuevas historias.
 Metodologa SCRUM
A pesar de que la metodologa XP recibe la mayor atencin bibliogrfica, las organizaciones
estn enfocando su atencin en la metodologa gil denominada SCRUM (Schwaber &
Shuterland, 2011) (Shuterland, 2012), la cual aplica las mismas premisas conceptuales que
XP pero para resolver un problema ligeramente distinto como es el de desarrollo evolutivo de
aplicaciones. SCRUM es una metodologa gil y flexible que sirve para gestionar el desarrollo
de software, cuyo principal objetivo es maximizar el retorno de la inversin para su empresa.
Se basa principalmente en construir la funcionalidad de mayor valor para el cliente y en los
principios de inspeccin continua, adaptacin, auto-gestin e innovacin.
Con SCRUM el cliente es pieza fundamental en el desarrollo de software, se entusiasma y se
compromete con el proyecto dado que lo ve crecer iteracin a iteracin. Asimismo, le permite
en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya
que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteracin.
Esta forma de trabajo promueve la innovacin, motivacin y el compromiso del equipo que
forma parte del proyecto, por lo que los profesionales encuentran un mbito propicio para
desarrollar sus capacidades. SCRUM genera algunas ventajas a diferencia de otras
metodologas agiles entre ellas:
Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que
aporta a cada requisito / historia del proyecto, el equipo los estima y con esta informacin el
propietario del producto establece su prioridad.
Flexibilidad a cambios: Genera una alta capacidad de reaccin ante los cambios de
requerimientos generados por necesidades del cliente o evoluciones del mercado. La
metodologa est diseada para adaptarse a los cambios de requerimientos que conllevan los
proyectos complejos.
Reduccin del tiempo: El cliente puede empezar a utilizar las funcionalidades ms
importantes del proyecto antes de que est finalizado por completo.
Mayor calidad del software: La forma de trabajo y la necesidad de obtener una versin
funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad superior.
Mayor productividad: Se consigue entre otras razones, gracias a la eliminacin de la
burocracia y a la motivacin del equipo que proporciona el hecho de que sean autnomos para
organizarse.
Maximiza el retorno de la inversin (ROI): Produccin de software nicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de
inversin.
Predicciones de tiempos: Mediante esta metodologa se conoce la velocidad media del equipo
por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar
fcilmente para cuando se dispondr de una determinada funcionalidad que todava est
retrasada.
 Reduccin de riesgos: El hecho de llevar a cabo las funcionalidades de ms valor en primer
lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.
La totalidad de los requerimientos a desarrollar, denominados historias de usuario (user
stories) son divididos en grupos en funcin de su prioridad relativa para luego ser
implementados en ciclos de esfuerzos relativamente cortos llamados sprints; las tareas son
organizadas en el equipo de tal manera que las asignaciones y prioridades se revisan
diariamente en una reunin breve llamada SCRUM que le da su nombre la metodologa. En
este enfoque se siguen los principales criterios del manifiesto generando as liberaciones
parciales incrementales del producto que se est desarrollando. La evidencia es consistente
que al abrazar la hoja de ruta y comprometer las inversiones necesarias para desplegar
formalmente esta metodologa tambin se abordan al mismo tiempo aspectos clave del
despliegue de prcticas maduras de proceso.
En tal sentido SCRUM ha sido exitosamente comparada contra los requisitos a satisfacer para
alcanzar una de evaluacin bajo niveles 2 y 3 del modelo CMMI (Shuterland, et al, 2008),
(Turner & Jain, 2002). Demostrando as que la ejecucin rigurosa satisface a la mayora de los
objetivos necesarios que sirven para obtener estos niveles; las pocas reas del proceso no
cubiertas directamente por no ser requeridos por SCRUM son en la prctica un requisito para
el correcto desempeo de una organizacin dedicada a la construccin de software.
Desarrollo adaptativo de software (DAS)
El desarrollo adaptativo software (DAS) lo propuso Jim Highsmith en 1998 como una tcnica
para construir software y sistemas complejos. Los apoyos filosficos del DAS se enfocan en la
colaboracin humana y la organizacin propia del equipo. Un enfoque de desarrollo gil y
adaptativo basado en la colaboracin es " una fuente de orden en las complejas interacciones
entre disciplina e ingeniera". El define el ciclo de vida del DAS, como se muestra en la figura
2.29 el cual incorpora tres fases principales:
1) Especulacin; en esta fase se inicia el proyecto y se conduce el ciclo adaptativo de
planeacin. Este ltimo utiliza informacin de inicio del proyecto, es decir, el enunciado de la
misin del cliente, restricciones del proyecto y los requisitos bsicos. Esto permite definir el
conjunto de ciclos de lanzamiento que se requerirn para el proyecto.
2) Colaboracin; la gente motivada trabaja de una forma que multiplica su talento y sus
salidas creativas ms all de sus nmeros absolutos. Este enfoque de colaboracin es un tema
recurrente en todos los mtodos giles, pero la cooperacin no es fcil. No solamente es la
comunicacin, o que la comunicacin es parte de ella. No slo es un asunto de trabajo en
equipo, aunque un equipo cuajado es esencial para la presencia de la colaboracin real. No
es un rechazo al individualismo ya que la creatividad individual representa un papel importante
en el pensamiento de colaboracin. Esto es, por encima de todo, una cuestin de confianza.
Las personas que trabajan juntas deben confiar entre s para:
a) Criticar de forma constructiva
b) Ayudar sin resentimientos
c) Trabajar ms duro de lo que ya lo hace
d) Tener el conjunto de actitudes para contribuir al trabajo curso
e) Comunicar los problemas o preocupaciones en una forma que conduzca a la accin efectiva
3) Aprendizaje; como miembros de un equipo de DAS se comienzan a desarrollar los
componentes integrantes de un ciclo adaptativo, la importancia radica en el aprendizaje y en
el progreso a travs de un ciclo completo. De hecho, Highsmith (2002), argumenta que los
desarrolladores de software a menudo sobreestiman su comprensin (de la tecnologa, el
proceso y el proyecto), y que el aprendizaje les podr ayudar a mejorar su grado de
entendimiento real. Los equipos del DAS aprenden de tres maneras:
a) Grupos enfocados. El cliente o los usuarios finales proporcionan retroalimentacin sobre los
incrementos de software que se entregan. Esto indica en forma directa la satisfaccin o la
insatisfaccin de las necesidades del negocio.
b) Revisiones tcnicas formales. Los miembros del equipo del DAS revisan los componentes
del software desarrollado mientras mejoran su calidad y su aprendizaje.
c) Post mortem. El equipo de DAS se vuelve introspectivo al vigilar su propio desempeo y
proceso con el propsito de aprender acerca de su enfoque y despus mejorarlo.
Es importante destacar que la filosofa del DAS es meritoria sin importar el modelo del proceso
empleado. La dinmica de la organizacin propia los equipos, la colaboracin interpersonal y
el aprendizaje individual conducen a los grupos de proyectos de software con una mayor
posibilidad de xito.
1.3.3 Otras filosofas
1.4 Importancia de las herramientas CASE en la Ingeniera de software
Las Herramientas de Ayuda al Desarrollo de Sistemas de Informacin, surgieron para intentar
dar solucin a los problemas inherentes a los proyectos de generacin de aplicaciones
informticas: plazos y presupuestos incumplidos, insatisfaccin del usuario, escasa
productividad y baja calidad de los desarrollos. Algunas de estas herramientas se dirigen
principalmente a mejorar la calidad, como es el caso de las herramientas CASE (Computer
Aided Software Engineering- Ingeniera de Software Asistida por Computadora). Otras van
dirigidas a mejorar la productividad durante la fase de construccin, como es el caso de los
lenguajes de cuarta generacin (4GL-Fourth Generation Language).
Definicin
Son un conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de
vida del desarrollo de sistemas de informacin, completamente o en alguna de sus fases.
El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:
Anlisis de datos y procesos integrados mediante un repositorio.
Generacin de interfaces entre el anlisis y el diseo.
Generacin del cdigo a partir del diseo.
Control de mantenimiento.
Tipos de case
No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil incluirlas en
una clase determinada. Podran clasificarse atendiendo a:
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.
Las herramientas CASE, en funcin de las fases del ciclo de vida abarcadas, se pueden
agrupar de la forma siguiente:
Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases
del ciclo de vida del desarrollo de sistemas. Son llamadas tambin CASE workbench.
Las herramientas I-CASE se basan en una metodologa. Tienen un repositorio y aportan
tcnicas estructuradas para todas las fases del ciclo de vida. Estas son las caractersticas que
les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no
todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo
o la utilizacin de lenguajes de alto nivel o tcnicas de prototipo.
Herramientas que comprenden algunas fases del ciclo de vida de desarrollo de software:
Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a
la automatizacin y soporte de las actividades desarrolladas durante las primeras fases del
desarrollo: anlisis y diseo.
Una estrategia posible es utilizar una U-CASE para anlisis y diseo, combinada con otras
herramientas ms modernas para las fases de construccin y pruebas. En este caso, habra
que vigilar cuidadosamente la integracin entre las distintas herramientas.
Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a las
ltimas fases del desarrollo: construccin e implantacin.
Juegos de herramientas o toolkits, son el tipo ms simple de herramientas CASE. Automatizan
una fase dentro del ciclo de vida. Dentro de este grupo se encontraran las herramientas de
reingeniera, orientadas a la fase de mantenimiento.
Herramientas de planificacin de sistemas de gestin. Sirven para modelizar los requisitos de
informacin estratgica de una organizacin. Proporcionan un "metamodelo" del cual se
pueden obtener sistemas de informacin especficos. Su objetivo principal es ayudar a
comprender mejor cmo se mueve la informacin entre las distintas unidades organizativas.
Estas herramientas proporcionan una ayuda importante cuando se disean nuevas estrategias
para los sistemas de informacin y cuando los mtodos y sistemas actuales no satisfacen las
necesidades de la organizacin.
Herramientas de anlisis y diseo. Permiten al desarrollador crear un modelo del sistema que
se va a construir y tambin la evaluacin de la validez y consistencia de este modelo.
Proporcionan un grado de confianza en la representacin del anlisis y ayudan a eliminar
errores con anticipacin. Se tienen:
Herramientas de anlisis y diseo (Modelamiento).
Herramientas de creacin de prototipos y de simulacin.
Herramientas para el diseo y desarrollo de interfaces.
Mquinas de anlisis y diseo (Modelamiento)"
Herramientas de programacin. Se engloban aqu los compiladores, los editores y los
depuradores de los lenguajes de programacin convencionales. Ejemplos de estas
herramientas son:
Herramientas de codificacin convencionales.
Herramientas de codificacin de cuarta generacin.
Herramientas de programacin orientadas a los objetos.
Herramientas de integracin y prueba: Sirven de ayuda a la adquisicin, medicin,
simulacin y prueba de los equipos lgicos desarrollados. Entre las ms utilizadas
estn:
Herramientas de anlisis esttico.
Herramientas de codificacin de cuarta generacin.
Herramientas de programacin orientadas a los objetos.
Herramientas de gestin de prototipos. Los prototipos son utilizados ampliamente en el
desarrollo de aplicaciones, para la evaluacin de especificaciones de un sistema de
informacin, o para un mejor entendimiento de cmo los requisitos de un sistema de
informacin se ajustan a los objetivos perseguidos.
Herramientas de mantenimiento: La categora de herramientas de mantenimiento se
puede subdividir en:
Herramientas de ingeniera inversa.
Herramientas de reestructuracin y anlisis de cdigo.
Herramientas de reingeniera.
Herramientas de gestin de proyectos. La mayora de las herramientas CASE de
gestin de proyectos, se centran en un elemento especfico de la gestin del proyecto,
en lugar de proporcionar un soporte global para la actividad de gestin. Utilizando un
conjunto seleccionado de las mismas se puede: realizar estimaciones de esfuerzo,
coste y duracin, hacer un seguimiento continuo del proyecto, estimar la productividad
y la calidad, etc. Existen tambin herramientas que permiten al comprador del desarrollo
de un sistema, hacer un seguimiento que va desde los requisitos del pliego de
prescripciones tcnicas inicial, hasta el trabajo de desarrollo que convierte estos
 requisitos en un producto final. Se incluyen dentro de las herramientas de control de
proyectos las siguientes:
Herramientas de planificacin de proyectos.
Herramientas de seguimiento de requisitos.
Herramientas de gestin y medida.
Herramientas de soporte. Se engloban en esta categora las herramientas que recogen
las actividades aplicables en todo el proceso de desarrollo, como las que se relacionan
a continuacin:
Herramientas de documentacin.
Herramientas para software de sistemas.
Herramientas de control de calidad.
Herramientas de bases de datos.
Otra clasificacin, diferencia las funciones CASE en cinco grupos:
Repositorio. Funcionan en torno a un repositorio central, siendo ste el ncleo fundamental
que contiene todas las definiciones de objeto y sus relaciones. Los objetos pueden ser
especificaciones del sistema en forma de diagramas de flujo de datos, diagramas entidad-
relacin, esquemas de bases de datos, diseos de pantallas, etc. El repositorio es un concepto
ms amplio que el de diccionario de datos y soporta a los dems grupos de funciones. No es
fcil encontrar en el mercado productos Case con funcionalidades estrictamente a las de
repositorio, ya que, a pesar de su innegable importancia, tienen un carcter auxiliar de los
dems grupos de funciones. Cualquier sistema Case poseer un repositorio propio o bien,
trabajar sobre un repositorio suministrado por otro fabricante o vendedor.
Reingeniera. Los sistemas Case permiten establecer una relacin estrecha y fuertemente
formalizable entre los productos generados a lo largo de distintas fases del ciclo de vida,
permitiendo actuar en el sentido especificaciones-cdigo (ingeniera "directa") y tambin en el
contrario (ingeniera "inversa"). Ello facilita la realizacin de modificaciones en la fase ms
adecuada en cada caso y su traslado a las dems. Al conjunto de facilidades proporcionadas
por la ingeniera "directa" e "inversa" se le denomina "re-ingeniera".
Soporte del ciclo de vida. El ciclo de vida de una aplicacin o de un sistema de informacin se
compone de varias etapas, que van desde la planificacin de su desarrollo hasta su
implantacin, mantenimiento y actualizacin. Aunque el nmero de fases puede ser variable
en funcin del nivel de detalle que se adopte, pueden de modo simplificado, identificarse las
siguientes:
Planeamiento.
Anlisis y Diseo.
Implantacin (programacin y pruebas).
Mantenimiento y actualizacin.
Los sistemas Case pueden cubrir la totalidad de estas fases o bien especializarse en alguna(s)
de ellas. En este ltimo caso se pueden distinguir sistemas de "alto nivel" ("Upper Case"),
orientados a la autonoma y soporte de las actividades correspondientes a las dos primeras
fases y, sistemas de "bajo nivel" ("Lower Case"), dirigidos hacia las dos ltimas. Los sistemas
de "alto nivel" pueden soportar un nmero ms o menos amplio de metodologas de desarrollo.
Soporte de proyecto. Este tipo de funciones hace referencia al soporte de actividades que se
producen durante el desarrollo, derivadas fundamentalmente del trabajo en grupos, tales como
facilidades de comunicacin, soporte a la creacin, modificacin e intercambio de
documentacin, herramientas personales, controles de seguridad, etc. Los sistemas Case
pueden conceder a estas cuestiones una importancia variable por lo cual el soporte de
proyecto constituye un factor de diferenciacin.
Mejora continua de calidad. Aunque frecuentemente se asocia a los sistemas Case con la
mejora de la productividad en el desarrollo de aplicaciones, debe tenerse en cuenta que una
de las principales ventajas estriba tambin, en la mejora de la calidad de los desarrollos
realizados. Determinados sistemas Case enfatizan ms sobre este punto que sobre el anterior,
introduciendo herramientas que permiten ejercer un control intenso de garanta de calidad del
software desarrollado desde las primeras fases de su ciclo de vida.
Beneficios de las herramientas case
Entre los beneficios ofrecidos por la tecnologa CASE se encuentran los siguientes:
Facilidad para la revisin de aplicaciones
La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por
mucho tiempo. Las herramientas CASE proporcionan un beneficio substancial para las
organizaciones al facilitar la revisin de las aplicaciones. Contar con un depsito central agiliza
el proceso de revisin ya que ste proporciona bases para las definiciones y estndares para
los datos. Las capacidades de generacin interna, si se encuentran presentes, contribuyen a
modificar el sistema por medio de las especificaciones ms que por los ajustes al cdigo fuente.
Soporte para el desarrollo de prototipos de sistemas
En general, el desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se
desarrollan diseos para pantallas y reportes con la finalidad de mostrar la organizacin y
composicin de los datos, encabezados y mensajes. Los ajustes necesarios al diseo se hacen
con rapidez para alterar la presentacin y las caractersticas de la interface. Sin embargo, no
se prepara el cdigo fuente, de naturaleza orientada hacia procedimientos, como una parte del
prototipo.
Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las
caractersticas de entrada y salida son desarrolladas junto con el cdigo orientado hacia los
procedimientos y archivos de datos.
Muchas herramientas CASE soportan las primeras etapas del desarrollo del prototipo. Muy
pocas brindan apoyo durante todo el proceso de desarrollo del prototipo. Las que proporcionan
la capacidad para generar cdigo soportan de hecho todo proceso, ya que el cdigo puede ser
generado al inducir la actividad de generacin despus de cambiar las especificaciones o
requerimientos.
Generacin de cdigo
Como ya se mencion, algunas herramientas CASE tienen la capacidad de producir el cdigo
fuente. La ventaja ms visible de esta caracterstica es la disminucin del tiempo necesario
para preparar un programa. Sin embargo, la generacin del cdigo tambin asegura una
estructura estndar y consistente para el programa (lo que tiene gran influencia en el
mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta
manera la calidad. Las caractersticas de la generacin del cdigo permiten volver a utilizar el
software y las estructuras estndares para generar dicho cdigo, as como el cambio de una
especificacin modular, lo que significa volver a generar el cdigo y los enlaces con otros
mdulos. Ninguna de las herramientas que existen en el presente es capaz de generar un
cdigo completo en los dominios.
Mejora en la habilidad para satisfacer los requerimientos del usuario
Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto
guarda relacin con el xito del sistema. De manera similar, tener los requerimientos correctos
mejora la calidad de las practicas de desarrollo. Parece ser que las herramientas CASE
disminuyen el tiempo de desarrollo, una caracterstica que es importante para los usuarios.
Las herramientas afectan la naturaleza y cantidad de interaccin entre los encargados del
desarrollo y el usuario. Las descripciones grficas y los diagramas, as como los prototipos de
reportes y la composicin de las pantallas, contribuyen a un intercambio de ideas ms efectivo.
Soporte interactivo para el proceso de desarrollo
La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las
herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar
diagramas, elaborar catlogos y clasificar. Como resultado de esto, se anticipa que los
analistas repasarn y revisarn los detalles del sistema con mayor frecuencia y en forma ms
consistente.
Debilidades de las herramientas case
Las herramientas CASE tienen puntos dbiles significativos, que van desde la confiabilidad en
los mtodos estructurados hasta su alcance limitado, los cuales amenazan con minar los
beneficios potenciales descritos con anterioridad.
Confiabilidad en los mtodos estructurados
Muchas herramientas CASE estn construidas teniendo como base las metodologas del
anlisis estructurado y del ciclo de vida de desarrollo de sistemas. Por si sola, esta
caracterstica puede convertirse en la principal limitante ya que no todas las organizaciones
emplean mtodos de anlisis estructurado.
Los mtodos estructurados, introducidos en la dcada de los setenta, fueron muy elogiados
por su habilidad para mejorar la exactitud de los requerimientos especficos de las
aplicaciones. El nivel de conocimiento de los mtodos estructurados es lato entre los
profesionales de sistemas de informacin - de acuerdo con algunas estimaciones (Yourdon),
casi el 90% de todos los analistas esta familiarizado con estos mtodos -. Aproximadamente
la mitad de todas las organizaciones en Estados Unidos han utilizado alguna vez estos
mtodos. A pesar de lo anterior, si la organizacin o el analista no utilizan los mtodos propios
del anlisis estructurado y tampoco desean considerar su uso, entonces el valor del CASE
disminuye. En algunos casos, los analistas evitan del todo emplear herramientas CASE.
Falta de niveles estndar para el soporte de la metodologa
An no aparece un conjunto "estndar" de herramientas CASE. Por tanto, debe tener
precaucin al seleccionar una herramienta de este tipo.
Existen dos significados para las palabras "soporte de la metodologa". Una herramienta
puede: 1) dar soporte a los diagramas que emplea una metodologa o 2) soportarlos e imponer
la metodologa, sus reglas y procesos.
Las herramientas CASE que existen en el presente, tienen una de las siguientes
caractersticas:
Son independientes de la metodologa.
Permiten que los usuarios definan sus propias metodologas.
Soportan una metodologa.
Soportan las metodologas ms diseminadas.
En todas ellas existen ciertos compromisos. Las herramientas que son independientes de la
metodologa, no pueden fomentar el uso de las reglas y estndares de la misma. Estas
herramientas quiz proporcionen los componentes de una metodologa (por ejemplo:
diagramas de flujos de datos, un diccionario de datos y facilidades para la descripcin de
procesos), pero no el marco de referencia, reglas y procedimientos que en realidad constituyen
el ncleo de la metodologa. Aunque se puede llevar a cabo acciones bsicas para la validacin
de diseos y diagramas para detectar componentes faltantes, stas son slo funciones
mecnicas. Por otra parte, esta clase de herramientas no puede proporcionar ayuda
metodolgica o pedir al usuario que realice tareas necesarias para la metodologa que an
esta sin terminar.
Estas herramientas mejoran la productividad al efectuar tareas tediosas y de documentacin,
aunque ellas no puedan asegurar buenos resultados. Desde el punto de vista funcional, las
capacidades que brindan para garantizar la calidad son mnimas.
Conflictos en el uso de los diagramas
Las herramientas difieren en el uso que hacen los diagramas. Algunas son herramientas
exclusivamente para grficas, que se abocan al dibujo de diagramas para el anlisis de entrada
y salida de datos. Este tipo de herramientas puede restringir ya sea el proceso de desarrollo
normal seguido por una organizacin o el estilo particular de trabajo de los analistas.
Otros vendedores de herramientas consideran los diagramas como documentacin y aceptan
entradas por medio de formas o lenguajes de especificacin y, en ocasiones, en forma grfica.
Por tanto, se debe tener cuidado cuando se selecciona una herramienta para apoyar los
mtodos existentes en una organizacin.
Diagramas no utilizados
En general, los productos CASE emplean grficas para modelar y generar informes sobre el
anlisis y desarrollo de sistemas. Una de las afirmaciones de los vendedores de herramientas
es que las presentaciones grficas y la documentacin mejoran la comunicacin entre los
miembros del equipo de desarrollo, propician una calidad mayor de la entrada proporcionada
por el cliente y mejoran la productividad de desarrollo de software. Sin embargo, los
investigadores han encontrado que, en algunos casos, las herramientas grficas,
automatizadas o manuales, no se emplean del todo. O tal vez no se utilicen en la forma que
deberan emplearse. Por otra parte, algunos analistas prefieren para algunas tareas un
lenguaje estructurado o descriptivo.
Muchos profesionales de los sistemas de informacin no hacen uso de herramientas grficas
en el desarrollo de software; ms bien las emplean para automatizar la produccin de informes
y documentacin del sistema, como los diagramas de flujo utilizados por los programadores
para documentar un programa una vez terminado.
Funcin limitada
Aunque una herramienta puede apoyar varias fases del ciclo de vida de desarrollo de sistemas
o adaptarse a diferentes metodologas de desarrollo, por lo general su enfoque primario est
dirigido hacia una fase o mtodo especifico. Por ejemplo, los encargados de desarrollar un
nuevo producto pueden afirmar que ste apoya todo el proceso de anlisis y diseo. Sin
embargo, las capacidades de comprobacin y verificacin de errores del producto quiz sean
ms rigurosas ya sea en el rea de anlisis o en la de diseo, pero no en ambas. Algunos
productos estn dirigidos hacia el diseo de bases de datos para la organizacin y al desarrollo
de aplicaciones que giren en torno a la base de datos, omitiendo el soporte para pantallas de
presentacin visual, los informes sobre requerimientos o las necesidades de seguridad.
Algunos productos capaces de generar el cdigo hacen mayor hincapi en el desarrollo de
prototipos como el principal mtodo de desarrollo de sistemas de informacin. Muchas
herramientas para la fase de desarrollo recalcan el mantenimiento y la reestructuracin del
cdigo, pero ofrecen un soporte dbil durante la fase de anlisis para la determinacin y
especificacin de requerimientos.
Alcance limitado
Aunque muchas herramientas basadas en computadoras incluyen la capacidad de verificar las
especificaciones para determinar su complementes o consistencia, virtualmente no llevan a
cabo ningn anlisis de los requerimientos de la aplicacin. Por tanto, el alcance de las
actividades de desarrollo asociado con las herramientas existentes es bastante limitado.
La mayor parte de productos CASE describe (documenta) pero no analiza. De poca ayuda es
proporcionar una regla de inclusin en los mejores enfoques y una regla de exclusin para los
que son poco satisfactorios. No ofrecen o evalan, soluciones potenciales para los problemas
relacionados con sistemas. Y tampoco existe una garanta clara para que dos analistas que
utilicen los mismos mtodos aplicados a informacin idntica, formulen recomendaciones
igualmente aceptables.
Opciones de integracion
Las herramientas Case pueden ser integradas de muchas formas. En un extremo se utiliza
una herramienta CASE de forma aislada. Se crea un nmero limitado de elementos de
configuracin de software (documentos, programas o datos) que se manipulan mediante una
nica herramienta y cuya salida tiene el formato de copia de pantalla y/o documentacin
grfica. En cierto sentido, el enlace con el resto del entorno de desarrollo se realiza mediante
copias en papel que gestiona el ingeniero.
Pocas herramientas CASE se utilizan en forma aislada. Se suele disponer de las siguientes
opciones:
a) Intercambio de datos. La mayora de las herramientas permiten exportar datos en forma de
archivo sin estructura con un formato conocido. Esto permite un intercambio de datos punto a
punto entre las distintas herramientas CASE, utilizando normalmente un "filtro" de transmisin
intermedio.
La desventaja del intercambio de datos punto a punto est en que, a menudo, slo parte de
los datos exportados es utilizable por la herramienta receptora, ya que no fue diseada para
ser totalmente compatible. Adems, a medida que evoluciona el software, la necesidad de
transferir archivos cada vez que se hace un cambio pequeo puede llevar mucho tiempo. Las
versiones pueden quedar "desfasadas" fcilmente, perdindose la posibilidad de transferencia,
la cual suele ser en un nico sentido. No hay posibilidad de que los cambios se reflejen en
ambos sentidos y, es difcil hacer comprobaciones cruzadas de documentos y mantener la
integridad de la configuracin a travs de las distintas herramientas que se estn utilizando.
b) Acceso comn a herramientas. Permite al usuario utilizar distintas herramientas de forma
similar, por ejemplo a travs de un men desplegable del gestor de ventanas del sistema
operativo. En un entorno multitarea, un usuario podra abrir simultneamente varias
herramientas, coordinando manualmente sus entradas y comparando las representaciones de
diseo a medida que evolucionan. Por ejemplo, el usuario podra visualizar un diagrama de
flujo de datos, un diagrama de estructura, un diccionario de datos y un segmento de cdigo
fuente, todos mantenidos por diferentes herramientas. En estos entornos, el intercambio de
datos de herramienta a herramienta podra simplificarse llamando al procedimiento de
traduccin a travs de un simple men o de la seleccin de una macro. No es la opcin ms
adecuada
c) Integracin de Datos.
Gestin comn de datos. Los datos de distintas herramientas se pueden mantener en una
nica base de datos lgica, que puede estar fsicamente centralizada o distribuida. Hay una
modalidad de fusin que permite combinar el trabajo de varias personas trabajando en
diferentes partes de una aplicacin.
Aunque los datos generados por las distintas herramientas se gestionan de forma conjunta en
el nivel de gestin de datos comunes, las herramientas no conocen de forma explcita las
estructuras de datos y la semntica de representacin del diseo de las dems.
Consecuentemente, se requiere una etapa de traduccin (normalmente ejecutada
manualmente) para permitir que una herramienta utilice la salida generada por otra.
Datos compartidos. Las herramientas del nivel de datos compartidos tienen estructuras de
datos y semntica compatible, pudiendo intercambiar datos sin necesidad de una etapa de
traduccin. Cada herramienta se disea para ser compatible con las dems. Por esta razn, la
mayor parte del intercambio de datos se da entre herramientas de un nico fabricante o en
casos en los que se han establecido relaciones estratgicas, entre distintos fabricantes para
generar un conjunto de datos integrado, a veces, a peticin de clientes importantes.
Interoperabilidad. Las herramientas que combinan las caractersticas de acceso comn y la
capacidad de compartir datos, tienen la capacidad de interoperacin. Esto representa el mayor
nivel de integracin entre herramientas diferentes. Sin embargo, hay otras propiedades del
entorno global CASE que se pueden aadir para mejorar la efectividad del proceso de
desarrollo de software.
. d) Integracin total. Para alcanzar la integracin total del entorno CASE se necesitan dos
caractersticas ms: gestin de metadatos y capacidad de control. Los metadatos representan
informacin sobre los datos de ingeniera generados por las distintas herramientas CASE. Esta
informacin incluye:
Definiciones de objetos (tipos, atributos, representaciones y relaciones vlidas).
Relaciones y dependencias entre objetos de granularidad arbitraria (p. ej.: un proceso en un
diagrama DFD, una entidad nica o un fragmento de cdigo de una subrutina).
Reglas de diseo del software (p. ej.: las distintas formas vlidas de dibujar y equilibrar un
diagrama de flujo de datos).
Procedimientos (fases estndar, hitos, informes, etc.) y sucesos (revisiones, finalizaciones,
informes de problemas, peticiones de cambios, etc.) del flujo de trabajo (proceso).
Normalmente, la parte de reglas y procedimientos de los metadatos se definen en forma de
base de reglas, para facilitar su modificacin segn evoluciona el proceso de desarrollo del
software. Por ejemplo, un nuevo mtodo de diseo podra alterar las reglas de representacin
y cambiar los estndares del proceso de trabajo seguido hasta el momento.
La capacidad de control permite que cada herramienta pueda notificar al resto del entorno (a
otras herramientas, al gestor de metadatos, al gestor de datos, etc.) la ocurrencia de sucesos
significativos, as como enviar peticiones para la realizacin de acciones a otras herramientas
y servicios por medio de un activador. Por ejemplo, una herramienta de gestin de
configuracin que haga una comprobacin cruzada de la consistencia de documentos. La
capacidad de control ayudar a mantener la integridad del entorno y proporcionar, tambin,
un medio para automatizar procesos y procedimientos estndar. El activador puede estar
incorporado en un entorno cerrado o puede estar visible para las distintas herramientas, a
travs de una interfase de programacin y un mecanismo de paso de mensajes.
La tecnologa Case tendr el mayor impacto si se integra a proyectos de innovacin
tecnolgica que hoy en da contemple:
Interfases de programacin visual.
Soluciones cliente-servidor.
Manejo de mltiples Bases de Datos.
Independencia de la plataforma de hardware y software.
Reingeniera de proceso de negocios.
Componentes y funcionalidades de una herramienta case
A continuacin, se describen los principales componentes de una herramienta CASE y sus
funcionalidades:
Repositorio. Base de datos central de una herramienta CASE. El repositorio amplio el concepto
de diccionario de datos para incluir toda la informacin que se va generando a lo largo del ciclo
de vida del sistema, como por ejemplo: componentes de anlisis y diseo (diagramas de flujo
de datos, diagramas entidad - relacin, esquemas de bases de datos, diseos de pantallas),
estructuras de programas, algoritmos, etc. En algunas referencias se le denomina Diccionario
de Recursos de Informacin.
La mayora de las herramientas CASE poseen un repositorio propio o bien trabajan sobre un
repositorio suministrado por otro fabricante o vendedor.
Apoyndose en la existencia del repositorio se efectan comprobaciones de integridad y
consistencia:
Que no existan datos no definidos.
Que no existan datos autodefinidos (datos que se emplean en una definicin pero que
no han sido definidos previamente).
Que todos los alias (referencias a un mismo dato empleando nombres distintos) sean
correctos y estn actualizados.
Las caractersticas ms importantes de un repositorio son:
Tipo de informacin. Que contiene alguna metodologa concreta, datos, grficos, procesos,
informes, modelos o reglas.
Tipo de controles. Si incorpora algn mdulo de gestin de cambios, de mantenimiento de
versiones, de acceso por clave, de redundancia de la informacin. La gestin de cambios y el
mantenimiento de versiones, ayudarn en el caso de que convivan diferentes versiones de la
misma aplicacin o se tengan que realizar cambios en la versin en produccin y en la de
desarrollo, simultneamente.
Tipo de actualizacin. Si los cambios en los elementos de anlisis o diseo se ven reflejados
en el repositorio en tiempo real o mediante un proceso por lotes (batch). Esto ser importante
en funcin a la necesidad de que los cambios sean visibles por todos los usuarios, en el acto.
Reutilizacin de mdulos para otros diseos. El repositorio es la clave para identificar, localizar
y extraer cdigo para su reutilizacin.
Posibilidad de exportacin e importacin para extraer informacin del repositorio y tratarla con
otra herramienta (formateo de documentos, mejora de presentacin) o incorporar al repositorio,
informacin generada por otros medios.
Interfases automticas con otros repositorios o bases de datos externos.
Mdulos de diagramacin y modelizacin.
Algunos de los diagramas y modelos utilizados con mayor frecuencia son:
Diagrama de flujo de datos.
Modelo entidad - interrelacin.
Historia de la vida de las entidades.
Diagrama Estructura de datos.
Diagrama Estructura de cuadros.
Tcnicas matriciales.

Algunas caractersticas referentes a los diagramas son:

Nmero mximo de niveles para poder soportar diseos complejos.
Nmero mximo de objetos que se pueden incluir para no encontrarse limitado en el
diseo de grandes aplicaciones.
Nmero de diagramas distintos en pantalla o al mismo tiempo en diferentes ventanas.
Dibujos en formato libre con la finalidad de aadir comentarios, dibujos, informacin
adicional para aclarar algn punto concreto deliseo.
Actualizacin del repositorio por cambios en los diagramas. Siempre resulta ms fcil
modificar de forma grfica un diseo y que loscambios queden reflejados en el
repositorio.
Control sobre el tamao, fuente y emplazamiento de los textos en el diagrama.
Comparaciones entre grficos de distintas versiones. De esta forma ser ms fcil
identificar qu diferencias existen entre las versiones.
 Inclusin de pseudocdigo que servir de base a los programadores para completar el
desarrollo de la aplicacin.
Posibilidad de deshacer el ltimo cambio facilitando que un error no conlleve perder el
trabajo realizado.
Herramienta de prototipado: El objetivo principal de esta herramienta es poder mostrar al
usuario, desde los momentos iniciales del diseo, el aspecto que tendr la aplicacin una vez
desarrollada. Ello facilitar la aplicacin de los cambios que se consideren necesarios, todava
en la fase de diseo.
La herramienta ser tanto ms til, cuanto ms rpidamente permita la construccin del
prototipo y por tanto antes, se consiga la implicacin del usuario final en el diseo de la
aplicacin. Asimismo, es importante poder aprovechar como base el prototipo para la
construccin del resto de la aplicacin. Actualmente, es imprescindible utilizar productos que
incorporen esta funcionalidad por la cambiante tecnologa y necesidades de los usuarios.
Los prototipos han sido utilizados ampliamente en el desarrollo de sistemas tradicionales ya
que proporcionan una realimentacin inmediata, que ayudan a determinar los requisitos del
sistema. Las herramientas CASE estn bien dotadas, en general, para crear prototipos con
rapidez y seguridad.
Generador de cdigo: Normalmente, se suele utilizar sobre ordenadores personales o
estaciones de trabajo, por lo que el paso posterior del cdigo al host puede traer problemas, al
tener que compilar en ambos entornos.
Las caractersticas ms importantes de los generadores de cdigo son:
Lenguaje generado. Si se trata de un lenguaje estndar o un lenguaje propietario.
Portabilidad del cdigo generado. Capacidad para poder ejecutarlo en diferentes
plataformas fsicas y/o lgicas.
Generacin del esqueleto del programa o del programa completo. Si nicamente genera
el esqueleto ser necesario completar el resto mediante programacin.
Posibilidad de modificacin del cdigo generado. Suele ser necesario acceder
directamente al cdigo generado para optimizarlo o completarlo.
Generacin del cdigo asociado a las pantallas e informes de la aplicacin. Mediante
esta caracterstica se obtendr la interfase de usuario de la aplicacin.
Mdulo generador de documentacin. El mdulo generador de la documentacin se
alimenta del repositorio para transcribir las especificaciones all contenidas.
Algunas caractersticas de los generadores de documentacin son:
Generacin automtica a partir de los datos del repositorio, sin necesidad de un esfuerzo
adicional.
Combinacin de informacin textual y grfica, lo que hace ms fcil su comprensin.
Generacin de referencias cruzadas. Con ello se podr localizar fcilmente en qu partes de
la aplicacin se encuentra un determinado objeto o elemento, con el fin de analizar el impacto
de un cambio o identificar los mdulos afectados por un determinado error.
Ayuda de tratamiento de textos. Facilidad para la introduccin de textos complementarios a la
documentacin que se genera de forma automtica.
Interfase con otras herramientas: procesadores de textos, editores grficos, etc.
Mdulo de gestin de proyectos. Algunos productos CASE incorporan un mdulo para la
gestin del proyecto de desarrollo de sistemas. Sus caractersticas ms importantes sern
analizadas en el apartado de otras herramientas.
Conceptos de la orientacin a objetos
Objetos:
Un objeto es cualquier cosa que se ofrece ala vista y afecta a los sentidos.
Un objeto es una entidad tangible que exhibe algn comportamiento bien definido
Un objeto tiene un estado, comportamiento e identidad.
Estado
conjunto de atributos
condicin actual del objeto
vara dinmicamente
no es accesible directamente desde fuera
no es modificable directamente desde fuera
Mtodos
responden a los mensajes
forma de interaccin con el objeto
nica forma de interactuar con el objeto
Clase:
Una clase define comportamientos comunes a objetos similares
Una clase es una abstraccin de un conjunto de objetos con caractersticas en comn.
Una clase es una fabrica de objetos
Una clase es una especificacin de los atributos y mtodos
Instancia:
Un objeto es una instancia de una clase
Las variables de instancia son los valores explicitos para cada objeto
Herencia:
La herencia es un mecanismo para compartir datos y mtodos entre clases.
Por la herencia se forman jerarquas de clases con subclases y superclases.
Las instancias de las subclases heredan los atributos y mtodos de las superclases.
Este enfoque no es totalmente nuevo, sino que puede considerarse como una extensin del
modelado de datos (DER) que se utiliza en los mtodos estructurados. Sin embargo, el
modelado de datos mediante DER est ms orientado al diseo de bases de datos y se centra
exclusivamente en la identificacin de los datos que maneja un sistema y en las relaciones
estticas que se establecen entre esos datos. En el AOO, los objetos encapsulan tanto
atributos como procedimientos (operaciones que se realizan sobre los objetos), e incorpora
adems conceptos como el polimorfismo o la herencia que facilitan la reutilizacin de cdigo.
El uso de AOO puede facilitar mucho la creacin de prototipos, y las tcnicas de desarrollo
evolutivo de software. Los objetos son inherentemente reutilizables, y se puede crear un
catlogo de objetos que podemos usar en sucesivas aplicaciones. De esta forma, podemos
obtener rpidamente un prototipo del sistema, que pueda ser evaluado por el cliente, a partir
de objetos analizados, diseados e implementados en aplicaciones anteriores. Y lo que es ms
importante, dada la facilidad de reutilizacin de estos objetos, el prototipo puede ir
evolucionando hacia convertirse en el sistema final, segn vamos refinando los objetos de
acuerdo a un proceso de especificacin incremental.
 Conclusin
La ingeniera de software es una disciplina de la ingeniera que nos ayudan a desarrollar
sistemas de software a tiempo y a la vez que se cumpla con las expectativas de calidad y que
permanezca dentro del presupuesto. Sus tres elementos importantes son: algoritmos,
estructura de datos y documentos. El proyecto de software cumple con un ciclo de vida, para
todo proyecto de software se debe elegir el modelo en el que se trabajara, es muy importante
realizar prototipos de los productos de software para el mejor diseo y entendimiento de lo que
requiere el cliente. Para esto necesitamos informacin adecuada, podemos utilizar cualquier
tcnica de recopilacin de informacin siempre y cuando se haga de la forma correcta y
constante comunicacin con el cliente.
En el desarrollo de productos de software las etapas de anlisis de requerimientos y diseo
toma gran parte del tiempo del proyecto. El modelo planteado en este proyecto pretende
establecer unos parmetros de diseo generales que permitan agilizar la implementacin de
proyectos tipo sistemas de control por software, cuya base comn es el procesamiento de
seales digitales en busca de comportamientos de inters (caracterizacin de seales).
Bajo la idea de cmo se concibe este modelo, se puede evaluar si es posible aplicar el
concepto general a nuevos campos o ambientes, definiendo nuevos modelos generales que
puedan ser correspondientes a tipos de problemas especficos. Parte de la utilidad que tendra,
es el poder agilizar la produccin de software, sin comprometer la no realizacin de actividades
como el anlisis y diseo, poniendo en riesgo el desarrollo del proyecto.
 Referencias Bibliogrficas

1.- Ingeniera del Software (7 ED.) ROGER PRESSMAN

2.- Ingeniera de Software. PEARSON EDUCACIN, Mxico, 2011
3.- Introduccin a la ingeniera del software. Fernando Alonso Amo, Loc Martnez Normand,
Francisco Javier Segovia Prez
4.- Ingeniera del software. Ian Sommerville
5.- https://okhosting.com/blog/metodologias-del-desarrollo-de-software/
6.- http://systeminfo.es.tl/4-.-1-.-3-.--HERRAMIENTAS-CASE.htm