Práctica no.

1
Metodologías de desarrollo de software

Nombre del alumno: Nava Rivero Brian

Matrícula: 18090623

Grupo: 3501

Turno: Matutino

Calificación: _____________
 Unidad 1 Práctica No. 1 Ambiente de aprendizaje: Laboratorio de
Sistemas Computacionales

Nombre de la práctica: Metodologías de desarrollo de software.

Resultado de aprendizaje propuesto (Rap)
asociado con esta práctica
Duración: 4 Horas
Investigar las metodologías de desarrollo más comunes que se
aplican en las empresas que se dedican a la producción de
software y elegir una para el desarrollo de un proyecto de
software, justificando su elección.

Conocimientos Previos:
• Fundamentos de Ingeniería del software

MATERIALES Y RECURSOS DIDÁCTICOS

• Internet • Software de aplicación (Word, Power Point)
• Video Proyector y Control para encendido y • Pizarrón y plumones para pizarrón.
apagado de proyector

Actividades sustantivas de aprendizaje:

• Investigar diferentes metodologías clásicas o pesadas, para el desarrollo de proyectos. Identificar las
características principales de cada metodología.

Actividades sustantivas de enseñanza:

• Explica la importancia de aplicar una metodología al desarrollar proyectos de software.
• Supervisa el desarrollo de la práctica

Evidencias por recopilar:

• Práctica resuelta en el formato.
• Trabajo de investigación.
• Cuadro comparativo.
• Esquemas

Actividad de evaluación 1. Valor 70 puntos.

Desarrollo de la práctica

1) Realizar un trabajo de investigación, sobre el tema Metodologías de desarrollo clásicas.

a. Cascada

b. Incremental

c. Evolutivo
 d. Espiral

e. Prototipos

f. Desarrollo basado en componentes

2) Escribe cuáles son las fases de cada una de las metodologías investigadas.

3) Elabora un cuadro comparativo de las metodologías ya mencionadas. El cuadro comparativo debe contener, el nombre
de la metodología, definición de la metodología, principios, características, ventajas y desventajas.

4) ¿Qué metodología recomiendas utilizar, al desarrollar un proyecto de software y por qué?

5) Dibuja un esquema de la metodología de desarrollo en cascada.

6) Dibuja un esquema de la metodología de desarrollo en espiral.

Actividad de evaluación 2. Valor 30 puntos.

Conclusiones. (Media cuartilla).

Parámetros de evaluación
Al terminar cada práctica, se evaluará tu desempeño mediante la siguiente rúbrica.

1. Lista de cotejo
2. Reporte de la práctica
3. Ejercicios en clase

Sistema de rúbricas

No. INDICADOR PONDERACIÓN

1 Investigación 10%
2 Trabajo en clase 40%
3 Lista de cotejo 10%
4 Reporte de la práctica 40%
Total ponderación 100%

Lista de cotejo
Parámetros Cumplió No cumplió

1 Entregaste el trabajo tiempo y forma

2 Cumpliste con el reglamento

3 Traes lista de cotejo

4 Cumpliste con la entrega de los ejercicios

5 Entregaste a tiempo la practica

6 Cumplió en tiempo y forma

 Guía de observación de la práctica No. 1

Instrucciones: Indique a través de una √ el desempeño que haya sido observado en el alumno en el desarrollo de
esta práctica.

(1) Totalmente de acuerdo: Cuando el Evaluador se encuentra totalmente satisfecho respecto a la afirmación
realizada
(2) De acuerdo: Cuando el Evaluador se encuentra satisfecho con respecto a la afirmación realizada
(3) Desacuerdo: Cuando el Evaluador se encuentra insatisfecho con respecto a la afirmación realizada
(4) Totalmente en desacuerdo: Cuando el Evaluador se encuentra totalmente insatisfecho con respecto a la
afirmación realizada.
Nombre del alumno (a): ____________________________________________________________________

