ROGER PRESSMAN BIOGRAFA:

Roger S. Pressman es un norteamericano ingeniero de software, autor

y consultor, y el presidente de RS Pressman & Associates. l recibi una
encefalopata espongiforme bovina de la Universidad de Connecticut,
una maestra de la Universidad de Bridgeport y un doctorado de la
Universidad de Connecticut. Tiene ms de 30 aos de experiencia
trabaj como ingeniero de software, un gerente, un profesor, un autor y
un consultor, centrndose en cuestiones de ingeniera de software. l ha
estado en el Consejo de Redaccin de IEEE Software y TI El cortador
Diario. Es miembro del IEEE y Tau Beta Pi. Roger Pressman, es una
autoridad internacionalmente reconocida en la mejora de procesos de
software y en tecnologas de Ingeniera de software. Por ms de tres
dcadas, ha trabajado como ingeniero, gerente, profesor, autor y
consultor de software en temas de ingeniera de software. Actualmente
es presidente de R.S. Pressman and Associates, Inc., una firma
consultora especialista en mtodos y entrenamiento en ingeniera de
software. Pressman ha diseado y desarrollado productos que se utilizan
en todo el mundo para la formacin de ingeniera de software y mejora
de procesos. Roger Pressman ha escrito varios artculos y libros sobre
temas tcnicos y de gestin. Una seleccin:

1977. de control numrico y la fabricacin asistida por ordenador

1982. Ingeniera de software: el enfoque de un profesional

(primera edicin)

1988. Ingeniera de Software: una gua para principiantes.

1991. descarga de software: el peligro y la oportunidad

2009.

1988. Hacer la ingeniera de software suceder: una gua para la

institucin de la tecnologa.

2005. Ingeniera del software: el enfoque de un profesional (sexta

edicin)
Web de ingeniera: el enfoque de un profesional.

METODOLOGA DE ROGER PRESSMAN

De acuerdo con Roger Pressman, las etapas metodolgicas a llevar a
cabo para el desarrollo de Sistemas de Informacin, se establecen de la
siguiente manera:
Etapas o Fases:

1. Anlisis
2. Diseo
3. Codificacin
4. Prueba
5. Mantenimiento

A continuacin la descripcin de estas actividades:

Etapa I: Anlisis de los requisitos del software:

El proceso de reunin de requisitos se intensifica y se centra
especialmente en el software. Dentro del proceso de anlisis, es
fundamental que a travs de una coleccin de requerimientos
funcionales y no funcionales, el desarrollador o desarrolladores del
software comprendan completamente la naturaleza de los programas
que deben construirse para desarrollar la aplicacin, la funcin
requerida, comportamiento, rendimiento e interconexin. [PRR98]. Es de
suma importancia que antes de empezar a codificar los programas, se
tenga una completa y plena comprensin de los requisitos del software.
Pressman establece que la tarea del anlisis de requisitos es un
proceso de descubrimiento, refinamiento, modelado y especificacin. Se
refina en detalle el mbito del software, y se crean modelos de los
requisitos de datos, flujo de informacin y control, y del comportamiento
operativo. Se analizan soluciones alternativas y se asignan a diferentes
elementos del software. El anlisis de requisitos permite al desarrollador
o desarrolladores especificar la funcin y el rendimiento del software,
indica la interfaz del software con otros elementos del sistema y
establece las restricciones que debe cumplir el software.
El anlisis de requisitos del software puede dividirse en cinco
reas de esfuerzo, que son:
1. Reconocimiento del problema. Reconocer los elementos bsicos
del problema tal y como los perciben los usuarios finales.
2. Evaluacin y sntesis. Definir todos los objetos de datos

observables externamente, evaluar el flujo y contenido de la

