Formato Clase MDS Clase N1 PRO204-M1

TALLER DE METODOLOGÍAS
DE DESARROLLO DE
SOFTWARE
Clase N° 1
03 – Noviembre – 2020
PRO204-PEV-M1
CONDICIONES FAVORABLES PARA LA CLASE
Mantén todos tus

sentidos activos
Práctica la puntualidad
Mantén tus dispositivos

electrónicos en silencio
Respeta el turno de
participación
PRESENTACIÓN DE LA CLASE
Aprendizaje Esperado: Clasifican tipos de metodologías de desarrollo de software tradicionales,
considerando evolución de método de creación de sistemas informáticos.
Criterios de Evaluación: Preguntas y participación en clases.
Contenidos: -Fases en la creación de software

-Metodologías de desarrollo en cascada
-Metodologías de desarrollo de prototipo
MOMENTO PARA RECORDAR
Desarrollo
Software
MOMENTO PARA RECORDAR
Metodología
Proyectos
MOMENTO PARA CONOCER
FASES EN LA CREACIÓN DE SOFTWARE
Conceptos fundamentales
¿Qué se entiende por Software?
“Conjunto de programas, instrucciones y reglas informáticas para

ejecutar ciertas tareas en una computadora.”
“Es el conjunto de los programas de cómputo, procedimientos, reglas,

documentación y datos asociados que forman parte de las
operaciones de un sistema de computación.”
Como vemos en esta definición mucho más exacta, se incluye la

documentación y los datos como parte de lo que se conoce como
Software.
¿Qué se entiende por Ingeniería del Software?
“Ingeniería del Software es la aplicación práctica del conocimiento

científico en el diseño y construcción de programas de
computadora y la documentación asociada requerida para
desarrollar, operar y mantenerlos. Se conoce también como
desarrollo de software o producción de software“
En esta definición del proceso de desarrollo Software, se introduce

como parte inherente del producto a obtener, la perspectiva de las
necesidades de usuario a las que debe dar respuesta:
“Aquellos en los que las necesidades del usuario se traducen en

requerimientos, estos se transforman en diseño y este a su vez se
implementa en código que es probado, documentado y certificado
para su uso”
En la siguiente, se introducen los conceptos de rentabilidad y

fiabilidad y la operatividad en entornos reales:
“La Ingeniería del Software trata del establecimiento de los

principios y métodos de la ingeniería a fin de obtener
software de modo rentable que sea fiable y trabaje en
máquinas reales.”
Y según otra de las definiciones que aporta la IEEE, se

introduce el concepto de cuantificación del proceso:
 La aplicación de un enfoque sistemático, disciplinado y

cuantificable al desarrollo, operación y mantenimiento del
software; es decir, la aplicación de ingeniería al software.
Como compendio de los conceptos barajados en las

definiciones expuestas se propone la siguiente
definición de Ingeniería del Software:
“La aplicación práctica, sistemática, disciplinada y

cuantificable del conocimiento científico para realizar
el análisis de las necesidades del usuario y obtener el
software y la documentación asociada requerida para
su desarrollo, operación y mantenimiento de manera
rentable, fiable, certificada y que opere en máquinas
reales”.
Problemática de la Ingeniería del Software
¿Qué complejidad inherente tiene el proceso de desarrollo de
Software?
El proceso de desarrollo es intensamente intelectual y se ve

afectado por la creatividad y juicio de las personas involucradas
en el mismo. Aunque un proyecto de desarrollo de software es
equiparable en muchos aspectos a cualquier otro proyecto de
ingeniería, en el desarrollo de software hay una serie de
desafíos adicionales relativos a la naturaleza del producto a
obtener, como son la intangibilidad o la fiabilidad del mismo:
Intangibilidad
Hablamos de un producto intangible y habitualmente complejo,

dado que su cometido es dar respuesta a la abstracción de un
problema planteado por personas que normalmente
desconocen esta disciplina.
Por esta cuestión, definir con exactitud los requisitos a cubrir y