N° IDENTIFICACIÓN (1) (2) (3) (4)

1. Resolvió el cuestionario de la práctica de manera adecuada.

2 Realizó el trabajo de investigación sobre metodologías clásicas de

manera correcta.

3 Dibujó los esquemas de las metodologías solicitadas.

4 Elaboró el cuadro comparativo de metodologías clásicas, con los

elementos solicitados.

5 Realizó las medidas de seguridad correctamente.

6 Mostró un comportamiento adecuado y de orden dentro del laboratorio.

7 Puso atención a la explicación del profesor.

8 El alumno limpió el área de trabajo.

9 El alumno acomodó los materiales usados.

10 Elaboró el reporte.

Profesor (a): _________________________________________________ Fecha: _____________________

Hora de inicio: Hora de término: Evaluación:

Observaciones:
 Metodologías de desarrollo clásicas.

Desarrollo en cascada.

El modelo en cascada es una metodología secuencial para la gestión de proyectos

que se divide en fases; Cada fase comienza recién cuando ha terminado la anterior.

Ciclo de vida de un programa, es el enfoque metodológico que ordena

rigurosamente las etapas del proceso para el desarrollo de software, de tal forma
que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.

¿Todo listo para empezar con la gestión de proyectos en cascada? Sigue estos seis
pasos:

1. Fase de requerimientos: Es el proceso de planificación inicial en el que los

miembros del equipo reúnen toda la información posible para garantizar el éxito del
proyecto.

2. Etapa de diseño del sistema: En un proceso de desarrollo de software, la fase de

diseño implica que el equipo que trabajará en el proyecto especifique qué hardware
usará, además de cualquier otro detalle, como los lenguajes de programación y la
interfaz de usuario.

3. Etapa de implementación: Esta es la fase en que todo entra en acción.

4. Etapa de pruebas: En esta etapa, el equipo de Desarrollo entrega el proyecto al

equipo de Calidad para que realice las pruebas pertinentes.
Modelo incremental.

Las fases del modelo incremental permiten el mejor el resultado posible, por cada
fase, el cliente puede dar su opinión para así evitar cambios bruscos durante el
desarrollo del proyecto.

Las fases por las que deben pasar todos los incrementos no son necesariamente
rígidas gracias que el modelo incremental es adaptable a las necesidades del
proyecto siendo así que al final, el producto es probado ante el cliente y se toma en
cuenta cualquier comentario que surja para el desarrollo del siguiente incremento.

Cada fase ayuda a concretar un objetivo específico que será necesario para
alcanzar los demás. Vemos:

1. Requerimientos: Esta fase se refiere a todos los objetivos del proyecto, tanto el
general o central como los específicos.

2. Diseño de los incrementos: Se define cuál será la evolución del proyecto en las
iteraciones.

3. Desarrollo del incremento: Las tareas definidas son llevadas a cabo y así los
incrementos previstos son desarrollados.

4. Validación de los incrementos: Los responsables de la gestión de proyecto han

de verificar que cada iteración culminada de los resultados esperados.

5. Integración de los incrementos: Como lo indica el nombre de esta fase, se trata

de integrar todos los incrementos aprobados o validados por la gestión de
proyectos.

6. Entrega del producto: Una vez hecha la integración y se constante que el producto
cumple con los objetivos planteados, se realiza la entrega.
Modelo evolutivo.

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de
exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos
por parte del cliente o del usuario final; Las fases de especificación, desarrollo y
validación se entrelazan en vez de separarse.

Existen dos tipos de desarrollo evolutivo:

1.Desarrollo exploratorio: Donde el objetivo del proceso es trabajar con el cliente

para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza
con las partes del sistema que se comprenden mejor. El sistema evoluciona
agregando nuevos atributos propuestos por el cliente.

2.Prototipos desechables: Donde el objetivo del proceso de desarrollo evolutivo es

