1

Metodologías de desarrollo de software

Paula Andrea Soler NAvarro.

Abril 2018.

Fundación Universitaria Internacional del Trópico Americano.

Casanare.

Seminario de proyecto
 2

Metodología de desarrollo de software

Introducción e información general

¿Qué son las metodologías de desarrollo de software?

Inicialmente, es importante conocer la definición de metodología y desarrollo.

Metodología es una palabra compuesta por tres vocablos griegos: metá (“más allá”), odós

(“camino”) y logos (“estudio”); considerando lo anterior, la definición de metodología son

los métodos para luego determinar cuál es el más adecuado.

El concepto de metodología es “conjunto de métodos coherentes y relacionados por unos

principios comunes”. El concepto de desarrollo, está vinculado a la acción de desarrollar o

a las consecuencias de este accionar, por lo tanto es necesario, rastrear el significado del

verbo desarrollar: se trata de incrementar, agrandar, extender, ampliar o aumentar alguna

característica de algo físico (concreto) o intelectual (abstracto).

Por lo anterior, se concluye que metodología de desarrollo es: el estudio y determinación

de cuál es el método más adecuado para dar incremento a algo en este caso al software.

Actualmente el término desarrollo es el más utilizado para referirse a las actividades que

involucran la creación, fabricación, actualización o modificación de software.

 3

Componentes de la Metodología

La metodología se define como la disciplina que indicará qué métodos y técnicas hay que

usar en cada fase del ciclo de vida del desarrollo del proyecto. Los elementos que

componen la metodología son:

Fases.

Son etapas del proceso de desarrollo de software. En la metodología se identificarán las

diferentes actividades que se realizarán en cada fase. Una fase es un conjunto de actividades

relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas

(actividades elementales) que pueden compartir un tramo determinado del tiempo de vida
 4

de un proyecto. La agrupación temporal de tareas impone requisitos temporales

correspondientes a la asignación de recursos (humanos, financieros o materiales).

La metodología contempla las fases de: Análisis, Diseño, Desarrollo, Pruebas e

Implementación; cada una de estas etapas se describen más adelante.

Métodos.

Es necesario identificar el modo en el que se realizará el proceso de desarrollo del producto

software. Se tendrá que descomponer los procesos en actividades más pequeñas, en estas

actividades se definen los valores que recibirá cada fase así como los que generará y la

técnica que se tendrá que usar. Técnicas y Herramientas.- Indican como se deberá de

resolver cada actividad y que herramientas podríamos usar. Existen diferentes tipos de

técnicas, algunas de ellas son:

 De recopilación de datos: entrevistas, formularios, etc.

 Técnicas gráficas: Diagramas, organigramas, matrices, etc.

 Técnicas de modelado: Desarrollo estructurado y orientado a objetos.

Documentación.

Es necesario especificar qué documentación se va generar durante cada etapa del proceso;

estos documentos deben realizarse de manera completa y usando todos los valores de

entrada y salida que se van generando, esto servirá para recoger los resultados y tomar

decisiones de las diferentes situaciones planteadas. Por ejemplo; Actas de Reuniones,

Formatos de Pruebas, etc.

 5

Control y Evaluación.

Las actividades de control y evaluación se deben de realizar a lo largo de todas las fases

para identificar errores y corregirlos a tiempo. En resumen, consiste en realizar el

seguimiento del avance de acuerdo al cronograma de trabajo; puede ser necesario tomar

decisiones como el replanteamiento de la planificación de las tareas asignadas para lograr

los objetivos propuestos.

Descripción de metodologías de desarrollo de software elegidas

Teniendo las metodologías seleccionadas, se procedió a ordenar la información de cada

una según los aspectos considerados inicialmente. El resultado es una descripción de cada

metodología, el cual es presentado a continuación.

RATIONAL UNIFIED PROCESS

Descripción

RUP es un proceso de ingeniería de software, desarrollado y mantenido por Rational

Software Corporation. Es un conjunto de actividades agrupadas en un marco adaptable a

distintos tipos de organizaciones, áreas de aplicación, niveles de aptitud y tamaños de

proyectos para producir software a partir requerimientos iniciales. Sus inicios se remontan

a 1997, cuando la Rational desarrolla Rational Objectory Process (ROP), siendo UML el

lenguaje de modelado. Posteriormente, la organización liderada por Grady Booch, Ivar

 6

Jacobson y James Rumbaugh, adaptó a ROP nuevos elementos, tomando forma de Rational

Unified process y lanzándolo para junio de 1998.

Manejo de requisitos

Requerimientos son las necesidades funcionales, las ventajas que le otorgan, así como los

límites y lo que no será tomado en cuenta para desarrollar un software. La dirección que

tomará el proyecto depende de la especificación de requisitos y se logra ello a través de los

casos de uso. Los modelos de casos de uso, cuya función es la de plasmar los

requerimientos definidos, guiarán el análisis, diseño, implementación y las pruebas, y otras