consolidarlos tempranamente se complica con frecuencia,
haciendo inevitable el cambio, durante el desarrollo o una vez
acabado el mismo.
Fiabilidad
Un producto software en sí es complejo siendo inviable conseguir el
100% de fiabilidad en un programa por muy reducida que sea su
funcionalidad.
Esto ocurre por la elevada combinatoria asociada a los distintos

factores que intervienen en la ejecución del mismo y que impiden
una verificación de las todas posibles situaciones que se puedan
presentar, son ejemplo de estos factores:
 Datos introducidos por el usuario

 Datos almacenados en el sistema
 Interacción con el software
 base o sistema operativo
 Interacción o el hardware del sistema sobre el que se ejecuta
Interacción con otras aplicaciones
 Otros.
Por otra parte, el ámbito de esta disciplina es tan amplio que

se abordan problemas tan dispares como pueden ser el
diseño de una simple Web de promoción de una empresa,
una aplicación que de el soporte al trabajo diario de gestión
de una organización, o el desarrollo del software de control
de un misil en tiempo real.
Por este motivo, las prácticas que aplican en un determinado

ámbito no tienen por qué ser de aplicación en el resto, sí bien
hay una serie de principios comunes que si pueden ser
adaptados a prácticas concretas para cada situación.
Este concepto es tratado por Pressman y que lo define como

“Marco común del Proceso” y que lo ilustra con la siguiente
figura
Se definen un conjunto de actividades aplicables a

cualquier proyecto, una serie de conjuntos de
tareas que permitirán la adaptación de las
actividades a cada proyecto en particular y
requisitos del equipo de proyecto y un conjunto de
actividades de protección, independientes de
cualquier actividad del marco de trabajo, presentes
durante todo el proceso y destinadas a cuestiones
como la garantía de calidad, gestión de la
configuración, gestión de riesgos, etc.
De una forma más concreta, las actividades del

marco de trabajo se pueden asimilar a tres fases
genéricas:
Definición: destinada identificar qué se pretende obtener.

Establecer cuestiones como qué información debe procesar el
sistema, qué funcionalidad implementar, cómo comportarse, etc.
Durante esta fase tendrán lugar tareas como la ingeniería de
sistemas o de información, planificación de proyecto y análisis de
requisitos
Desarrollo: en la que efectivamente se da solución a las

necesidades definidas en la fase anterior, y su cometido principal
es la construcción del producto final. En esta fase tienen lugar
tareas como el diseño, la codificación y pruebas del software.
Mantenimiento: que se ocupa del cambio del producto obtenido

en la fase de desarrollo.
Este cambio puede venir motivado por distintos aspectos en los que
destacan:
 Correcciones de defectos localizados tras el desarrollo, cuestión

inevitable, como explicamos con anterioridad. Las
modificaciones realizadas para dar solución a estos cambios se
conocen como mantenimiento correctivo.
 Adaptaciones del software ante el cambio del entorno original
para el que fue desarrollado, cambios del hardware, del
software base, etc. Realizadas por el mantenimiento adaptativo.
 Mejoras que den respuesta a nuevos requisitos del cliente,
cubiertas por el mantenimiento perfectivo.
 Prevención de la degradación que se produce por el cambio. El
mantenimiento preventivo o reingeniería del software se ocupa
de realizar cambios que faciliten la corrección, adaptación y
mejora.
Por último, es destacable la visión genérica y multicapa que

ofrece Pressman como fundamento de la Ingeniería del
Software, donde herramientas, métodos y procesos se apoyan
sobre un enfoque de calidad .
Calidad: indispensable para cualquier disciplina de ingeniería.

Idea reforzada por la tendencia actual de fomento de la cultura
de mejora continua de procesos.
Procesos: definen un marco de trabajo para el conjunto de áreas

clave base del control de la gestión de proyectos y establecen el
contexto de aplicación de los métodos técnicos y otras
cuestiones como el aseguramiento de la calidad y gestión del
cambio.
Métodos: especifican cómo construir técnicamente el Software,