comprender los requerimientos del cliente y entonces desarrollar una definición
mejorada de los requerimientos para el sistema. El prototipo se centra en
experimentar con los requerimientos del cliente que no se comprenden del todo.

1. Entregar al cliente algo útil.

2. Medir el valor agregado del incremento.

3. Ajustar el diseño y los objetivos en base a las mediciones.

Modelo espiral.

Su estructura busca ser lineal y con una lógica terminado para comenzar; Esto
significa que la actividad siguiente no puede comenzar, hasta que se haya
completado la actividad anterior.

El elemento más interesante de esta metodología radica en la combinación de esa

estructura básica, con la iteración incremental, en escalas cada vez más grandes, y
donde se asumen riesgos mayores.

El modelo evolutivo en espiral consiste de cuatro fases:

1. Planificación: La planificación tiene como meta, lograr identificar los objetivos y el

alcance del primer ciclo.

2. Análisis de riesgo: El análisis de riesgos es muy importante dentro de las fases

del modelo en espiral.

3. Desarrollo: Se desarrolla y valida el prototipo, según el alcance y las funciones

definidas en la etapa anterior.

4. Evaluación: Cuando concluye una vuelta de la espiral, es momento de comenzar

el ciclo de nuevo, pero no sin antes evaluar lo realizado en la iteración que termina.
Modelo Prototipo.

En contraste con la Ingeniería de Software de la década de los 70, que dio respuesta
a proyectos grandes, pero con requisitos estables, la Ingeniería de Software de los
80 reaccionó a las complicaciones resultantes de encontrarse con requisitos poco
claros y dinámicos, dando lugar a la “construcción de prototipos”.

El modelo de ciclo de vida de prototipos fue propuesto por Gomaa en 1984.

Un prototipo es un mecanismo para identificar los requisitos del software. La

construcción de prototipos es un proceso que facilita al ingeniero de software el
desarrollo de la aplicación.

Normalmente, el prototipo sirve como mecanismo para identificar los requisitos del
software, y su construcción suele llevar las siguientes etapas:

1. Recolección de requisitos: El ingeniero de software y el cliente definen los

objetivos globales del software, y aquéllos más específicos que se desean destacar
con el prototipo.

2. Diseño rápido: Centrado en los aspectos del software visible al usuario (por
ejemplo, interfaz de usuario, entradas y salidas…).

3. Construcción del prototipo.

4. Evaluación del prototipo: Se realiza por el cliente y usuarios, lo que permitirá

concretar y refinar los requisitos del software a desarrollar.

5. Refinamiento del prototipo: Se produce un proceso iterativo en el que el prototipo

es refinado para que satisfaga las necesidades del cliente, al tiempo que facilita al
ingeniero de software un mejor conocimiento del sistema.

6. Producto: En la mayoría de los casos este sistema refinado (piloto) hay que
desecharlo y hacer uno nuevo. Por ello, el desarrollo de un prototipo se debe
planificar con el acuerdo expreso del cliente.
Modelo de desarrollo basado en componentes.

El modelo de desarrollo basado en componentes incorpora muchas de las

características del modelo espiral, más sin embargo es de naturaleza evolutivo y
demanda un enfoque iterativo para la creación de software.

Sin embargo, el modelo de desarrollo basado en componentes construye

aplicaciones a partir de fragmentos de software prefabricados.

las etapas siguientes:

1. Se investigan y evalúan, para el tipo de aplicación de que se trate, productos

disponibles basados en componentes.

2. Se consideran los aspectos de integración de los componentes.

3. Se diseña una arquitectura del software para que reciba los componentes.

4. Se integran los componentes en la arquitectura.

5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.

 Metodologías de desarrollo clásicas.

Metodologí Definición Principios Características Ventajas y desventajas

a

Cascada Es un Tiene un El modelo en cascada V