actividades de modo tal que finalmente cumpla con las necesidades del usuario. La tabla

1.0. Nos muestra los elementos de un modelo de casos de uso.

Tabla 1.0. Elementos de un modelo de caso de uso. Fuente: página web Casos de uso.
 7

Centrado en la arquitectura

La arquitectura de software otorga una serie de estándares que encaminarán la organización

y estructura de un software, sus elementos componentes, en lo posible agrupados de

acuerdo a un comportamiento, subproceso, características o relaciones en común.

En RUP, la arquitectura es representada a través de modelos, que contribuirán a tener una

descripción de los elementos más importantes de la arquitectura. Cada modelo

proporcionará sólo una visión parcial de la arquitectura, ya sea estática, funcional o

dinámica. Los modelos se plasman a través de lenguajes, es decir de diagramas. La figura

2.1. Presenta los distintos modelos según cada vista de arquitectura. En el caso de RUP,

como lo hemos mencionado líneas arriba, trabaja con el Lenguaje Unificado de Modelado

(UML)

Fig. 2.1. Vistas de Arquitectura. Adaptado de Reynoso, C.

 8

RUP propone tres criterios de evaluación:

 Fiabilidad

Probabilidad de que durante la ejecución de las operaciones de un sistema no ocurra un

fallo.

 Funcionalidad

El software debe actuar de manera apropiada, en concordancia con sus requisitos

funcionales.

 Rendimiento

La rapidez en que el software realiza una tarea ante una determinada situación y condiciones

predefinidas de trabajo.

METODOLOGIA DE DESARROLLO SCRUM

Descripción

SCRUM es un proceso de desarrollo que sigue los fundamentos establecidos en el

manifiesto ágil. Toma sus principios de los estudios realizados en los años 80 por los

japoneses Hirotaka Takeuchi e Ikujijo Nonaka, quienes investigaron nuevas prácticas

de producción, inicialmente para productos tecnológicos. Jeff Sunderland en 1993

adaptó dichas ideas para desarrollo de software para la empresa Easel Corporation y

en 1996, junto con Ken Schwaber presentó el proceso formal.

 9

Principios

Scrum se sostiene sobre tres principios obtenidos de la teoría del control empírico

de procesos:

Transparencia

Todos los integrantes de la administración del proceso deben conocer los

aspectos y resultados que inciden sobre aquél. Estos aspectos deben tener estados

definidos, con términos concretos y no ambiguos.

Inspección

La frecuencia de inspección debe ser suficiente como para identificar variaciones

que podrían afectar de manera negativa un proyecto. El éxito de las actividades

dependerá de la habilidad, cautela, eficiencia y experiencia de los inspectores.

Adaptación

La adaptación rápida permite ajustar el proceso cuando, a través de la inspección,

se hallan aspectos fuera de los límites y que producen desviaciones al objetivo

principal del proceso.

Para inspeccionar y adaptar, el proceso se vale de reuniones diarias, revisión de

iteraciones y reuniones de planificación.

Características

SCRUM posee características de los procesos agrupados como de desarrollo ágil, es

decir:
 Modo de desarrollo de carácter adaptable más que predictivo.
 10

 Orientado a las personas más que a los procesos.

 Estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.

Ciclo de vida

El proceso SCRUM divide a sus componentes en los siguientes grupos principales:

Elementos, Roles, Bloques de tiempo.

Elementos

a) Product Backlog (Pila del producto)

Lista de los requerimientos del sistema, representados por características, funciones,

tecnologías, mejoras y correcciones de errores que debe contener el software para ser

exitoso. Cada elemento debe constar de una descripción, una prioridad, y una

estimación de esfuerzo (magnitud de tiempo que tomará realizar una tarea

determinada). No se debe pretender tener todos los requisitos desde el inicio. Se irá

actualizando a través del tiempo, según los cambios del entorno. Se trabajará con el

Product Backlog teniendo como actividades inmediatas las correspondientes a obtener

los requisitos con mayor prioridad y, por consiguiente, detalladas con mayor nivel.

b) Sprint Backlog (Pila de iteración)

Lista de tareas que se realizarán para alcanzar a hacer un incremento. Las tareas son

agregadas al Sprint Backlog tomando como referencia el Product Backlog en la reunión

de Planificación del Sprint. Luego estos elementos son descompuestos en tareas más
 11

pequeñas hasta lograr un entendimiento mejor de cada una de ellas. A cada tarea se

debe asignar a personas miembros del equipo encargadas, con un tiempo y unos

recursos para completarlas.

c) Incremento

Ejecutable resultado de un Sprint. Se trata de un módulo operativo. Según Schwaber y

Sutherland,la principal característica de un incremento es que debe estar “hecho”. Para

estos mismos autores, esto es:

 Tener un pleno compromiso por parte del equipo en hacer un elemento del

Product Backlog en un Sprint.

 Que los elementos del Product Backlog y el incremento en su totalidad hayan

completado el análisis, diseño, refactorización, programación, documentación y