abarcando desde las tareas de especificación de requisitos y el
diseño hasta la construcción, pruebas y mantenimiento.
Herramientas: son aquellas que darán un soporte más o menos

automático a procesos y métodos.
Modelos de proceso
También conocidos como paradigmas, son abstracciones que si

bien no describen detalladamente el proceso a seguir para el
desarrollo software, representan diferentes estrategias o
enfoques para abordar este problema:
“Una descripción simplificada de un proceso del software que

presenta una visión de ese proceso. Estos modelos pueden
incluir actividades que son parte de los procesos y productos de
software y las personas involucradas en la ingeniería del
software.”
A continuación se describen los principales modelos de

proceso:
• Lineal secuencial
• Basado en prototipos
• Evolutivo
 Incremental
 En espiral
• Basado en componentes
Lineal secuencial
También llamado ciclo de vida básico, utiliza un

enfoque sistemático y secuencial de las actividades
fundamentales que se mencionaron con anterioridad:
En esta figura, se contempla el concepto de ingeniería

de Sistemas / Información, que ofrece una visión que
pone de manifiesto que el software suele formar parte
de una solución mayor, y que su cometido es dar
respuesta a un subconjunto de los requisitos a cubrir.
El modelo secuencial más conocido es el modelo en cascada,

propuesto por Royce en 1970.
El uso de este modelo es frecuente en proyectos de tamaño

considerable en el que se conocen bien los requisitos a los
que se
debe dar respuesta.
Son desventajas de este modelo:
• La necesidad de conocer los requisitos con exactitud desde

el comienzo del proyecto, cuestión que no es habitual.
• El producto a obtener no se hace visible hasta el final, algo

que provoca que los errores cometidos en la fase de
análisis se propaguen por el resto de fases.
Basado en prototipos
Este modelo facilita la definición de los requisitos,

mediante un diseño rápido centrado en la
representación de los aspectos del software que serán
visibles por el usuario mediante la construcción de un
prototipo.
Una vez realizada la primera versión del prototipo, se

irá refinando y validando hasta lograr la definición
completa del sistema.
La principal desventaja de este modelo es la

percepción de “producto terminado” que puede dar el
prototipo. La clave para evitarla es dejar claro desde el
primer momento cuál es la función del prototipo y sus
limitaciones.
Evolutivo
Surge para dar respuesta a una realidad: la necesidad de

dar respuesta a la necesidad de rápida evolución del
Software.
La experiencia confirma que, con frecuencia, los requisitos

cambian durante el desarrollo, cuestión que se ve
reforzada por la presión sobre tiempos de entrega que
dificultan la finalización de un producto completo y obligan
a introducir versiones parciales, cada vez más completas,
que den cierto grado de solución en un plazo menor.
Incremental
Combina elementos del modelo lineal aplicados repetidas veces

con la filosofía de construcción de prototipos.
A diferencia de la construcción de prototipos, el modelo

incremental se centra en la entrega de un producto operativo
en cada incremento, siendo los primeros incrementos
versiones, si bien incompletas, que proporcionan la
funcionalidad precisada además de una plataforma para la
evaluación.
Este modelo también es útil cuando no se dispone de todos

los recursos para realizar una implementación completa en
una fecha establecida, limitándose la entrega a un primer
incremento ajustado a la capacidad disponible.
En espiral
Combina igualmente la naturaleza iterativa del la

construcción de prototipos con los aspectos sistemáticos
del modelo lineal.
Este modelo es propuesto por Boehm en 1988 e

incorpora los conceptos de análisis de riesgos y
planificación como parte del proceso.
La espiral representa el avance del proyecto y ésta pasa por un

conjunto de regiones que se corresponden con actividades del
marco de trabajo. El número de regiones propuestas por Boehm
originalmente es de 4, aunque en la bibliografía revisada se
distinguen hasta 6.
Una variante de este modelo, el modelo espiral Win-Win, también

propuesto por Boehm en 1998, interesante por introducir el
concepto ganar-ganar como parte del proceso iterativo.
El fundamento de esta variante se basa a que, con frecuencia, es