informacin, definir y elaborar todas las funciones del software, entender
el comportamiento del software en el contexto de acontecimientos que
afectan al sistema.
3. Modelado. Crear modelos del sistema con el fin de entender mejor el
flujo de datos y control, el tratamiento funcional y el comportamiento
operativo y el contenido de la informacin.
4. Especificacin. Realizar la especificacin formal del software
5. Revisin. Un ltimo chequeo general de todo el proceso.
Etapa II: Diseo:
Segn Pressman, el diseo del software es realmente un proceso de
muchos pasos pero que se clasifican dentro de uno mismo. En general,
la actividad del diseo se refiere al establecimiento de las estructuras de
datos, la arquitectura general del software, representaciones de interfaz
y algoritmos. El proceso de diseo traduce requisitos en una
representacin de software [PRR98].
El diseo es el primer paso en la fase de desarrollo de cualquier
producto o sistema de ingeniera. De acuerdo con Pressman, el objetivo
del diseo es producir un modelo o representacin de una entidad que
se va a construir posteriormente [PRR98].
El diseo, es la primera de las tres actividades tcnicas que implica un
proceso de ingeniera de software; estas etapas son diseo, codificacin
y pruebas. Generalmente la fase de diseo produce un diseo de datos,
un diseo arquitectnico, un diseo de interfaz, y un diseo
procedimental [PRR98].
El diseo de datos esencialmente se encarga de transformar el modelo
de dominio de la informacin creado durante el anlisis [PRR98].En el
diseo arquitectnico se definen las relaciones entre los principales
elementos estructurales del programa [PRR98]. Para una herramienta de
software basada en el desarrollo e implementacin de ambientes
virtuales ste es un aspecto fundamental dado que en esta
representacin del diseo se establece la estructura modular del
software que se desarrolla.
El diseo de interfaz describe cmo se comunica el software consigo
mismo, con los sistemas que operan con l, y con los operadores que lo
emplean [PRR98].
Etapa III: Generacin de Cdigo:
Esta actividad consiste en traducir el diseo, en una forma legible por la

mquina. La generacin de cdigo se refiere tanto a la parte de

generacin de los ambientes virtuales, como a la parte en la cul se
aadir comportamiento a estos ambientes. Por ejemplo, el lenguaje de
programacin VRML 2.0 es un lenguaje de modelado en 3D en el cul se
dibuja por medio de generar cdigo de programacin de formato y
marcado para especificar las caractersticas del objeto u objetos que se
van agregando a un mundo o entorno virtual. El comportamiento de las
escenas virtuales es decir, su funcionalidad, se puede construir a travs
de algn otro lenguaje de programacin, como clases Java o scripts
especificados en JavaScript. Todas estas actividades implican generar
cdigo.

Etapa IV: Pruebas:

Una vez que se ha generado cdigo, comienzan las pruebas del software
o sistema que se ha desarrollado. De acuerdo con Pressman, el proceso
de pruebas se centra en los procesos lgicos internos del software,
asegurando que todas las sentencias se han comprobado, y en los
procesos externos funcionales, es decir, la realizacin de las prueba para
la deteccin de errores [PRR98]. En el caso de una herramienta de
software, es necesario tener etapas de pruebas tanto para la parte
funcional del software, como para la parte aplicativa del mismo.
Se requiere poder probar el software con aplicaciones reales que puedan
evaluar el comportamiento del software, con el fin de proporcionar
retroalimentacin a los desarrolladores. Es sumamente importante que
durante el proceso de desarrollo no se pierda el contacto con los
interesados o solicitantes del desarrollo de software, de esta manera los
objetivos de proyecto se mantendrn vigentes y se tendr una idea clara
de los aspectos que tienen que probarse durante el periodo de pruebas.

Etapa V: Mantenimiento.
El software indudablemente sufrir cambios, y habr que hacer algunas
modificaciones a su funcionalidad. Es de suma importancia que el
software de calidad pueda adaptarse con fines de acoplarse a los
cambios de su entorno externo [PRR98]. Por medio de la documentacin
apropiada y atinada del software se pueden presentar las vas para el
mantenimiento y modificaciones al mismo.

ELEMENTOS IMPORTANTES

Metodologa, considera a lo menos cuatro elementos importantes:

1.- Principio Rector:
Tambin denominado filosofa de la metodologa, es la norma o idea
fundamental que rige el pensamiento o la conducta, y orienta el anlisis,
diseo y desarrollo del software. Es el Principio, el que ordena y
estructura las herramientas que son aplicables en la metodologa, as
como los Procedimientos con los que se aplica. Tradicionalmente, se
apellida a cada metodologa en funcin del principio que la rige:

Metodologa estructurada se fundamenta en que lo ms

importante de un sistema de informacin, son las estructuras que
lo componen y que, por lo tanto, el anlisis se debe centrar en
ellas, descomponindolas en nuevas subestructuras hasta tener
elementos tan simples, que puedan ser resueltos en forma
sencilla.

