República Bolivariana De Venezuela

Ministerio Del Poder Popular Para La Educación Universitaria

Universidad Politécnica Territorial De Oeste De Sucre
"Clodosbaldo Russian"
Sede Cariaco - Municipio Ribero
Estado Sucre

Metodología En Espiral

Profesor: Raimary Cova Bachilleres C.I

Rodríguez Sara 26.421.909
Jiménez Yoleidy 17.779.616
Josué vera 22.920.951
Trayecto II - Trimestre I
PNF en Informática

Cariaco, 08 Junio de 2017

ROGER PRESSMAN

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

presidente de RS Pressman and Associates Inc., una firma consultora especialista en métodos
y entrenamiento en ingeniería de software. Él recibió una encefalopatía espongiforme bovina
de la Universidad de Connecticut, una maestría de la Universidad de Bridgeport y un
doctorado de la Universidad de Connecticut. Tiene más de 30 años de experiencia trabajó
como ingeniero de software, un gerente, un profesor, un autor y un consultor, centrándose en
cuestiones de ingeniería de software. Él ha estado en el Consejo de Redacción de IEEE
Software y TI El cortador Diario. Es miembro del IEEE y Tau Beta Pi.

Pressman ha diseñado y desarrollado productos que se utilizan en todo el mundo para la

formación de ingeniería de software y mejora de procesos.

Roger Pressman ha escrito varios artículos y libros sobre temas técnicos y de gestión. Una
selección:

1977. De control numérico y la fabricación asistida por ordenador

1982. Ingeniería de software: el enfoque de un profesional (primera edición)

1988. Hacer la ingeniería de software suceder: una guía para la institución de la tecnología.

1988. Ingeniería de Software: una guía para principiantes.

1991. descarga de software: el peligro y la oportunidad

2005. Ingeniería del software: el enfoque de un profesional (sexta edición)

2009. Web de ingeniería: el enfoque de un profesional.

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:

Análisis

Diseño

Codificación

Prueba

Mantenimiento

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 cual 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

Esta 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:

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.

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.
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.

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”.

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez
por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de software. Las
actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración
representa un conjunto de actividades.

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”.
MODELO DE PROTOTIPOS:

Este modelo comienza con la recolección de requisitos, el desarrollador y el cliente definen

los objetivos globales para el software, originándose un diseño rápido que se centra en una
representación de esos aspectos del software que sean visibles para el usuario/cliente. De este
diseño surge la construcción de un prototipo y este es evaluado por el cliente/usuario. La
interacción ocurre cuando el prototipo satisface las necesidades del cliente.

Las etapas del modelo son:

1. Investigación preliminar.
 2. Colecta y refinamiento de los requerimientos y proyecto rápido.
3. Análisis y especificación del prototipo.
4. Diseño y construcción del prototipo.
5. Evaluación del prototipo por el cliente.
6. Renacimiento del prototipo.
7. Diseño técnico.
8. Programación y test.
9. Operación 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 ingeniería.

DESVENTAJAS

A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de
inmediato. Sin embargo, la construcción de prototipos se torna problemática por las
siguientes razones:

1. El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido
construido con “chicle y cable para embalaje”, y puede decepcionarse al indicarle que
el sistema aún no ha sido construido.
2. El desarrollador puede caer en la tentación de aumentar el prototipo para construir el
sistema final sin tener en cuenta las 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 petición 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 evaluación 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 representación

abreviada de los requerimientos.

Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar

los dominios funcionales y de información del programa y desarrollar un método razonable
de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse
mediante los métodos de análisis de requerimientos.

PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea

un conjunto de especificaciones de diseño abreviadas para el prototipo.

El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el
diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los
aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado.

PASO 4. El software del prototipo se crea, prueba y refina.

Idealmente, los bloques de construcción de software preexisten se utilizan para crear el

prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente
existen.

Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de

construcción de prototipos puede aún aplicarse. Para las aplicaciones interactivas con el
hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción
hombre-máquina 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 aplicación y sugiere modificaciones.

Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente
puede examinar una representación implementada de los requerimientos del programa,
sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.

PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén
formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción.

Modelo Espiral

El modelo en espiral: propuesto originalmente por Boehm, es un modelo de proceso de

software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los
aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial
para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el
software se desarrolla en una serie de versiones incrementales. Durante las primeras
iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las
últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

El modelo en espiral se divide en un número de actividades de marco de trabajo, también

llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
1) Comunicación con el cliente: Las tareas requeridas para establecer comunicación entre
el desarrollador y el cliente.
2) Planificación: Las tareas requeridas para definir recursos, el tiempo y otra información
relacionadas con el proyecto.
3) Análisis de riesgos: Las tareas requeridas para evaluar riesgos técnicos y de gestión.

4) Ingeniería: Las tareas requeridas para construir una o más representaciones de la

aplicación.

5) Construcción y acción: Las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario (por ejemplo: documentación y práctica).

6) Evaluación del cliente: Las tareas requeridas para obtener la reacción del cliente según
la evaluación de las representaciones del software creadas durante la etapa de ingeniería
e implementada durante la etapa de instalación.

Cada una de las regiones está compuesta por un conjunto de tareas del trabajo, llamado
conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse.
Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo. Para
proyectos mayores y más críticos cada región de tareas contiene tareas de trabajo que se
definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las
actividades de protección (por ejemplo: gestión de configuración del software y garantía de
calidad del software).

Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor
de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer
circuito de la espiral puede producir el desarrollo de una especificación de productos; los
pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y
progresivamente versiones más sofisticadas del software. Cada paso por la región de
planificación produce ajustes en el plan del proyecto.

El coste y la planificación se ajustan con la realimentación ante la evaluación del cliente.

Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para
completar el software.

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran

escala. Como el software evoluciona, a medida que progresa el proceso el desarrollador y el
cliente comprende y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.

El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las
etapas del proyecto, y, si se aplica adecuadamente, debe reducir los riesgos antes de que se
conviertan en problemáticos. Pero al igual que otros paradigmas, el modelo en espiral no es
la panacea. Puede resultar difícil convencer a grandes clientes (particularmente en situaciones
bajo contrato) de que el enfoque evolutivo es controlable.

Requiere una considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad
para el éxito. Si un riesgo importante no es descubierto y gestionado, indudablemente
surgirán problemas. Finalmente, el modelo no se ha utilizado tanto como los paradigmas
lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos
años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante
paradigma.
 Referencias Bibliográficas

Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.

Boehm, B. W., A Spiral Model of Software Development and Enhancement, IEEE

Computer, 1988.

https://sisteminformacii.wikispaces.com/MODELO+DE+PROTOTIPOS

https://sisteminformacii.wikispaces.com/ are licensed under a Creative Commons Attribution

Share-Alike 3.0 License