difícil obtener del cliente los detalles necesarios para continuar el
proceso, lo que se deriva en un proceso de negociación: la
funcionalidad, rendimiento, y otros productos o características del
sistema se sopesan frente al coste y al tiempo.
Modelo Win-WIN
Esta visión introduce un

conjunto de actividades de
negociación al principio de
cada paso alrededor de la
espiral.
Basado en componentes
Modelo evolutivo por naturaleza y que

presenta características comunes con el
modelo en espiral. También conocido como
“Desarrollo basado en la reutilización”, se
apoya precisamente en el ese concepto:
enfatizar la creación de clases y componentes
que encapsulan datos y procedimientos para
tratarlos de modo que se facilite su
reutilización en distintos proyectos.
Este modelo introduce el concepto de “biblioteca de componentes” es un

repositorio de elementos potencialmente reutilizables (clases y componentes).
A comienzo de la etapa de construcción, se distinguen las necesidades únicas del

proyecto de las comunes entre distintos proyectos. Para darle respuesta a estas
últimas se identifican los “componentes candidatos” de formar parte de la
biblioteca.
Si existen los componentes candidatos existen en la biblioteca, se reutilizarán, y

en otro caso, se construirán de tal modo que puedan ser incorporados
posteriormente a la biblioteca.
De esta forma, se compone la primera iteración de la aplicación a construirse,

mediante los componentes de la biblioteca y aquellos componentes únicos del
proyecto (a priori, no reutilizables)
Metodologías
Las metodologías deben dar forma y detalle al proceso de desarrollo software y,

adicionalmente, proporcionar un conjunto de prácticas y técnicas recomendadas,
así como guías de adaptación a los distintos proyectos.
Habitualmente suelen ser combinación de modelos de proceso genéricos.
Para este estudio del arte, utilizaremos la siguiente distinción:

Metodologías tradicionales
Son aquellas caracterizadas por una fuerte

planificación durante todo el proceso de
desarrollo y por realizar una intensa etapa de
análisis y diseño antes de la construcción del
sistema, cuestión por las que también se
conocen con el nombre de “Metodologías
Pesadas”
Cabe realizar la siguiente clasificación en función del tipo de

enfoque que utilizan para realizar las etapas análisis y diseño:
• Estructuradas : Los datos se consideran separadamente de

los procesos que los transforman y el comportamiento del
sistema, tiende a desempeñar un papel secundario en la
etapa de análisis, haciéndose un fuerte uso de la
descomposición funcional. MÉTRICA, MERISE o SSADM son
ejemplos de metodologías estructuradas.
• Orientadas a objetos: Se considera el dominio del

problema como un conjunto de objetos que interactúan
entre sí. OOAD (Booch), OOSE (Jacobson) y OMT
(Rumbaugh), son ejemplos de metodologías con enfoque
orientado a objetos.
MÉTRICA
Es característico de las metodologías tradicionales, en general:
• Prestar especial atención al modelado y mantenimiento de los modelos.

• El énfasis en el control del proceso de desarrollo, metodología, el rigor de
las actividades involucradas, las herramientas y la notación utilizada.
• El énfasis en la especificación detallada de procesos y un elevado número
y especialización de roles.
• Limitar la participación del cliente a reuniones de control, reduciendo de
manera significativa sus aportes.
• Asumir que no se van a presentar cambios una vez comenzado el
proyecto y esperar que la arquitectura se defina tempranamente.
• Documentar de manera rigurosa toda actividad desarrollada en el
proyecto.
• El aumento de los tiempos de espera por parte del usuario para ver los
resultados.
METODOLOGÍA DE DESARROLLO EN CASCADA
El término “waterfall model” hace referencia a un procedimiento

secuencial que permite representar un proyecto en base a unas
fases que se suceden entre sí.
¿Qué es el modelo en cascada?
El desarrollo en cascada (en inglés, waterfall model) es