Metodologa orientada a objetos indica que el principio rector es

la orientacin a objetos, es decir el anlisis de todos los
componentes del sistema como un conjunto de objetos que
poseen propiedades y que, a travs de mensajes, se
interrelacionan entre s.

2.- Herramientas:
son definiciones de mecanismos manuales, semiautomticos o
automticos que permiten analizar, disear o construir el software. Las
herramientas quedan estrechamente ligadas al principio rector de la
metodologa y es muy poco probable que una misma herramienta sea

utilizable en ms de una metodologa . Una herramienta debe tener un

objetivo especfico y un mtodo de aplicacin. Por lo general, se ha
demostrado que las herramientas grficas (que usan imgenes) son ms
fciles de usar y entender que las herramientas que slo se sustentan
en textos escritos. Son ejemplos de herramientas: los DFD, MER,
Lenguaje Estructurado, Diagramas de Componentes, Diagramas de
Herencia, etc.
3.- Procedimientos:
Se refiere al modo de hacer, con orden, las cosas; es decir, como poner
en prctica las herramientas. Los procedimientos corresponden a la
definicin que permite unir y ordenar los resultados de cada herramienta
y facilitan el desarrollo racional y oportuno de software. Definen la
secuencia en la que se aplican las herramientas, la entrega de los
resultados de ellas, los controles que ayudan a asegurar la calidad.
Tambin coordinan y controlan los cambios y entregan las directrices
que ayudan a los administradores a evaluar el progreso del proyecto.
4.- Modelos:
El modelo define las etapas a realizar para alcanzar la solucin al
problema planteado. Los Modelos, se refieren a la forma de organizar los
Procedimientos, de manera de obtener resultados de calidad en el
menor tiempo posible. A diferencia de las Herramientas y los
Procedimientos, los modelos son relativamente independientes del
principio, pudiendo aplicarse sin grandes dificultades, cualquier modelo
a cualquier metodologa. Pese a lo anterior, el modelo debe quedar
definido claramente antes de iniciar el desarrollo del software. Ejemplos
de modelos son: Cascada, Prototipos, Espiral, T4G, RAD:
1. Cascada: Tambin denominado clsico . Bajo este modelo, los
procedimientos de la metodologa se ordenan en pasos o etapas,
las cuales debern ser seguidas bajo un enfoque secuencial de
anlisis, diseo y desarrollo. Creado a partir del modelo
convencional de lnea de produccin de la ingeniera clsica,
este modelo es el ms aplicado en el desarrollo de Software.
2. Prototipos : Los prototipos son modelos (no necesariamente
productos de software) que permiten estudiar y probar aspectos
especficos del producto final (en este caso el producto de
software). Bajo este modelo, se planifica la aplicacin de las
diferentes herramientas, para producir elementos de pruebas
especficas (interfaz de usuario, mantenedores, procesos) que
debern ser presentados al usuario y confirmados por ste.
Alternativamente, se ha denominado de esta forma, al resultado
del diseo rpido de productos de software que permitan

comprender de mejor manera los requerimientos del usuario. Sin

embargo, para prevenir confusiones, se sugiere que para esos
casos, se usen las denominaciones siguientes, segn corresponda.
3. Espiral: El modelo espiral, pretende optimizar los tiempos y
reducir la incertidumbre del proyecto, as, la idea es partir
produciendo una pequea parte del sistema (pero completamente
funcional) y una vez completada, se procede a crear una segunda
parte, acoplada a la primera, de manera de que en cada iteracin,
se obtiene una versin aumentada del sistema. El proceso
concluye cuando se considera que el sistema ha alcanzado un
nivel de maduracin tal, que permite que el trabajo para el que fue
creado, sea realizado sin mayores inconvenientes.
4. T4G o RAD(D): T4G es la sigla de Tcnicas de 4 Generacin y
RAD(D) es la sigla de Rapid Application Development (and
Deploy) o Desarrollo (y Distribucin) rpido de aplicaciones.
Como modelo, se basa en la existencia de herramientas de
software que se caracterizan como T4G y RAD(D), las cuales
permiten que el analista diseador de un sistema, realice un
mnimo anlisis y diseo, lo traduzca rpidamente en aplicacin y
se lo presente al usuario para su estudio y posterior aprobacin o
indicaciones para modificacin.

Actualmente, este es, con una alta probabilidad, el modelo ms utilizado

