Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Metodología de Roger Pressman

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 7

METODOLOGÍA DE ROGER PRESSMAN

De acuerdo con Roger Pressman, las etapas metodológicas a llevar a cabo


para el desarrollo de Sistemas de Información, se establecen de la siguiente
manera:

Etapas o Fases:

1. Análisis

2. Diseño

3. Codificación

4. Prueba

5. Mantenimiento

A continuación la descripción de estas actividades:

Etapa I: Análisis de los requisitos del software:

El proceso de reunión de requisitos se intensifica y se centra especialmente en


el software. Dentro del proceso de análisis, es fundamental que a través de una
colección 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 aplicación, la función
requerida, comportamiento, rendimiento e interconexión. [PRR98]. Es de suma
importancia que antes de empezar a codificar los programas, se tenga una
completa y plena comprensión de los requisitos del software.
Pressman establece que la tarea del análisis de requisitos es un proceso de
descubrimiento, refinamiento, modelado y especificación. Se refina en detalle el
ámbito del software, y se crean modelos de los requisitos de datos, flujo de
información y control, y del comportamiento operativo. Se analizan soluciones
alternativas y se asignan a diferentes elementos del software. El análisis de
requisitos permite al desarrollador o desarrolladores especificar la función 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 análisis de requisitos del software puede dividirse en cinco áreas de


esfuerzo, que son:

1. Reconocimiento del problema. Reconocer los elementos básicos del


problema tal y como los perciben los usuarios finales.
2. Evaluación y síntesis. Definir todos los objetos de datos observables
externamente, evaluar el flujo y contenido de la información, 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 información.
4. Especificación. Realizar la especificación formal del software
5. Revisión. Un último chequeo general de todo el proceso.

Etapa II: Diseño:

Según Pressman, el diseño del software es realmente un proceso de muchos


pasos pero que se clasifican dentro de uno mismo. En general, la actividad del
diseño se refiere al establecimiento de las estructuras de datos, la arquitectura
general del software, representaciones de interfaz y algoritmos. El proceso de
diseño traduce requisitos en una representación de software [PRR98].

El diseño es el primer paso en la fase de desarrollo de cualquier producto o


sistema de ingeniería. De acuerdo con Pressman, el objetivo del diseño es
producir un modelo o representación de una entidad que se va a construir
posteriormente [PRR98].

El diseño, es la primera de las tres actividades técnicas que implica un proceso


de ingeniería de software; estas etapas son diseño, codificación y pruebas.
Generalmente la fase de diseño produce un diseño de datos, un diseño
arquitectónico, un diseño de interfaz, y un diseño procedimental [PRR98].
El diseño de datos esencialmente se encarga de transformar el modelo de
dominio de la información creado durante el análisis [PRR98].En el diseño
arquitectónico se definen las relaciones entre los principales elementos
estructurales del programa [PRR98]. Para una herramienta de software basada
en el desarrollo e implementación de ambientes virtuales éste es un aspecto
fundamental dado que en esta representación del diseño se establece la
estructura modular del software que se desarrolla.
El diseño de interfaz describe cómo se comunica el software consigo mismo,
con los sistemas que operan con él, y con los operadores que lo emplean
[PRR98].

Etapa III: Generación de Código:

Esta actividad consiste en traducir el diseño, en una forma legible por la


máquina. La generación de código se refiere tanto a la parte de generación de
los ambientes virtuales, como a la parte en la cuál se añadirá comportamiento a
estos ambientes. Por ejemplo, el lenguaje de programación VRML 2.0 es un
lenguaje de modelado en 3D en el cuál se dibuja por medio de generar código
de programación de formato y marcado para especificar las características 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 través de algún otro lenguaje de programación, como clases Java o
scripts especificados en JavaScript. Todas estas actividades implican generar
código.

Etapa IV: Pruebas:

Una vez que se ha generado código, comienzan las pruebas del software o
sistema que se ha desarrollado. De acuerdo con Pressman, el proceso de
pruebas se centra en los procesos lógicos internos del software, asegurando
que todas las sentencias se han comprobado, y en los procesos externos
funcionales, es decir, la realización de las prueba para la detección 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
retroalimentación 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 mantendrán 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 documentación apropiada y atinada del
software se pueden presentar las vías para el mantenimiento y modificaciones
al mismo.

 ELEMENTOS IMPORTANTES

Metodología, considera a lo menos cuatro elementos importantes:

1.- Principio Rector: 


También denominado “filosofía de la metodología”, es la norma o idea
fundamental que rige el pensamiento o la conducta, y orienta el análisis, diseño
y desarrollo del software. Es el Principio, el que ordena y estructura las
herramientas que son aplicables en la metodología, así como los
Procedimientos con los que se aplica. Tradicionalmente, se apellida a cada
metodología en función del principio que la rige:

 “Metodología estructurada” se fundamenta en que lo más importante de


un sistema de información, son las estructuras que lo componen y que,
por lo tanto, el análisis se debe centrar en ellas, descomponiéndolas en
nuevas subestructuras hasta tener elementos tan simples, que puedan
ser resueltos en forma sencilla.
 “Metodología orientada a objetos” indica que el principio rector es la
orientación a objetos, es decir el análisis de todos los componentes del
sistema como un conjunto de objetos que poseen propiedades y que, a
través de mensajes, se interrelacionan entre sí.

2.- Herramientas: 
son definiciones de mecanismos manuales, semiautomáticos o automáticos
que permiten analizar, diseñar o construir el software. Las herramientas quedan
estrechamente ligadas al principio rector de la metodología y es muy poco
probable que una misma herramienta sea utilizable en más de una metodología
. Una herramienta debe tener un objetivo específico y un método de aplicación.
Por lo general, se ha demostrado que las herramientas gráficas (que usan
imágenes) son más fáciles de usar y entender que las herramientas que sólo
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
práctica las herramientas. Los procedimientos corresponden a la definición 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. También 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 solución 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 metodología. 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: También denominado “clásico” . Bajo este modelo, los


procedimientos de la metodología se ordenan en pasos o etapas, las
cuales deberán ser seguidas bajo un enfoque secuencial de análisis,
diseño y desarrollo. Creado a partir del modelo convencional de “línea
de producción” de la ingeniería clásica, este modelo es el más aplicado
en el desarrollo de Software.

2. Prototipos : Los prototipos son modelos (no necesariamente productos


de software) que permiten estudiar y probar aspectos específicos del
producto final (en este caso el producto de software). Bajo este modelo,
se planifica la aplicación de las diferentes herramientas, para producir
elementos de pruebas específicas (interfaz de usuario, mantenedores,
procesos) que deberán ser presentados al usuario y confirmados por
éste. Alternativamente, se ha denominado de esta forma, al resultado del
diseño rápido 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, según corresponda.

3. Espiral: El modelo espiral, pretende optimizar los tiempos y reducir la


incertidumbre del proyecto, así, la idea es partir produciendo una
pequeña 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 iteración, se obtiene una versión
aumentada del sistema. El proceso concluye cuando se considera que el
sistema ha alcanzado un nivel de maduración 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 “Técnicas de 4ª Generación” y


RAD(D) es la sigla de “Rapid Application Development (and Deploy)” o
“Desarrollo (y Distribución) rápido 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 diseñador
de un sistema, realice un mínimo análisis y diseño, lo traduzca
rápidamente en aplicación y se lo presente al usuario para su estudio y
posterior aprobación o indicaciones para modificación.

Actualmente, este es, con una alta probabilidad, el modelo más utilizado por los
desarrolladores de software; sin embargo, y probablemente en la misma tasa
de ocurrencia, es llamado “modelo prototipo”.
EXPERIENCIA EMPÍRICA

Experiencia que se adquiere a través de la labor sin utilizar conocimientos


teóricos o técnicos.

También podría gustarte