un procedimiento lineal que se caracteriza por dividir los procesos
de desarrollo en sucesivas fases de proyecto. Al contrario que en
los modelos iterativos, cada una de estas fases se ejecuta tan solo
una vez. Los resultados de cada una de las fases sirven como
hipótesis de partida para la siguiente.
El waterfall model se utiliza, especialmente, en el desarrollo de

software.
El desarrollo del modelo se atribuye al teórico de la informática Winston W.

Royce. Sin embargo, Royce no es el inventor de este modelo. el teórico
formula una reflexión crítica acerca de los procedimientos lineales. A modo
de alternativa, Royce presenta un modelo iterativo incremental en el que cada
una de las fases se basa en la anterior y verifica los resultados de esta,
propone un modelo compuesto por siete fases que se ha de ejecutar en
diversas vueltas (iteraciones):
• Requisitos de sistema
• Requisitos de software
• Análisis
• Diseño
• Implementación
• Prueba
• Servicio
El modelo en cascada se popularizó a través de la norma

estadounidense DoD-STD-2167.
Esta norma se basa en una versión extremadamente

simplificada del procedimiento desarrollado por Royce, que no
fue lo suficientemente analizado por los autores. Tal y como
reconoció con el paso del tiempo David Maibor, uno de sus
autores, el motivo fue la falta de compresión de los modelos
iterativos incrementales.
En la práctica, se aplican diversas versiones del modelo. Los

más habituales son los modelos que dividen los procesos de
desarrollo en cinco fases. En ocasiones, las fases 1, 2 y 3
definidas por Royce se integran en una sola fase de proyecto a
modo de análisis de los requisitos.
1. Análisis: planificación, análisis y especificación de los

requisitos.
2. Diseño: diseño y especificación del sistema.
3. Implementación: programación y pruebas unitarias.
4. Verificación: integración de sistemas, pruebas de sistema
y de integración.
5. Mantenimiento: entrega, mantenimiento y mejora.
La siguiente imagen explica por qué el procedimiento lineal se

denomina metodología en cascada.
Las fases del desarrollo en cascada
En este modelo, las diferentes fases de un proceso de

desarrollo se suceden una detrás de otra como en una
cascada.
Cada una de las fases concluye con un resultado

provisional (hito) como, por ejemplo, un catálogo de
requisitos en forma de pliego de condiciones, la
especificación de una arquitectura de software o una
aplicación a nivel alfa o beta.
Análisis
Todo proyecto de software comienza con una fase de análisis que

incluye un estudio de viabilidad y una definición de los requisitos. En
el estudio de viabilidad se evalúan los costes, la rentabilidad y la
factibilidad del proyecto de software. El estudio de viabilidad da como
resultado un pliego de condiciones (una descripción general de los
requisitos), un plan y una estimación financiera del proyecto, así como
una propuesta para el cliente, si fuera necesario.
A continuación, se realiza una definición detallada de los requisitos,

incluyendo un análisis de la situación de salida y un concepto.
Mientras que los análisis de salida se encargan de describir la
problemática en sí, el concepto ha de definir qué funciones y
características debe ofrecer el producto de software para cumplir con
las correspondientes exigencias
La definición de los requisitos da como resultado un pliego de

condiciones, una descripción detallada de cómo se han de
cumplir los requisitos del proyecto, así como un plan para la
prueba de aceptación, entre otros.
Por último, la primera fase del waterfall modelo incluye

un análisis de la definición de los requisitos en el que los
problemas complejos se dividen en pequeñas tareas
secundarias y se elaboran las correspondientes estrategias de
resolución.
Diseño
La fase de diseño sirve para formular una solución específica

en base a las exigencias, tareas y estrategias definidas en la
fase anterior.
En esta fase, los desarrolladores de software se encargan de

diseñar la arquitectura de software, así como un plan de
diseño detallado del mismo, centrándose en componentes
concretos, como interfaces, entornos de trabajo o
bibliotecas.
La fase de diseño da como resultado un borrador preliminar

con el plan de diseño del software, así como planes de
prueba para los diferentes componentes.
Implementación
La arquitectura de software concebida en la fase de diseño se