método de funcionamient es un enfoque clásico
gestión de o muy sencillo. en el desarrollo de • Usa una
proyectos, Lo que software que describe estructura
en el que el propone es un método de clara.
proyecto se dividir en fases desarrollo lineal y • Determina el
divide en cada etapa del secuencial. Consta de objetivo final
distintas desarrollo de cinco a siete fases, rápidamente.
fases software y cada fase está definida • Transmite bien
secuenciales completar por diferentes tareas y la información.
, donde el cada una de objetivos, por lo que la
equipo ellas en un totalidad de las fases D
puede pasar orden describe el ciclo de vida
• Dificulta los
a la siguiente específico, es del software hasta su
cambios
fase sólo decir, no entrega.
• Excluye al
cuando se puedes iniciar
cliente o al
haya la “fase 2”
usuario final
completado hasta que
• Retrasa las
la anterior. hayas
pruebas hasta
concluido la
después de la
“fase 1”.
finalización

Incremental Este modelo El modelo ▪ Los V

descompone incremental de incrementos
un proyecto gestión de son pequeños. • La distribución
en una proyectos tiene ▪ Permite una de módulos
sucesión de como objetivo fácil facilita el
agregados un crecimiento administración SDLC.
denominado progresivo de de las tareas • Este modelo
s la en cada es rentable.
incrementos, funcionalidad. iteración. • Los recursos
estos Es decir, el ▪ La inversión se se utilizan
agregados producto va materializa a correctamente
conforman evolucionando corto plazo. según el
un fragmento con cada una ▪ Es un modelo conjunto de
de la de las entregas propicio a habilidades.
funcionalidad previstas hasta cambios o • Gráfico de
total del que se amolda modificaciones. aprendizaje
producto; a lo requerido ▪ Se adapta a las fluido y bueno.
Este es un por el cliente o necesidades
modelo destinatario. que surjan. D
 prescriptivo 1. Necesita muy buena
que entrega planificación sobre el
un modelo.
componente
de trabajo 2. La rotura del módulo
con cada debe planificarse
incremento. adecuadamente.

3. Es necesario
conocer bien todo el
sistema antes de elegir
los módulos.

4. El costo total a veces

es alto.

Evolutivo Son modelos Desde el punto ▪ Desarrollo V

iterativos, de vista de exploratorio:
permiten desarrollo de Donde el • La
desarrollar sistema el objetivo del especificación
versiones enfoque proceso es puede
cada vez evolutivo suele trabajar con el desarrollarse
más traer más cliente para de forma
completas y ventajas en explorar sus creciente.
complejas, comparación requerimientos • Los usuarios y
hasta llegar con un y entregar un los
al objetivo enfoque en sistema final. desarrolladore
final cascada ya ▪ Prototipos s logran un
deseado; que el sistema desechables: mejor
incluso se va Donde el entendimiento
evolucionar ajustando a las objetivo del del sistema.
más allá, necesidades proceso de Esto se refleja
durante la del cliente, a la desarrollo en una mejora
fase de vez que él evolutivo es de la calidad
operación. mismo comprender los del software.
entiende mejor requerimientos • Es más
sus propios del cliente y efectivo que el
requerimientos entonces modelo de
. desarrollar una cascada, ya
definición que cumple
mejorada de con las
los necesidades
requerimientos inmediatas del
para el cliente.
sistema.
D

• Puede resultar
costoso si hay
 que reiniciar el
desarrollo.
• Hay que
mantener muy
bien la
documentació
n del proyecto
para facilitar el
control de
versiones y su
mantenimiento
.
• Para el rápido
desarrollo se
necesitan
herramientas
que pueden
ser
incompatibles
con otras o
que poca
gente sabe
utilizar.

Espiral Modelo de En el modelo Cada una de las V