por los desarrolladores de software; sin embargo, y probablemente en la
misma tasa de ocurrencia, es llamado modelo prototipo.

MODELO DE PROTOTIPOS:
Este modelo comienza con la recoleccin de requisitos, el desarrollador y

el cliente definen los objetivos globales para el software, originndose

un diseo rpido que se centra en una representacin de esos aspectos
del software que sean visibles para el usuario/cliente. De este diseo
surge la construccin de un prototipo y este es evaluado por el
cliente/usuario. La interaccin ocurre cuando el prototipo satisface las
necesidades del cliente.

Las etapas del modelo son:

- Investigacin preliminar.- Colecta y refinamiento de los requerimientos
y proyecto rpido:- Anlisis y especificacin del prototipo.- Diseo y
construccin del prototipo.- Evaluacin del prototipo por el cliente.Renacimiento del prototipo.- Diseo tcnico.- Programacin y test.- Operacin y mantenimiento.
VENTAJAS: No modifica el flujo del ciclo de vida. Reduce el riesgo
de construir productos que no satisfagan las necesidades de los
usuarios. Reduce costos y aumenta la probabilidad de xito. Exige
disponer de las herramientas adecuadas. No presenta calidad ni
robustez. Una vez identificados todos los requisitos mediante el
prototipo, se construye el producto de ingeniera.
DESVENTAJASA los usuarios les gusta el sistema real y a los
desarrolladores les gusta construir algo de inmediato. Sin embargo, la
construccin de prototipos se torna problemtica por las siguientes
razones: El cliente ve funcionando lo que para el es la primera versin
del prototipo que ha sido construido con chicle y cable para embalaje,
y puede decepcionarse al indicarle que el sistema aun no ha sido
construido. El desarrollador puede caer en la tentacin de aumentar el
prototipo para construir el sistema final sin tener en cuenta los
obligaciones de calidad y de mantenimiento que tiene con el cliente.
Para construir un prototipo del software se aplican los siguientes
pasos:

PASO 1. Evaluar la peticin del software y determinar si el programa a

desarrollar es un buen candidato para construir un prototipo.Debido a
que el cliente debe interaccionar con el prototipo en los ltimos pasos,
es esencial que: 1) el cliente participe en la evaluacin y refinamiento
del prototipo, y 2) el cliente sea capaz de tomar decisiones de
requerimientos de una forma oportuna. Finalmente, la naturaleza del
proyecto de desarrollo tendr una fuerte influencia en la eficacia del
prototipo.
PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla
una representacin abreviada de los requerimientos.Antes de que pueda
comenzar la construccin de un prototipo, el analista debe representar
los dominios funcionales y de informacin del programa y desarrollar un
mtodo razonable de particin. La aplicacin de estos principios de
anlisis fundamentales, pueden realizarse mediante los mtodos de
anlisis de requerimientos.
PASO 3. Despus de que se haya revisado la representacin de los
requerimientos, se crea un conjunto de especificaciones de diseo
abreviadas para el prototipo.El diseo debe ocurrir antes de que
comience la construccin del prototipo. Sin embargo, el diseo de un
prototipo se enfoca normalmente hacia la arquitectura a nivel superior y
a los aspectos de diseo de datos, en vez de hacia el diseo
procedimental detallado.
PASO 4. El software del prototipo se crea, prueba y refinaIdealmente,
los bloques de construccin de software preexisten se utilizan para crear
el prototipo de una forma rpida. Desafortunadamente, tales bloques
construidos raramente existen.Incluso si la implementacin de un
prototipo que funcione es impracticable, es escenario de construccin de
prototipos puede aun aplicarse. Para las aplicaciones interactivas con el
hombre, es posible frecuentemente crear un prototipo en papel que
describa la interaccin hombre-maquina usando una serie de hojas de
historia.
PASO 5. Una vez que el prototipo ha sido probado, se presenta al
cliente, el cual "conduce la prueba" de la aplicacin y sugiere
modificaciones.Este paso es el ncleo del mtodo de construccin de
prototipo. Es aqu donde el cliente puede examinar una representacin
implementada de los requerimientos del programa, sugerir
modificaciones que harn al programa cumplir mejor las necesidades
reales.
PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los
requerimientos estn formalizados o hasta que el prototipo haya
evolucionado hacia un sistema de produccin.