ejecuta en la fase de implementación, en la que se incluye
la programación del software, la búsqueda de errores y
las pruebas unitarias. En la fase de implementación, el proyecto
de software se traduce al correspondiente lenguaje de
programación.
Los diversos componentes se desarrollan por separado, se

comprueban a través de las pruebas unitarias y se integran
poco a poco en el producto final.
La fase de implementación da como resultado un producto de

software que se comprueba por primera vez como producto
final en la siguiente fase (prueba alfa).
Prueba
La fase de prueba incluye la integración del software en el

entorno seleccionado. Por norma general, los productos de
software se envían en primer lugar a los usuarios finales
seleccionados en versión beta (pruebas beta).
Las pruebas de aceptación desarrolladas en la fase de

análisis permiten determinar si el software cumple con las
exigencias definidas con anterioridad.
Aquellos productos de software que superan con éxito las

pruebas beta están listos para su lanzamiento.
Servicio
Una vez que la fase de prueba ha concluido con

éxito, se autoriza la aplicación productiva del
software.
La última fase del modelo en cascada incluye

la entrega, el mantenimiento y la mejora del
software.
Pros y contras del modelo en cascada
Esta metodología permite estructurar la organización de forma

clara en aquellos proyectos de desarrollo en los que las diversas fases
de proyecto se diferencian claramente entre sí. Como cada una de las
fases concluye con un hito, el proceso de desarrollo es muy fácil de
comprender.
El punto clave del modelo reside en la documentación de todos y cada

uno de los pasos de proceso. Los conocimientos adquiridos se registran
en pliegos de requisitos o borradores preliminares.
En teoría, el desarrollo en cascada pretende crear los requisitos previos

para una ejecución rápida y rentable de los proyectos a través de una
cuidada planificación previa.
Sin embargo, la utilización del modelo en la práctica es

controvertida. Por una parte, en el desarrollo de software
las fases de proyecto no suelen estar claramente
diferenciadas entre sí.
Es precisamente en los proyectos de software más

complejos donde los desarrolladores se suelen enfrentar al
hecho de que los diversos componentes de una misma
aplicación se encuentran en diferentes fases de desarrollo
al mismo tiempo.
Por otra parte, la secuencia lineal del waterfall model no

suele coincidir con la realidad.
En sentido estricto, el modelo en cascada no prevé la realización de

ajustes a lo largo del proyecto.
Sin embargo, un proyecto de software en el que todos los detalles del

desarrollo se definieran al comienzo, solo podría concluir con éxito si
desde el principio se invirtiera una gran cantidad de tiempo y dinero
en análisis y diseño.
A todo esto, se añade que los proyectos de software de más

envergadura se suelen prolongar durante varios años y, de no
adaptarse a los avances más actuales, obtendrían resultados que ya
estarían obsoletos en el momento de su aplicación.
La metodología en cascada se suele emplear, especialmente, en

aquellos proyectos cuyos requisitos y procesos se pueden describir de
forma precisa durante la fase de planificación, en los que cabe suponer
que las hipótesis no van a sufrir una gran variación durante el
transcurso del proyecto.
Los procedimientos estrictamente lineales se adaptan, así,

especialmente bien a proyectos de software pequeños, sencillos y
claramente estructurados.
A esta misma conclusión llegó Royce en los años 1970. Por este motivo,
la alternativa al procedimiento lineal que propuso, y que más tarde se
conocería como waterfall model, incluía tres ampliaciones principales:
Verificación tras cada fase de proyecto
Según Royce, los resultados de cada una de las fases de proyecto se

deben comparar y verificar inmediatamente con los documentos
elaborados previamente.
Es decir, inmediatamente después de desarrollar un módulo, por

ejemplo, se debería garantizar que este cumple con las exigencias
definidas con anterioridad sin esperar a que concluya el proceso de
desarrollo.
Al menos, dos iteraciones
Según Royce, el modelo se debería ejecutar en, al menos, dos

ocasiones: primero para elaborar un prototipo y, a continuación,
para desarrollar el producto de software en sí.
Pruebas que incluyen al usuario final
La tercera ampliación del modelo en cascada propuesta por Royce