proceso de espiral, el regiones están
software software se compuestas por un • El modelo en
evolutivo desarrolla en conjunto de tareas del espiral puede
donde se una serie de trabajo llamado adaptarse y
conjuga la versiones conjunto de tareas que aplicarse a lo
naturaleza incrementales. se adaptan a las largo de la vida
de Durante las características del del software
construcción primeras proyecto que va a de
de prototipos iteraciones la emprenderse en todos computadora.
con los versión los casos se aplican • Como el
aspectos incremental actividades de software
controlados y podría ser un protección. evoluciona a
sistemáticos modelo en medida que
del modelo papel o un progresa el
lineal y prototipo, proceso, el
Tipos desarrollador y
secuencial. durante las
últimas el cliente
El modelo espiral tuvo
iteraciones se comprenden y
varias modificaciones
producen reaccionan
que son:
versiones cada mejor ante
vez más Modelo Original de riesgos en
completas del Boehm. cada uno de
los nivele
evolutivos.
 sistema Modelo Típico de Seis • El modelo en
diseñado. Regiones. espiral permite
a quien lo
Modelo WINWIN. desarrolla
aplicar el
enfoque de
construcción
de prototipos
en cualquier
etapa de
evolución del
producto.

• Resulta difícil
convencer a
grandes
clientes de que
el enfoque
evolutivo es
controlable.
• Debido a su
elevada
complejidad
no se aconseja
utilizarlo en
pequeños
sistemas.
• Genera mucho
tiempo en el
desarrollo del
sistema.

Prototipos Es El prototipo es • El prototipo V

básicamente una versión funcional
prueba y funcional de un evolutivo • Reduce el
error ya que sistema de desarrolla un riesgo de
si al usuario información o comportamient construir
no le gusta de parte de o que satisface productos que
una parte del éste, pero su los requisitos y no satisfagan
prototipo propósito es el necesidades las
significa que de servir de que se han necesidades
la prueba modelo entendido de los usuarios
fallo por lo preliminar. claramente. • Reduce costo
cual se debe • Se va y aumenta la
corregir el Una vez en modificando y probabilidad
error que se operación, el desarrollando de éxito
tenga hasta prototipo se sobre la
 que el refinará más marcha, según • Exige disponer
usuario aún hasta que las de las
quede cumpla con apreciaciones herramientas
satisfecho. precisión los del cliente. adecuadas
requerimientos Esto ralentiza
del usuario. el proceso de D
desarrollo y
• Debido a que
disminuye la
el usuario ve
fiabilidad,
Una vez que el
puesto que el
finalizado el prototipo
software está
diseño, el funciona
constante
prototipo se piensa que
mente
puede este es el
variando, pero,
convertir en un producto
a la larga,
sistema en terminado y no
genera un
producción entienden que
producto más
refinado. recién se va a
seguro, en
desarrollar el
cuanto a la
satisfacción de software.
las • El
necesidades desarrollador
del cliente. puede caer en
la tentación de
• Impropio para
ampliar el
sistemas
prototipo para
complejos y
construir el
grandes.
sistema final
sin tener en
cuenta los
compromisos
de calidad y
mantenimiento
que tiene con
el cliente.

Desarrollo El modelo de El objetivo de Es utilizado para V

basado en desarrollo la tecnología reducir los costos,
compones basado en de tiempo y esfuerzos de • Funcionalidad
componente componentes desarrollo del software, mejorada.
s es software es y de esta manera
necesario construir incrementar el nivel de
dar una aplicaciones productividad de los • reduce los costes y
visión muy complejas grupos desarrolladores tiempos
general de lo mediante y minimizar los riesgos;
que es la ensamblado a su vez ayuda a
reutilización de módulos optimizar la fiabilidad,
de software que han sido flexibilidad y la • Reutilización del
previamente software.
diseñados por reutilización de la
otros, a fin de aplicación final.
ser reusados • Simplifica las
en múltiples pruebas.
aplicaciones
D

* Genera mucho
tiempo.

* Genera mucho
trabajo adicional

* Confiabilidad de los
componentes.