pruebas (testeo unitario, de sistema, de usuario y de regresión, pruebas no

funcionales, pruebas de rendimiento, de estabilidad, de seguridad y de

integración).

 Cualquier internacionalización que permita adaptarse a hábitos lingüísticos y

culturales del grupo de usuarios que lo operará.

EXTREME PROGRAMMING (XP)

Descripción

Extreme Programming es una metodología de desarrollo de software ligera planteada

por Kent Beck en el año 1999. Hacía un año él la había puesto en práctica en la
 12

ejecución de un proyecto llamado C3 (Chrysler Comprehensive Compensation) para

la compañía automotriz Chrysler. Afirma que se puede modificar la curva de costo de

cambios en el desarrollo de programas a lo largo del ciclo de vida, de tipo creciente

en metodologías tradicionales. Para obtener una gráfica opuesta, propone un cambio

sustancial en la forma hacer un sistema.

XP unifica prácticas conocidas desde los inicios del desarrollo de software, que

reunidas buscan satisfacer al cliente con software de desarrollo sencillo, facilitar la

respuesta a los cambios que pueden experimentar las necesidades del cliente en el

tiempo, y maximizar la productividad del grupo de trabajo. Para conseguir tales

objetivos, se requiere que gerentes del proyecto, desarrolladores y clientes (como un

miembro más del equipo de desarrollo de software) sean participantes activos e

involucrados en el proyecto.

Características

Extreme Programming posee características de los procesos agrupados como de

desarrollo ágil, esto es:

 Modo de desarrollo de carácter adaptable más que predictivo.

 Orientado a las personas más que a los procesos.
 Estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.

Tabla 1.1. Ítems determinados en el Plan de Entregas. Fuente: Beck, K.

 13

Plan de entregas
Ítems determinados por el Ítems determinados por parte
negocio. técnica.
 Alcance (historias de usuario).
 Estimaciones.
 Consecuencias de toma de
 Prioridad.
decisiones.
 Procesos (Organización de
 Componentes de entregas.
tareas y equipo).
 Programación detallada
 Fechas de entrega. (Cronograma
de tareas).

La duración de esta fase es de aproximadamente 2 a 4 semanas, obedeciendo al

conocimiento previo de los programadores de la tecnología a aplicar

Fig. 2.3. Fases de Extreme Programming. Fuente: Página web Agile Methodologies.
 14

MODELO ESPIRAL

El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del

software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del

desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue

cuatro pasos principales:

1- Determinar o fijar los objetivos.

En este paso se definen los objetivos específicos para posteriormente identifica las

limitaciones del proceso y del sistema de software, además se diseña una planificación

detallada de gestión y se identifican los riesgos.

2. Análisis del riesgo.

En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del

proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos

riesgos se planean estrategias alternativas.

3. Desarrollar, verificar y validar.

En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el

desarrollo del sistema de software y se lo desarrolla.

4. Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se

debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan

los planes para la siguiente fase del proyecto.

 15

Ventajas del modelo espiral

-No requiere una definición completa de los requerimientos del software a desarrollar para

comenzar su funcionalidad.

-En la terminación de un producto desde el final de la primera iteración es muy factible

aprobar los requisitos.

-Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados

tempranamente y existe la forma de poder corregirlos a tiempo.

Desventajas del modelo espiral

-Existe complicación cuando se evalúa los riesgos.

-Se requiere la participación continua por parte del cliente.

-Se pierde tiempo al volver producir inicialmente una especificación completa de los

requerimientos cuando se modifica o mejora el software.

 16

Lista de referencias

1. SORBERAMURINA, V. (2007, Octubre 30). Sistemas De

Información:
Concepto Y Aplicaciones. Extraído el 21 de Junio de 2011 de
sde http://www.editum.org/Sistemas-De-Informacion-Concepto-Y-
Aplicaciones-p- 128.html

2. TOROSSI, G. (s.f.) El Proceso Unificado de Desarrollo de Software.

Extraído
el 02 de Enero de 2012 desde
http://www.ecomchaco.com.ar/UTN/disenodesistemas/apuntes/oo/ApunteRUP.
pdf

3. TORRES COVARRUBIAS, V. J. (2005) Importancia de los sistemas de

información en la administración y la economía de las organizaciones.
Encuentros, Revista Semestral de la Unidad Académica de Economía,
Universidad Autónoma de Nayarit, 2.

4. TORRICO, R. (2010) Metodología Crystal. Extraído el 04 de Febrero de

2012 desde http://www.cs.umss.edu.bo/rep_materia_doc.jsp?doc_mat=130

5. TORRICO, R. (2010) Metodología de desarrollo ágil Crystal. Extraído el

04 de Febrero de 2012 desde
http://www.cs.umss.edu.bo/rep_materia_doc.jsp?doc_mat=130

6. TRIPOD.COM. (s.f.) Importancia y Beneficios de los Sistemas De

Información. Extraído el 21 de Junio de 2011 desde
http://wilbercalles.tripod.com/impyben.html