1

TALLER SOBRE METODOLOGÍAS DE DESARROLLO DE SOFTWARE

GA1-220501093-AA1-EV01

SERVICIO NACIONAL DE APRENDIZAJE SENA

FICHA No: 3145644

ANALISIS Y DESARROLLO DE SOFTWARE

INSTRUCTOR: JAVIER HUMBERTO PINTO DIAZ

6 De marzo del 2025

I. INTRODUCCION
 2

I. INDUCCION DE LA METODOLOGIA DE DESARROLLO DE SOWARE

Es importante aclarar que existe un gran número de definiciones sobre lo que es una
metodología, para evitar cualquier confusión en este material se utiliza la definición
dada en Maida y Pacienzia (2015), quienes indican que una metodología hace
referencia a un conjunto de procedimientos genéricos y lógicos que se utilizan para
alcanzar un objetivo particular usando un conjunto de habilidades y conocimientos.

Las metodologías de desarrollo de software siempre parten de un componente teórico

y cuando son usadas por los equipos de trabajo conllevan a la utilización de un
conjunto de técnicas y métodos que al final determinarán las tareas generales y
específicas que se deberían realizar para alcanzar un objetivo.

Existen diferentes tipos de metodologías de desarrollo

de software que fueron ideadas pensando en problemas
 3

particulares presentados en la industria en contextos específicos,

por lo cual es importante conocer sus diferentes características y
contrastarlas con las necesidades particulares a las que se enfrenta
a la hora de desarrollar un producto y servicio. Es decir, cada una
de estas tiene ventajas y enfoques que pueden ser reutilizados en
diferentes momentos.
Existen dos grandes clasificaciones de metodologías de desarrollo
de software que se agrupan generalmente como marcos de trabajo
tradicionales o marcos de trabajo ágiles que se verán a
continuación.

II. MARCOS DE TRABAJOS TRADICIONALES

Para el desarrollo de un buen producto de software se debe iniciar por un excelente

proceso de planificación y gestión de este durante todas las etapas y actividades que
involucran transformar una idea o requerimiento en un producto o servicio que será usado
por un cliente particular.
II.1 CARACTERISTICAS

Los marcos de trabajo o metodologías tradicionales se caracterizan por centrar la mayor parte de
su esfuerzo en la planeación y control del proceso, lo que conlleva a una documentación
exhaustiva y precisa de los artefactos que describen los requisitos y los modelos del sistema en
las etapas iniciales del desarrollo del proyecto
(Maida y Pacienzia, 2015).

Lo anterior supone que este tipo de enfoques

son óptimos en proyectos en los cuales los
requisitos están plenamente identificados y
delimitados, donde no se producirá ningún
 4

cambio en lo establecido mientras el proyecto

es finalizado.

A continuación, se describen algunas

metodologías que se enmarcan en los marcos
tradicionales de desarrollo de software.

II.2 CASCADA
Este es uno de los modelos genéricos más ampliamente conocido en la ingeniería de software y
se deriva de procesos de ingeniería de sistemas más generales (Royce, 1970). Este modelo
plantea un proceso lineal donde las actividades de desarrollo de un producto o servicios
de software se agrupan en un conjunto de fases sucesivas donde estas son desarrolladas una única
vez y los resultados de cada fase son la entrada requerida para cada fase subsiguiente, ninguna
fase puede iniciar si la fase anterior no ha sido finalizada generalmente mediante un formalismo
que puede ser un documento.

Según Sommerville (2005) el modelo en cascada se compone de cinco (5) etapas principales que
se asocian con actividades fundamentales en el proceso de desarrollo de software, las cuales son:
 5

II.3 PROCESO RACIONAL UNIFICADO RUP

RUP es una sigla en inglés equivalentes a Proceso Racional Unificado, el cual es un
proceso de desarrollo de software tradicional basado en el modelo cascada y que fue
desarrollado por la empresa Rational Software que es propiedad de IBM, esta
metodología se centra en la arquitectura y es guía por casos de uso (requerimientos)
(Kruchten, 2003).

RUP divide el proceso de desarrollo en cuatro grandes fases, dentro de las que se
realizan algunas iteraciones donde se desglosan, en mayor o menor intensidad, un
conjunto de disciplinas según la fase que se está abordando. A continuación, se
observan las fases y disciplinas propuestas por RUP.

FASES Y DISCIPLINAS DE RUP:

 6

II.4 ANALISTTAS
A continuación, se describen cada uno de los roles

En los roles específicos clasificados en la categoría de analistas se encuentran:

 Analistas de procesos de negocio.

 Diseñadores del negocio.

 Analistas del sistema.

 Especificador de requisitos.

 Diseñadores de interfaces de usuario o similares.

II.5 DESARROLLADORES

Dentro de los roles específicos clasificados en la categoría de desarrolladores se encuentran:

 Arquitectos desoftware.

 Diseñador de bases de datos.

 Desarrollador backend y frontend.

 Cualquier otro rol relacionado con procesos de codificación o integración de código.

III. MARCOS DE TRABAJO ÁGILES

Los marcos de trabajo ágiles o metodologías ágiles para el desarrollo
de software nacen como otra opción para abordar proyectos donde no es posible tener
un detalle completo de los requerimientos y sus estimaciones en la primera fase del
 7