en su ensayo es una medida que, a día de hoy, se ha convertido en
un procedimiento estándar en el desarrollo de productos: la
inclusión del usuario final en el proceso de producción. Royce
propone incluir al usuario en tres momentos diferentes del proceso
de desarrollo de software: durante la planificación del software en
la fase de análisis, entre el diseño del software y su implementación
y en la fase de prueba que precede al lanzamiento del software.
Procedimientos alternativos al modelo en cascada
Debido a la secuencia estrictamente lineal de las fases sucesivas de

proyecto, el modelo en cascada se adaptaría, en el mejor de los casos,
a proyectos de software de poca envergadura. Por el contrario, los
procesos complejos de varios niveles serían difícilmente
representables con este modelo.
Por este motivo, con el paso del tiempo han ido surgiendo enfoques
alternativos, mientras que algunos modelos, como el modelo en
espiral o el modelo en V, se consideran una evolución del waterfall
modelo clásico, algunos métodos, como la programación extrema, el
desarrollo ágil de software o el desarrollo iterativo, se centran en un
enfoque completamente diferente y suelen permitir una adaptación a
los cambios más recientes o a las exigencias más actuales.
METODOLOGÍA EN BASE A PROTOTIPOS
El Modelo de prototipos pertenece a los modelos de desarrollo

evolutivo. El prototipo debe ser construido en poco tiempo,
usando los programas adecuados y no se debe utilizar muchos
recursos.
Durante la década de los 70 se daba respuesta a proyectos

grandes y con requisitos establecidos a la exactitud, pro la
ingeniería de los 80 se relacionó con proyectos de requisitos poco
claros y dinámicos que daban lugar a la creación de prototipos.
El modelo de ciclo de vida de prototipos fue propuesto en 1984.
Un prototipo es un mecanismo para identificar los requisitos del

software
El diseño rápido se centra en una representación de aquellos

aspectos del software que serán visibles para el cliente o el
usuario final. Este diseño conduce a la construcción de un
prototipo.
El prototipo se prueba y modifica cuando es necesario, y los

resultados se anotan en la revisión de los bosquejos y los dibujos
en funcionamiento, se clasifican en:
• Modelo de rendimiento
• Modelo a escala no funcional
• Modelo a escala completa
• Modelo con características esenciales
Los tipos de prototipo son:
• Desechables: sirve para eliminar dudas sobre lo que quiere el

cliente.
• Evolucionario: modelo parcialmente construido que pasa de
ser prototipo a ser el software.
VENTAJAS
No modifica el flujo del ciclo de vida, reduce el riesgo de construir

productos que no satisfagan las necesidades de los usuarios,
reduce costo y aumenta la probabilidad de éxito, exige disponer
de las herramientas adecuadas y ofrece un mejor enfoque
cuando el responsable del desarrollo del software está inseguro
de la eficacia de un algoritmo.
DESVENTAJAS
Debido a que el usuario ve que el prototipo funciona

piensa que este es el producto terminado.
El desarrollador puede caer en la tentación de

ampliar el prototipo para construir el sistema final sin
tener en cuenta los compromisos de calidad y
mantenimiento que tiene con el cliente.
MOMENTO PARA RETROALIMENTAR
MOMENTO PARA APLICAR
CONTROLAR ROBOT EN FORMA INALÁMBRICA
Un empresa que se iniciará en innovación, lo ha contratado para participar en un proyecto

tecnológico, para crear un Sistema informático que permita controlar en forma inalámbrica
desde una Tablet o celular a un robot Bipedo.
El Robot deberá:
• Caminar (avanzar y retroceder)

• Levantar y bajar cada pierna
• Agacharse y levantarse.
MOMENTO PARA APLICAR
CONTROLAR ROBOT EN FORMA INALÁMBRICA
Le solicitan aplicar la metodología cascada para abordar este proyecto y como primera
tarea debe entregar el detalle de actividades que se deberán realizar para cada fase del
proyecto para obtener en un plazo de 2 meses el Robot y Sistema de control inalámbrico
operativo en ambiente productivo para su funcionamiento, incluyendo el término del
proyecto.
Debe enviar al correo del profesor su trabajo en formato PDF bajo con el siguiente nombre
de archivo “Nombre Alumno_Apelledio_PRO204_ACT01_PS.pdf”.
El plazo de estrega es el próximo Lunes .

MUCHAS GRACIAS

Formato Clase MDS Clase N1 PRO204-M1

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Formato Clase MDS Clase N1 PRO204-M1

Загружено:

Авторское право:

Доступные форматы

TALLER DE METODOLOGÍAS

Mantén todos tus

Mantén tus dispositivos

Criterios de Evaluación: Preguntas y participación en clases.

Contenidos: -Fases en la creación de software

“Conjunto de programas, instrucciones y reglas informáticas para

“Es el conjunto de los programas de cómputo, procedimientos, reglas,

Como vemos en esta definición mucho más exacta, se incluye la

“Ingeniería del Software es la aplicación práctica del conocimiento

En esta definición del proceso de desarrollo Software, se introduce

“Aquellos en los que las necesidades del usuario se traducen en

En la siguiente, se introducen los conceptos de rentabilidad y

“La Ingeniería del Software trata del establecimiento de los

Y según otra de las definiciones que aporta la IEEE, se

 La aplicación de un enfoque sistemático, disciplinado y

Como compendio de los conceptos barajados en las

“La aplicación práctica, sistemática, disciplinada y

El proceso de desarrollo es intensamente intelectual y se ve

Hablamos de un producto intangible y habitualmente complejo,

Por esta cuestión, definir con exactitud los requisitos a cubrir y

Esto ocurre por la elevada combinatoria asociada a los distintos

 Datos introducidos por el usuario

Por otra parte, el ámbito de esta disciplina es tan amplio que

Por este motivo, las prácticas que aplican en un determinado

Este concepto es tratado por Pressman y que lo define como

Se definen un conjunto de actividades aplicables a

De una forma más concreta, las actividades del

Definición: destinada identificar qué se pretende obtener.

Desarrollo: en la que efectivamente se da solución a las

Mantenimiento: que se ocupa del cambio del producto obtenido

 Correcciones de defectos localizados tras el desarrollo, cuestión

Por último, es destacable la visión genérica y multicapa que

Calidad: indispensable para cualquier disciplina de ingeniería.

Procesos: definen un marco de trabajo para el conjunto de áreas

Métodos: especifican cómo construir técnicamente el Software,

Herramientas: son aquellas que darán un soporte más o menos

También conocidos como paradigmas, son abstracciones que si

“Una descripción simplificada de un proceso del software que

A continuación se describen los principales modelos de

También llamado ciclo de vida básico, utiliza un

En esta figura, se contempla el concepto de ingeniería

El modelo secuencial más conocido es el modelo en cascada,

El uso de este modelo es frecuente en proyectos de tamaño

Son desventajas de este modelo:

• La necesidad de conocer los requisitos con exactitud desde

• El producto a obtener no se hace visible hasta el final, algo

Este modelo facilita la definición de los requisitos,

Una vez realizada la primera versión del prototipo, se

La principal desventaja de este modelo es la

Surge para dar respuesta a una realidad: la necesidad de

La experiencia confirma que, con frecuencia, los requisitos

Combina elementos del modelo lineal aplicados repetidas veces

A diferencia de la construcción de prototipos, el modelo

Este modelo también es útil cuando no se dispone de todos

Combina igualmente la naturaleza iterativa del la

Este modelo es propuesto por Boehm en 1988 e

La espiral representa el avance del proyecto y ésta pasa por un

Una variante de este modelo, el modelo espiral Win-Win, también

El fundamento de esta variante se basa a que, con frecuencia, es

Esta visión introduce un

Modelo evolutivo por naturaleza y que

Este modelo introduce el concepto de “biblioteca de componentes” es un

A comienzo de la etapa de construcción, se distinguen las necesidades únicas del