proyecto o donde es necesario hacer procesos de adaptabilidad a lo largo del proceso

de desarrollo de software.
III.1 CARACTERISTICAS
Las metodologías ágiles proveen un conjunto de pautas y principios que buscan facilitar y
priorizar la entrega de producto sobre procesos de documentación exhaustiva, haciéndolos más
simples, donde interactúa el cliente final desde las primeras etapas del proyecto. El inicio de las
metodologías ágiles nació en el año 2001 a partir del manifiesto ágil de software donde se
establecen cuatro valores fundamentales (Manifiesto Ágil, 2001):

 Individuos e interacciones sobre procesos y herramientas.

 Software funcionando sobre documentación extensiva.

 Colaboración con el cliente sobre negociación contractual.

 Respuesta ante el cambio sobre seguir un plan.

Adicionalmente a los valores ágiles anteriormente listados, el manifiesto ágil establece 12

principios ágiles para materializar los valores definidos (Manifiesto Ágil, 2001):

1. “Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y

continua de software de valor.

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los
procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.

3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta
un par de meses, con preferencia en los períodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a
través del proyecto.

5. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el

respaldo que necesitan y procurándoles confianza para que realicen la tarea.
 8

6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un

equipo de desarrollo es mediante la conversación cara a cara.

7. El software que funciona es la principal medida del progreso.

8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica enaltece la agilidad.

10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto
organizan.

12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta
su conducta en consecuencia”.

III.2 Programación Extrema – XP

XP es la abreviación comúnmente utilizada para referirse a Extreme Programming,

que es un marco de desarrollo de software ágil que busca producir software de alta
calidad en contextos con requisitos altamente cambiantes, riesgos que involucran
tiempos fijo con tecnologías nuevas y equipos de trabajo pequeños ubicados en un
mismo sitio.

En XP se definen cinco valores según Beck y Andrés (2004):

Comunicación: el desarrollo de software requiere de trabajo en equipo

por lo cual es importante la transferencia de conocimientos y utilizar
medios de comunicación apropiados, se propone la discusión cara a cara
con herramientas que permitan dibujar o escribir, como, por ejemplo: un
tablero.
 9

Simplicidad: esto se refiere a hacer solo las cosas que sean

absolutamente necesarias evitando el desperdicio, elaborar las cosas de
forma que sea fácil entender por otros y abordar solo requisitos conocidos.

Retroalimentación: esto permite identificar áreas de mejora y

revisión constante de las prácticas implementadas en el proceso de forma
que se puedan establecer procesos de mejora permanentes.

Coraje: se refiere al actuar sobre situaciones que pueden ser retadoras para
el equipo, como, por ejemplo:

 Enfrentar problemas organizacionales.

 Intentar implementar funcionalidades de formas diferentes cuando

lo convencional no funciona y aceptar comentarios, etc.

Respeto, los miembros del equipo deben respetarse entre sí para

comunicarse y trabajar en equipo. Cada persona contribuye en favor de
lograr el objetivo del equipo.
 10

3.3 DESARROLLO RÁPIDO DE APLICACIONES - RAD

RAD (Desarrollo Rápido de Aplicaciones) es otra metodología de desarrollo de

software ágil que se centra en el desarrollo rápido de aplicaciones mediante la realización de
iteraciones frecuentes y realimentación constante y fue inventado por James Martin en 1991.

Algunas características fundamentales de RAD son:

 Mayor flexibilidad y adaptabilidad a cualquier ajuste que deba realizarse durante el

proceso de desarrollo.

 Iteraciones rápidas que reducen el tiempo de desarrollo y mantienen un ritmo de entrega

acelerado.

 Se fomenta la reutilización de código.

 Mejor gestión del riesgo, ya que las partes interesadas discuten y abordan cualquier
vulnerabilidad mientras se construyen los productos.

A continuación, se describen las fases propuestas en RAD.

 11

III.3 SCRUM
Scrum es un marco de trabajo ágil de muy amplio uso en la industria del software que se
fundamenta en los valores y principios ágiles definidos en (Manifiesto Ágil, 2001) y donde se
definen tres pilares fundamentales según (SCRUMstudy, 2013) los cuales se describen a
continuación:

Transparencia

Hace referencia a que cualquier proceso de Scrum puede ser conocido por cualquiera. Esto es
posible por medio de eventos como:

 Las reuniones de revisión y reuniones diarias.

 Artefactos como la pila de producto.

 Cronogramas de lanzamiento.

 Documentos de visión del proyecto.

 Instrumentos de seguimiento, como: el burndown chart o el tablero de Scrum (Scrum

board).

Inspección

Permite que cualquiera pueda estar enterado de las actividades realizadas por otros y en general
conocer el estado actual de los procesos.

Adaptación

Por medio de la transparencia y la inspección es posible fijar actividades de mejoras que

permitan modificar todo tipo de proceso en pro de lograr más altos estándares de calidad.

Adicionalmente, este marco de trabajo ágil está estructurado por un conjunto de

roles, eventos y artefactos que pueden ser observados a continuación:

MARCO DE TRABAJO SCRUM