UNIVERSIDAD ESTATAL DEL SUR DE MANABÍ

FACULTAD DE CIENCIAS TÉCNICAS

CARRERA DE TECNOLOGÍAS DE LA INFORMACIÓN

ASIGNATURA:

Sistemas de Información

ACTIVIDAD # 6

1.Desarrollo Ágil de Software, Concepto, Principios fundamentales.

Metodologías ágiles más comunes, Roles, prácticas y artefactos clave en el desarrollo

ágil.

2. Desarrollo de Software Orientado a Objetos (OO)

Enfoque, conceptos básicos.

Estructura de los sistemas de información utilizando la encapsulación, la

herencia y el polimorfismo.

Cómo se aplica la POO en el desarrollo de sistemas de información.

INTEGRANTES:

Nallely Valentina Ávila Mera

Ricardo Andrés Muentes Arteaga

Alicia Karina Villacreses Castro

Ufelia Natividad Yosa Piguave

CURSO/PARALELO:
 Cuarto “B”

DOCENTE

Ing. José Álava Cruzatty, MG

JIPIJAPA – MANABÍ – ECUADOR

2023

Concepto de Desarrollo Ágil de Software

Las metodologías de desarrollo de software ágil que a menudo son llamadas

Agile, predican la flexibilidad y pragmatismo en el proceso de entrega de aplicación.

Este enfoque iterativo de desarrollo de software ofrece el valor a los usuarios en

incrementos pequeños en vez de lanzamientos tan grandes. Los equipos ágiles evalúan

continuamente los requisitos y resultados, lo que da pie a la implementación eficiente

del cambio.

El uso de Agile les da a los equipos la habilidad de crear valor frente a un

mercado dinámico y de una competencia muy acelerada mientras que se mantiene la

eficiencia y la rapidez. Un principio fundamental de Agile es la creación de una cultura

de trabajo colaborativa ya que les permite a los equipos trabajar conjuntamente con un

mayor entendimiento de los roles individuales dentro del sistema.

Agile también establece las pruebas en todo el proceso del ciclo de desarrollo.

Esto les permite a los equipos hacer cambios cuando sea necesario, alertar entre sí sobre
potenciales problemas y por ende les da la suficiente confianza para crear y lanzar

aplicaciones de muy alta calidad.

Los valores fundamentales de Agile se encuentran en el Manifesto Agile, que fue

creado en 2001 por un grupo de personas de desarrollo de software. Este manifiesto

resalta los 4 conceptos más importantes que promueven el desarrollo ligero, a

continuación, se muestran.

Darles más prioridad a las personas sobre las herramientas y procesos.

Mientras estos últimos son muy esenciales, las interacciones individuales son

significativas y vitales en el proceso de desarrollo de software, también ayudan a crear

una respuesta a las necesidades empresariales de manera efectiva.

Una aplicación muy bien construida antes que la documentación en detalle.

Agile no elimina toda la documentación recolectada, sino que se enfoca mucho

más en darle al equipo de desarrollo la información necesaria que es requerida para

cumplir los objetivos, así como las historias de usuario.

Se sustituyen las negociaciones de contrato del gerente de proyectos y el cliente

por una colaboración que sea frecuente.

El producto puede tomar forma de acuerdo a la visión del cliente de manera

efectiva si se involucran en todo el proceso de desarrollo y no solamente al comienzo y

al final.

Responder al cambio de manera rápida y eficaz.

Agile descarta la idea del cambio como un costo no deseado. En su lugar, le da

valor al cambio y promueve las iteraciones cortas para permitir que las modificaciones

se hagan de manera fácil y rápida.

 Además de estos valores que son tan importantes, el Manifestó Agile también

resalta 12 principios para los equipos de desarrollo que pueden mejorar su

funcionamiento:

1. Dividir las tareas más grandes en pequeñas piezas para una mejor

realización.

2. Se enfoca en la satisfacción del cliente a través de la entrega rápida y

continua de valor.

3. Asegura la creación de procesos que llevan a un impulso de esfuerzo

sostenible.

4. Acepta los requisitos de cambios, aunque se agreguen en una etapa más

avanzada del proyecto.

5. Toma el cambio como un medio para lograr una ventaja

6. Les ofrece a los miembros motivados del equipo el entorno de trabajo y

la confianza necesarios para completar los requisitos con rapidez.

7. Reconoce que los equipos autoorganizados realizan el mejor trabajo

8. Mide el progreso en función del trabajo realizado

9. Completa el trabajo a un ritmo constante

10. Garantiza la colaboración regular entre los equipos de proyecto y de

negocio a lo largo de la duración del proyecto

11. Reflexiona periódicamente sobre cómo se puede ajustar el

comportamiento del equipo para mejorar su eficacia.

12. Por último, busca constantemente la excelencia.

Implementar Agile requiere de un cambio en la cultura tradicional de las

empresas, ya que impulsa la entrega limpia de componentes aislados en lugar de una

aplicación completa de una sola vez. Al día de hoy, Agile ha reemplazado el modelo de
desarrollo de software Waterfall en la mayoría de las empresas. Sin embargo, podría ser

fusionado o reemplazado a medida que el último crece en popularidad mundialmente.

Ciclo de vida del desarrollo de software ágil

En el ciclo de vida ágil, los desarrolladores pasan estratégicamente de la

conceptualización a la salida de la aplicación.

Ciclo de vida del desarrollo de software ágil

A continuación, se encuentran los pasos de este ciclo:

Conceptualización

En el primer paso del ciclo de vida ágil, el product owner define el alcance del

proyecto. En el caso de múltiples proyectos, los más críticos son lo que se priorizan.
Dependiendo de la estructura de la organización, el personal puede ser asignado a más

de un proyecto a la vez.

En esta fase el product owner y el cliente discuten los requerimientos esenciales

y formular la documentación básica que se basa en los objetivos del proyecto finalizado.

Esta documentación, en la forma de un documento de requerimientos de producto

(PRD), incluirá el principal objetivo del proyecto y las características o funciones

soportadas. También en esta etapa se estima el tiempo y el costo del proyecto.

El análisis a profundidad que se lleva a cabo durante la conceptualización ayuda

a determinar la factibilidad antes de que el trabajo comience. Los desarrolladores

pueden apostar a completar los requisitos más críticos ya que pueden irse agregando

muchas más etapas.

Creación

Una vez el proyecto sea conceptualizado, el siguiente paso es construir el equipo

de desarrollo de software. En esta etapa, el product owner verifica la disponibilidad de

cada integrante del equipo y asigna a los mejores al proyecto. El product owner se

responsabiliza de darle a los integrantes los recursos adecuados.

Una vez el equipo se complete, el proceso de diseño comenzará y se crea una

maqueta de la interfaz de usuario y, quizás, algunos diagramas de flujo de usuario y

UML. En esta fase también se construye la arquitectura del proyecto. Luego, los

elementos diseñados se muestran a las partes interesadas para que hagan sus

aportaciones.

Todo esto lleva al equipo a establecer completamente los requerimientos del

diseño y ver la funcionalidad de la aplicación y cómo encaja en el sistema existente. Las

comprobaciones frecuentes del equipo de empresas garantizarán que la creación se

mantenga en marcha.

Construcción

En la fase de construcción, más conocida como fase de iteración, es dónde

básicamente se hace todo el trabajo. Normalmente es la etapa con más duración, con el

equipo Dev (desarrolladores) y los diseñadores UX, se trabaja en colaborativo para

llevar a cabo todos los requerimientos, retroalimentación y la interpretación del diseño

en código.

La meta de construcción es crear la funcionalidad básica de las aplicaciones

antes de que la primera iteración (o ‘sprint’) termine. Funciones secundarias adicionales

y modificaciones menores pueden ocurrir en iteraciones futuras. El objetivo principal es

crear una aplicación funcional e implementar todas las mejoras para la satisfacción del

cliente.

Lanzamiento

Cuando el equipo trabaja en esta etapa, el producto ya debería estar casi listo

para su lanzamiento. Sin embargo, antes de que esto pase, el equipo de control de

calidad (QA) deberá probar la aplicación para asegurarse de que sea totalmente

funcional de acuerdo a lo que se propuso en los objetivos del proyecto. La prueba

también se hace con el fin de estar seguros de que no haya ningún defecto ni bug en el

código; si se llega a encontrar alguno, tendrá que ser reportado y arreglado rápidamente

por el equipo de desarrolladores. El código limpio es una muy esencial en esta etapa

Esta fase también incluye el entrenamiento de usuario, la creación del sistema y

la documentación del usuario para apoyarse. Visualizar el código en esta parte es

esencial. Una vez los defectos hayan sido corregidos y el entrenamiento de usuario se

complete, la iteración final del producto puede tomarse y ser enviada para producción.

Producción y mantenimiento

Una vez la aplicación se lance de manera efectiva y esté disponible para los

usuarios, el equipo pasa a modo de mantenimiento. En esta fase el equipo de

desarrolladores proporciona soporte continuo para asegurarse de que todo vaya perfecto

en las operaciones del sistema y puedan arreglarse todo tipo de bugs y defectos

El equipo también estará al pendiente de ofrecer entrenamiento adicional a los

clientes y resolver todo tipo de dudas para asegurarse de que el producto se utilice de

manera adecuada. Los desarrolladores también pueden utilizar la retroalimentación

recolectada durante esta etapa para planificar diferentes funciones para las siguientes

iteraciones.

Retiro

La aplicación puede estar destinada a retirarse por dos razones: la sustitución por

una nueva versión o la falta de un caso de uso debido a la redundancia.

Si la aplicación no se encuentra en esta fase, el primer paso es notificarles a los

usuarios sobre el retiro de la aplicación. Luego, se deberá asegurar una migración más

fluida del sistema. Finalmente, el equipo de desarrolladores deberá completar todas las

actividades pendientes y cerrar todo lo relacionado con el soporte que se proporciona a

la aplicación existente.

Planificación de los sprints en Agile

Cada fase ágil que se resalta anteriormente conlleva a la creación de numerosas

iteraciones de software. Estas iteraciones se crean conforme el equipo de

desarrolladores repite los procesos para pulir la aplicación y crear la mejor versión de

acuerdo a los requerimientos determinados del proyecto. Éstas son ‘sub ciclos’ que

están contenidos entre el largo ciclo de vida ágil de desarrollo de software.

El ciclo de vida ágil divide el trabajo en “sprints” para completar estas

iteraciones. El objetivo de cada sprint es producir una aplicación que funcione. Un

sprint típico debería durar 10 días laborables (2 semanas).

A continuación, se ve el flujo de trabajo en un sprint típico:

Planear: Cada ‘sprint’ comienza con una reunión de ‘planificación de sprint’ en

el los integrantes de un equipo se reúnen y deciden que objetivos o metas deberían

tratarse a lo largo del trabajo. Durante la reunión, el gerente de proyectos debería

priorizar los trabajos que se encuentran pendientes y asignar tareas a personas

específicas.

Desarrollar: Una vez se lleve a cabo el plan, este equipo trabaja en el diseño y

desarrollo de acuerdo a lo que se establezca.

Pruebas de calidad: Luego de que la aplicación haya sido desarrollada, el equipo

de control de calidad se encarga de probarlo minuciosamente, lleva a cabo todas las

correcciones de cualquier error o imprevistos, y documenta los resultados.

Entrega: Luego de la prueba, la aplicación está lista para su lanzamiento y se

presenta a todos los stakeholders y clientes relevantes.

Valorar: Luego de la entrega, la retroalimentación que se recolecta de los

clientes y se combina con toda la información relevante para la implementación del

siguiente sprint.
 Las reuniones de planificación del sprint son útiles, pero el equipo también

debería reunirse regularmente (si es posible, a diario) para hacer un balance del progreso

del sprint y resolver cualquier conflicto. La colaboración y la receptividad al cambio son

componentes clave del ciclo de vida ágil y una forma probada de mantener el proceso

en marcha de forma eficaz. (Latam, 2022)

Metodologías ágiles más comunes

Las metodologías ágiles son enfoques para el desarrollo de productos que se

ajustan a los valores y principios descritos en el Manifiesto Ágil para el desarrollo de

software. Las metodologías ágiles pretenden ofrecer el producto adecuado, con una

entrega incremental y frecuente de pequeños trozos de funcionalidad, a través de

pequeños equipos multifuncionales autoorganizados, lo que permite la

retroalimentación frecuente del cliente y la corrección del curso según sea necesario.

Con ello, Agile pretende corregir los problemas que plantean los enfoques

tradicionales en «cascada», que consisten en la entrega de grandes productos en largos

periodos de tiempo, durante los cuales los requisitos de los clientes cambian con

frecuencia, lo que hace que se entreguen productos equivocados.

 Principios fundamentales del desarrollo ágil.

Los principios básicos sobre los que se fundamenta el desarrollo ágil son tres.

Individuos y procesos: en primer lugar, el capital humano prima ante los

procesos y herramientas. Por lo tanto, todo el proceso de desarrollo gira en torno a la

satisfacción de las necesidades concretas de los usuarios.

Cliente: por supuesto, la colaboración del cliente en todas y cada una de las

etapas que forman parte del proceso es muy importante. Por lo tanto, la relación entre el

cliente y el equipo de desarrolladores debe estar basada en la confianza mutua.

Adaptación: otro de los principios básicos es la capacidad de adaptación. Es

precisamente el mercado del Siglo XXI uno de los más variables y, además, los cambios

se producen a una velocidad cada vez mayor.

 Así, el desarrollo ágil de software se apoya en la entrega anticipada, realizando

entregas de programas en funcionamiento desde las dos semanas. Además, responde de

forma precisa a los requisitos cambiantes, tanto del mercado como de los clientes. El

principal factor para evaluar su rendimiento es el funcionamiento del software.

Y, por último, cabe destacar la importancia de la simplificación para evitar que

tanto el software como el proceso de desarrollo no sean demasiado complejos.

Aplicación de la Metodología ágil

La metodología ágil, nacida en el desarrollo de software, se ha expandido a

diversas industrias. Su enfoque es responder rápidamente a las necesidades del mercado

y del cliente, entregando valor de manera iterativa en Sprints cortos. Busca minimizar

riesgos y maximizar la satisfacción del cliente. Métodos como Scrum, XP y Kanban,

junto con prácticas técnicas como DevOps, permiten entregas frecuentes y adaptación

continua. Su uso ha crecido considerablemente, proyectándose que se utilice en el 80%

de los proyectos de desarrollo de software. (Sotomayor, 2023)

Cuatro valores centrales del Manifiesto Ágil

Los cuatro valores centrales del Manifiesto Ágil son:

1. Individuos e interacciones por encima de procesos y herramientas:

Destaca la importancia del trabajo en equipo y la comunicación en el

desarrollo de software, reconociendo que la calidad de la interacción

humana es fundamental, independientemente de las herramientas

utilizadas.

2. El software de trabajo por encima de la documentación exhaustiva:

Prioriza el desarrollo de software funcional sobre la creación de

 documentación extensa. Reconoce que la principal meta es ofrecer

beneficios empresariales a través del software.

3. Colaboración con el cliente por encima de la negociación de contratos:

Enfatiza la necesidad de una estrecha colaboración y comunicación

frecuente con los clientes. La comprensión de sus necesidades y la

retroalimentación constante son clave para el éxito.

4. Responder a los cambios en lugar de seguir un plan: Reconoce la

inevitabilidad de los cambios en el desarrollo de software y aboga por la

flexibilidad en los planes de proyecto. Se destaca la capacidad de

adaptación ante las condiciones cambiantes.

12 principios del Manifiesto Ágil

 Nuestra máxima prioridad es satisfacer al cliente mediante la entrega

temprana y continua de software valioso.

 Aceptamos los cambios en los requisitos, incluso en las últimas fases del

desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja

competitiva del cliente.

 Entregar software funcional con frecuencia, desde un par de semanas

hasta un par de meses, con preferencia por la escala de tiempo más corta.

 Los empresarios y los desarrolladores deben trabajar juntos a diario

durante todo el proyecto.

 Construir proyectos en torno a personas motivadas. Dales el entorno y el

apoyo que necesitan, y confía en ellos para que hagan el trabajo.

  El método más eficiente y eficaz para transmitir información a un equipo

de desarrollo y dentro de él es la conversación cara a cara.

 El software en funcionamiento es la principal medida de progreso.

 Los procesos ágiles promueven el desarrollo sostenible. Los

patrocinadores, los desarrolladores y los usuarios deben ser capaces de

mantener un ritmo constante indefinidamente.

 La atención continua a la excelencia técnica y al buen diseño mejora la

agilidad.

 La simplicidad -el arte de maximizar la cantidad de trabajo no realizado-

es esencial.

 Las mejores arquitecturas, requisitos y diseños surgen de equipos

autoorganizados.

 A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, y

luego afina y ajusta su comportamiento en consecuencia. (Desconocido,

Qué es la metodología ágil)

Principales metodologías de desarrollo ágil

Para que las metodologías de desarrollo ágil se puedan considerar como tal, es

requisito imprescindible que cumplan estos cuatro aspectos. Por un lado, los individuos

y las interacciones que llevan a cabo entre ellos son más importantes que los propios

procesos y las herramientas. Por otro lado, prima que el software esté implementado y

funcionando. Además, es importante prestar atención a la colaboración continua con el

cliente. Y, por último, resulta esencial la respuesta adecuada al cambio, adaptándose a

las necesidades cambiantes, tanto del cliente como del mercado. Es decir, hay que

eliminar cualquier tipo de tarea que no sea necesaria.

 Se pueden diferenciar diferentes metodologías de desarrollo ágil, cada una de

ellas con sus propias características y ventajas. En función del proyecto a desarrollar y

de las necesidades concretas del equipo de desarrolladores, se puede optar por una u

otra. (Desconocido, Qué es la metodología ágil)

Tipos de metodologías Ágiles

El objetivo de cada metodología Ágil es adoptar y adaptarse al cambio mientras

entrega software funcional de la manera más eficiente posible. Sin embargo, cada

método varía en la forma en que define los pasos del desarrollo de software. Los

métodos ágiles más utilizados incluyen:

 Scrum

 Desarrollo de software esbelto

 Programación extrema

 Crystal

 Kanban

 Método de desarrollo de sistemas dinámicos

 Desarrollo impulsado por funciones

Scrum: es un marco Ágil liviano que los gerentes de proyectos pueden usar para

controlar todo tipo de proyectos iterativos e incrementales. En Scrum, el propietario del

producto crea una cartera de productos que les permite trabajar con su equipo para

identificar y priorizar la funcionalidad del sistema. La cartera de productos es una lista

de todo lo que se necesita lograr para ofrecer un sistema de software que funcione

correctamente —esto incluye correcciones de errores, características y requisitos no

funcionales. Una vez que se define la cartera de productos, no se puede agregar ninguna

funcionalidad adicional excepto por el equipo correspondiente.

 Una vez que el equipo y el propietario del producto han establecido las

prioridades, los equipos multifuncionales intervienen y acuerdan entregar incrementos

funcionales de software durante cada sprint, a menudo dentro de los 30 días. Después de

cada sprint, la cartera de productos se reevalúa, analiza y prioriza para seleccionar un

nuevo conjunto de funciones entregables para el próximo sprint. Scrum ha ganado

popularidad a lo largo de los años porque es simple, ha demostrado ser productivo y

puede incorporar las diversas prácticas generales promovidas por los otros métodos

Ágiles.
 Ventajas de Scrum Desventajas de Scrum

 Fuerte planificación, con todo el

equipo entendiendo el “qué, por

qué, cómo” de las tareas asignadas

 Alta motivación, ya que el equipo

trabaja para cumplir los plazos de

cada sprint  Una gran concentración en partes

 Alta transparencia que permite el específicas del proyecto puede

seguimiento del proyecto a nivel de hacer que el equipo pierda de vista

equipo e incluso de organización el panorama general

 Valida los requisitos mediante un  Las organizaciones pueden no

método sencillo de “definición de lo definir con detalle el papel de cada

hecho”. miembro, lo que puede generar

 Se centra en garantizar la calidad y confusión.

minimizar los errores

 Prioriza lo flexible, ya que los

propietarios del producto pueden

cambiar el enfoque a sprints

urgentes con frecuencia.

El desarrollo de software: esbelto es otro método iterativo que se centra en el

uso de un mapeo de flujo de valor efectivo para garantizar que el equipo brinde valor al
cliente. Es flexible y cambiante; no tiene pautas o reglas rígidas. El método Lean utiliza

los siguientes principios primarios:

 Incremento del aprendizaje

 Paso de poder al equipo

 Fomento de la integridad

 Eliminación de desechos

 Entendimiento el todo

 Toma de decisiones lo más tarde posible

 Entrega del producto lo más rápido posible

A diferencia de la mayoría de las metodologías de desarrollo de software

que utilizan un ciclo de vida estático, es decir, Planificar-Diseñar-Construir,

 ASD ofrece un ciclo de vida iterativo no lineal, en el que cada ciclo puede iterar

y modificarse mientras se ejecuta otro. Apunta hacia el Desarrollo Rápido de

Aplicaciones (RAD), que hace hincapié en la velocidad de desarrollo para crear

un producto de alta calidad y bajo mantenimiento que implique al usuario lo

máximo posible. Las principales características de ASD son:

 Especular: Es la fase de iniciación del proyecto en la que es necesario

establecer los principales objetivos y metas del proyecto conociendo las

limitaciones (áreas de riesgo) con las que opera el proyecto.

 Colaborar: Es la fase donde se centra la mayor parte del desarrollo,

manteniendo una coordinación entre equipos que asegure que lo aprendido por

un equipo sea comunicado al resto y no tenga que ser aprendido de nuevo por

otros equipos desde cero.

 Aprender: La última etapa termina con una serie de ciclos de colaboración: el

trabajo consiste en captar lo que se ha aprendido, tanto lo positivo como lo

negativo. Esta etapa es fundamental para la eficacia del proyecto.

Método dinámico de desarrollo de software (DSDM)

El Método de Desarrollo Dinámico de Software (DSDM) fue

desarrollado en el año 1994 por un grupo de proveedores y expertos en el campo

del desarrollo de software. El DSDM se centra en proyectos de software

caracterizados por presupuestos y calendarios ajustados. Se centra en la entrega

frecuente de ciclos de productos, y el desarrollo es iterativo e incremental.

 DSDM es un modelo ágil que sin duda puede ayudar a las organizaciones

acostumbradas a trabajar por proyectos a cambiar su mentalidad y su forma de

trabajar para mejorar su capacidad de aportar valor y reducir el tiempo de

comercialización.

Desarrollo orientado a las características (FDD)

La metodología de Desarrollo Dirigido por Características (FDD) está

orientada principalmente a equipos más grandes y con más personas que

aquellos a los que normalmente se aplican otras metodologías ágiles como

Scrum. FDD fue desarrollada por Jeff De Luca y Peter Coad en el año 1997.

Esta metodología se centra en iteraciones cortas, que permiten entregas tangibles

del producto en un periodo corto de tiempo (2 semanas).

 Los proyectos con múltiples equipos y un gran número de personas

representan el reto de que no todos tendrán el mismo talento y disciplina. El

FDD incluye actividades específicas que ayudan a afrontar los retos de

comunicación y coordinación de este tipo de proyectos.

El FDD es un proceso de 5 etapas, de las cuales las 3 primeras son

secuenciales y las dos últimas son iterativas (como se muestra en el diagrama

anterior). Todas las metodologías ágiles siguen una serie de principios que hacen

que se parezcan entre sí. Sin embargo, FDD ofrece soluciones sobre cómo

organizar el equipo y cómo programar el código, lo que la hace especialmente

viable para grandes equipos de desarrollo que construyen software complejo.

Uno de los libros más populares sobre el método FDD fue publicado por

Stephen Palmer en 2002, titulado “A Practical Guide to Feature-Driven

Development“.
 El método Lean: se basa en una retroalimentación rápida y confiable entre los

clientes y los programadores para proporcionar flujos de trabajo de desarrollo rápidos y

eficientes. Para lograr esto, proporciona a los individuos y equipos pequeños autoridad

para tomar decisiones en lugar de depender de un flujo de control jerárquico. Para

eliminar el desperdicio, el método Lean pide a los usuarios que solo seleccionen

características verdaderamente valiosas para su sistema, prioricen estas características

elegidas y luego las entreguen en lotes pequeños. El desarrollo de software ajustado

también fomenta que las pruebas unitarias automatizadas se escriban simultáneamente

con el código y se concentra en garantizar que cada miembro del equipo sea lo más

productivo posible.

Sus siete principios fundamentales son:

1. Eliminar sin ninguna consideración todo lo que no importa para la

calidad del producto

2. Centrarse en el desarrollo de la calidad

3. Crear conocimiento a través de una valiosa documentación

4. No planificar el desarrollo sin una comprensión completa de los

requisitos del negocio

5. Ofrecer valor al cliente lo antes posible

6. Se comunica con regularidad, gestiona los conflictos con rapidez y

desarrolla una cultura de respeto

7. Por último, no se centra en la optimización parcial y se asegura de que

toda la aplicación sea de alta calidad

 Ventajas de Lean Desventajas de Lean

 Minimiza el tiempo y el dinero  Depende en gran medida de

invertido miembros del equipo dedicados

 Aumenta la motivación al y con talento

informar al equipo durante el  La división de las tareas en

proceso de toma de decisiones subtareas puede dificultar la

 Muy adaptable y escalable concentración.

 Minimiza el riesgo de sobre  Es relativamente pesado en

ingeniería cuanto a la documentación.

El método de programación extrema (XP): es un enfoque disciplinado que se

centra en la velocidad y la entrega continua. Promueve una mayor participación del

cliente, ciclos rápidos de retroalimentación, planificación y pruebas continuas y trabajo

en equipo cercano. El software se entrega a intervalos frecuentes — generalmente cada

una a tres semanas. El objetivo es mejorar la calidad y la capacidad de respuesta del

software ante los requisitos cambiantes de los clientes.

 El método XP se basa en los valores de comunicación, retroalimentación,

sencillez y valentía. Los clientes trabajan en estrecha colaboración con su equipo de

desarrollo para definir y priorizar las historias de usuario solicitadas. Sin embargo,

depende del equipo entregar las historias de usuario de mayor prioridad en forma de

software funcional que se haya probado en cada iteración. Para maximizar la

productividad, el método XP proporciona a los usuarios un marco ligero y de apoyo que

los guía y ayuda a garantizar el lanzamiento de software empresarial de alta calidad.

Ventajas de XP Desventajas de XP

 Código simplificado que se  La gran atención que se presta

puede mejorar en iteraciones al código puede hacer que se

posteriores preste menos atención al diseño,

 Un ciclo de desarrollo convirtiéndolo en una tarea

transparente y una gran separada en lugar de formar

 visibilidad del proceso conducen parte de los requisitos originales

a una fijación de objetivos  La falta de atención a la

eficiente y a resultados rápidos documentación de las pruebas

 Gran agilidad de desarrollo puede hacer que se repitan

gracias a las pruebas continuas errores similares

 Fomenta el trabajo enérgico y  No es ideal para los equipos que

fomenta el talento trabajan a distancia

Crystal: es la metodología más ligera y adaptable. Se enfoca en las personas y

las interacciones que ocurren mientras se trabaja en un proyecto Agile, así como en la

importancia comercial y la prioridad del sistema en desarrollo. El método Crystal se

basa en la constatación de que cada proyecto posee características únicas que requieren

un conjunto de políticas, prácticas y procesos ligeramente adaptados. Como resultado,

se compone de una colección de modelos de procesos Ágiles, como Crystal Orange,

Crystal Clear y Crystal Yellow. Cada modelo tiene sus propias características únicas que

son impulsadas por diferentes factores, incluidas las prioridades del proyecto, el tamaño

del equipo y la criticidad del sistema.

Al igual que otras metodologías Ágiles, Crystal enfatiza la entrega frecuente de

software de trabajo con alta participación del cliente, adaptabilidad y eliminación de

burocracia y distracciones. Sus principios clave incluyen la comunicación, el trabajo en

equipo y la sencillez.

Kanban: utiliza un método de administración de flujo de trabajo altamente

visual que permite a los equipos administrar activamente la creación de productos —

enfatizando la entrega continua— sin crear más estrés en el ciclo de vida de desarrollo
de software (SDLC). Se ha vuelto popular entre los equipos que también practican el

desarrollo de software Lean.

Kanban utiliza tres principios básicos: visualizar el flujo de trabajo; limitar la

cantidad de trabajo en curso; y mejorar el flujo de trabajo. Similar al Scrum, el método

Kanban está diseñado para ayudar a los equipos a trabajar de manera más eficiente entre

sí. Fomenta la colaboración continua e intenta definir el mejor flujo de trabajo posible

para promover un entorno con aprendizaje y mejora activos y continuos.

El método de desarrollo de sistemas dinámicos (DSDM) es una respuesta a la

necesidad de un marco industrial común para la entrega rápida de software. El DSDM

se basa en ocho principios clave; El incumplimiento de cualquiera de los principios

presenta un riesgo para la finalización exitosa del proyecto. Los ocho principios son:

 Colaboración

 Tiempo de entrega

 Control demostrado

 Comunicación clara y continua

 Un enfoque constante en las necesidades comerciales

 Desarrollo iterativo

 Creación en incrementos a partir de cimientos firmes

 Negativa a comprometer la calidad

En el DSDM, el retrabajo está integrado en el proceso y todos los cambios deben

ser reversibles. Los requisitos del sistema se priorizan utilizando las reglas de

MoSCoW, que clasifican la prioridad como:

 M - debe tener
  S - debería tener

 C - podría haberlo tenido, pero no es crítico

 W - no lo tendrá ahora, pero podría tenerlo más tarde

Es importante para el DSDM que no todos los requisitos se consideren críticos.

Cada iteración debe incluir elementos menos críticos que se puedan eliminar para que

los requisitos de mayor prioridad no se vean afectados (Silverthorner)

Ventajas de Kanban Desventajas de Kanban

 Fácil de usar  La falta de plazos puede

 Ve todas las tareas de un proyecto al provocar retrasos

mismo tiempo, según su categoría  Los datos pueden ser

(realizadas, en proceso, en pruebas, malinterpretados,

etc.) especialmente si no se

 Controla el número de tareas en las actualizan con frecuencia

que se trabaja en función de la

 prioridad

 Una duración transparente del ciclo:

desde la cartera de pedidos hasta la

finalización

 Impulsa la entrega continua

Desarrollo basado en el comportamiento (BDD)

El Desarrollo Orientado al Comportamiento (BDD) es una metodología de

desarrollo ágil orientada al comportamiento. Fue creada por Dan North en 2003 como

una evolución de la metodología TDD. Dan North pretendía que las personas no

técnicas participaran en el proceso de creación de la funcionalidad técnica del sistema.

Ocurre que cuando desarrollamos software, involuntariamente no incluimos los

conceptos de negocio presentes en la funcionalidad, lo que da lugar a un posible flujo de

errores recurrentes e incluso graves.

 BDD utiliza conceptos de lenguaje universal que fomentan la colaboración entre

personas con o sin conocimientos técnicos en un proyecto de software. El proceso de

desarrollo BDD se basa en la redacción de escenarios de prueba y características. Éstos

contienen los requisitos y los criterios de aceptación del comportamiento del sistema.

Indican qué necesita la funcionalidad para ponerse en marcha, qué hará a continuación y

cuáles serán los resultados tras su ejecución.

BDD ayuda a los equipos a comunicar con mayor precisión los requisitos, a

descubrir los defectos con antelación y a construir un software que siga siendo

sostenible en el tiempo.

Existe una gran variedad de modelos y metodologías de desarrollo basados en

los principios de Ágil. En los últimos años, ha aumentado la lista de organizaciones que

atribuyen a esta metodología su éxito. Algunos de los nombres más importantes de los

medios de comunicación, la tecnología, las finanzas e incluso algunos organismos del

Gobierno nacional han adoptado y alabado la eficacia de Ágil.

Roles, prácticas y artefactos clave en el desarrollo ágil.

La incorporación de la metodología agile en las organizaciones trajo aparejada el

surgimiento de nuevas posiciones laborales y la redefinición de puestos y funciones

preexistentes que debieron reconfigurarse. Veamos cuales son:

 Agile Coach

Entre los nuevos roles, se destaca el Agile Coach, una posición con autoridad y

seniority organizacional, que trasciende a los marcos de trabajo y las herramientas, y

que cuenta con los atributos para proveer dirección y foco la dinámica de los equipos.

¿En qué se enfoca el Agile Grand Coach?

 El agile coach se focaliza en:

los resultados de negocio.

la efectividad para conseguirlos (en términos de uso de recursos y tiempos de

entrega).

la motivación y satisfacción profesional de quienes trabajan en el equipo.

¿Cuáles son las competencias para ser Agile Grand Coach?

Entre las competencias que no pueden faltar en el desempeño profesional de este

perfil se destacan:

 la conversación individual (cara a cara, presencial o virtualmente),

 la indagación,

 la escucha activa,

 considerar al aprendizaje como un valor esencial e irremplazable

(tomando al error como una oportunidad de crecimiento),

 provocar atractivos para que una persona realice acciones motivado en

lugar de empujarlo a hacerlas obligado,

 la gestión de acuerdos para materializar expectativas.

En definitiva, un agile coach es un líder profundo, memorable, que se deja

conocer y conoce integralmente a su equipo y a cada persona, en ocasiones más de los

que se conocen ellos mismos.

 Scrum Master
 SCRUM es el framework de gestión ágil de proyectos de mayor crecimiento,

basado en un proceso iterativo e incremental con entregas de valor temprano, y centrado

en potenciar a los integrantes del proceso y sus interacciones, para lograr los objetivos

propuestos.

Un principio clave de Scrum reside en entender que durante un proyecto los

clientes pueden cambiar de idea sobre lo que quieren o necesitan y, en consecuencia, los

objetivos no necesariamente pueden ser enfrentados de una forma anticipada y

planificada.

El Scrum Master desempeña el rol de coach del equipo desarrollo y del dueño de

producto, es un maestro y mentor de las prácticas Scrum. Destraba frenos del equipo, es

protector, facilita la comunicación y la disponibilidad de recursos, y resuelve conflictos

y problemas para entregar el máximo valor al cliente.

¿Cuáles son las funciones de un Scrum Master?

Algunas de sus funciones propias son:

 Liderar los equipos ágiles, eliminando trabas y obstáculos.

 Garantizar que se alcancen los objetivos marcados en el sprint

 Asegurar que se sigan las pautas marcadas en el modelo scrum.

 Realizar la lista de tareas a desarrollar (product backlog)

 Asignar tareas a los miembros del equipo (sprint backlog)

 Intermediar entre el cliente (o Product Owner) y el equipo scrum.

 Facilitar las reuniones scrum, organizándolas y dirigiéndolas.

  Comprender las necesidades y herramientas para

implementar metodologías y marcos de trabajo ágiles a lo largo de la

organización

 Hacer coaching con el equipo, aportando herramientas para la

autogestión y formulando preguntas para que cada miembro encuentre la

solución.

 Entregar un resultado útil al cliente y finalizar de manera exitosa el

proyecto.

 Entre las principales hard skills específicas que hoy se solicitan en los

procesos de reclutamiento orientados a personas que tengan como

objetivo cubrir puestos de Scrum Master se destaca conocer:

 conceptos más avanzados sobre SCRUM y el proceso en todo su ciclo de

vida y funcionamiento.

 elementos de Release, Product Backlog, Sprint, y otros artefactos del

framework SCRUM.

 herramientas que facilitan el cambio organizacional hacia una cultura

ágil

 frameworks más comunes de ágil escalado, por ejemplo, SAFe y LeSS.

 mejores técnicas y herramientas para la gestión ágil de equipos.

 Adicionalmente, tener la certificación Certified SCRUM Master (CSM).

 Product Owner

También denominado Propietario, Dueño o Guardián de Producto, representa a

los stakeholders y su foco es entender que es lo que da más valor al negocio a través de

entender el producto y su entorno, guiando su desarrollo a partir de:

  la determinación del producto que se debe construir

 la secuencia en la que se debe acometer.

en Scrum, el Product Owner debe maximizar el valor del producto desarrollado

por el Equipo de Desarrollo (Scrum Team).

¿Cuáles son las responsabilidades del product owner?

Sus responsabilidades incluyen:

 El retorno de inversión del proyecto.

 Gestionar el Product Backlog en su totalidad, ordenando y priorizando

las tareas para alcanzar los objetivos de la mejor forma.

 Optimizar el valor del trabajo del Equipo.

 Asegurarse de que el Product Backlog sea visible, transparente y claro

para todos.

“Para la mayoría de las empresas que se mudan a Agile, este es un rol nuevo y

crítico, que generalmente se traduce en un trabajo de tiempo completo”, advierten desde

Scale Agile, Inc, agregando que el rol tiene relaciones y responsabilidades significativas

fuera del equipo al cual está relacionado.

El rol del product owner es crítico y generalmente se traduce en un trabajo de

tiempo completo.

Por ello, en Scrum.org enfatizan que para que los Product Owners tengan éxito,

toda la organización debe respetar sus decisiones.

 Equipo de Desarrollo
 En Scrum, el Development Team contempla varios roles con diversas

responsabilidades. Sus miembros asumen las responsabilidades interfuncionales

necesarias para transformar una idea o un requisito en un producto tangible para los

usuarios finales.

¿Cuáles son los perfiles del equipo de desarrollo?

Entre los perfiles que lo integran se encuentra a los siguientes:

 Diseñador de producto

 Escritor

 Programador

 Tester

 Especialista en experiencia de usuario

Además de las habilidades que facilitan el desarrollo de productos, los miembros

del Team también deben contar con habilidades blandas para autoorganizarse y que

cuando ocurra un problema, el equipo es capaz y esté facultado para tomar medidas

correctivas.

Los miembros del Team también deben contar con habilidades para

autoorganizarse y que, cuando ocurra un problema, el equipo es capaz para tomar

medidas correctivas.

Para BMC, las responsabilidades clave del Equipo de Desarrollo son realizar

sprints de trabajo según los requisitos proporcionados por el Product Owner y

coordinados por el Scrum Master.

El Team también participa de una reunión regular (Daily Scrum) para comunicar

el progreso del proyecto con los compañeros y el Scrum Master, garantizando de esta
manera la transparencia y permitiendo que el equipo de desarrollo incorpore los

cambios necesarios en futuros sprints, en función de los comentarios del propietario del

producto.

 Product Manager

El Product Manager es el responsable de gestionar el ciclo de vida de un

producto o una línea de productos, con análisis, planificación y ejecución, y el objetivo

de maximizar ventas e ingresos, incrementar la cuota de mercado y extender los

márgenes de beneficio.

Su relevancia en el mercado laboral se ha incrementado en los últimos tiempos

debido a que estamos inmersos en un mercado más orientado a productos que a

proyectos, con nuevos actores, herramientas innovadoras, modelos de negocio distintos,

reglas novedosas y un cambio de hábitos de consumo.

El escenario actual requiere de profesionales altamente capacitados en product

management para resolver eficientemente necesidades y desafíos, cada vez más

complejos y dinámicos y enfrentar la gestión de proyectos ágiles.

¿Cuáles son las funciones de un Product Manager?

Entre las principales funciones que debe desarrollar un Product Manager para

cumplir con las responsabilidades de la posición, se destacan las siguientes:

 Liderar a su equipo durante todo el ciclo de vida del producto,

coordinando y estableciendo una escala de prioridades para la realización

de actividades estratégicas y tácticas, tendientes a su diseño, producción,

comercialización y distribución.
 Identificar una necesidad de mercado, y en función de ella, evaluar el

nicho de oportunidad y determinar la conveniencia de desarrollar un

nuevo producto o mejorar/reelaborar una preexistente, para resolver un

punto de dolor o un aspiracional de sus potenciales clientes objetivos.

 Generar la idea o desarrollar la oportunidad de negocio, y análisis del

mercado y del cliente para determinar la viabilidad de la propuesta.

 Elaborar la estrategia, definición, planificación, diseño, creación y

desarrollo de productos, manteniendo un contacto constante con todo su

ciclo, para responder a las necesidades de cada etapa, resolviendo

eventuales problemas e implementando mejoras.

 Colaborar con el diseño y creación del producto. En las empresas

tecnológicas se debe involucrar con el departamento de software.

 Realización del test de producto e incorporación de ajustes y mejoras

para optimizarlo.

 Diseño del plan de marketing y gestión del lanzamiento, alineando a

todos las áreas y equipos de la empresa involucrados.

 Capacitación en la utilización del producto.

 Definir los requisitos indispensables para que la experiencia de

usuario sea óptima y cada cliente vea resuelta sus expectativas en

función de la promesa de satisfacción de cada producto.

 Atender especialmente al cumplimiento de los estándares de calidad.

 Hacer seguimiento del soporte y atención que se le brinda al cliente,

tanto en la etapa de comercialización como en la post-venta.

 Analizar los resultados/ventas, y en función de ello gestionar mejoras o

incidencias.
  Obtener la mayor rentabilidad e ingresos posibles.

 En todas y cada una de las funciones descriptas, tomar decisiones

informadas y fundamentadas.

 Se trata de una posición de liderazgo con incidencia directa y

determinante en el éxito que pueda alcanzar un producto.

 PRACTICAS

La metodología Agile prioriza objetivos más pequeños y escalables con el

tiempo que el lanzamiento de grandes productos. Además, su equipo evalúa

periódicamente tanto tarea como procesos para la mejora tanto de productos como sus

rendimientos. En la actualidad, encontramos diferentes metodologías como Scrum,

Lean, Extreme Programming (XP)… unificadas bajo el paraguas de Agile. Sin embargo,

es importante tener en cuenta ciertas prácticas que ayudan a crear un desarrollo de

software Agile eficaz y más competitivo.

Un cliente involucrado en cada etapa

En el desarrollo de software tradicional, el cliente prácticamente solo se implica

en dos partes del proceso: al inicio, a la hora de recopilar información y poner ideas en

común, y al final, cuando se prueba el producto.

Esto cambia con Agile, donde el cliente se involucra en todas y cada una de las

etapas lo que garantiza que el producto final realmente satisfaga las necesidades del

usuario final. También ayuda a que los desarrolladores pueden hacer ajustes durante el

mismo proceso en vez de esperar al final.

Reuniones diarias

Las reuniones diarias son, por ejemplo, habituales en la metodología Scrum,

aunque otras metodologías de Agile emplean alguna que otra variación. Los controles
diarios consisten en una breve reunión de no más de 15 minutos para que cada miembro

del equipo pueda actualizar a todos los demás sobre en qué están trabajando ese día.

Una opción para fomentar la colaboración y la transparencia en el equipo, reducir la

duplicación de trabajo y evitar problemas de comunicación. También ayuda a cumplir

con el calendario de trabajo.

Una mayor comunicación en equipo

Uno de los objetivos de Agile es fomentar una comunicación más constante y

productiva. Mejores prácticas de comunicación que han ido avanzando al mismo tiempo

que lo ha hecho el trabajo híbrido y remoto. Sus desarrolladores siguen trabajando en

ello pese a que el equipo se encuentre ubicado en varias zonas horarias.

Priorización de tareas

Decidir qué tareas completar y en qué orden es un aspecto esencial del desarrollo

Agile. Hay muchos métodos diferentes para establecer estas prioridades como

MoSCoW (Must-haves, Should-haves, Could-haves, Won’t-haves) y first-in/first-out.

Lo ideal es elegir -o descartar- varios según las necesidades de cada proyecto.

Configuración de Sprint

Los sprints son períodos de tiempo limitado durante los cuales un equipo intenta

completar un conjunto definido de tareas. Éstas se asignan en orden de la más

importante a la menos importante, y cada miembro del equipo tiene un conjunto de

responsabilidades alineadas con cada tarea. Antes es importante identificar aquellas

tareas que no se pueden realizar hasta que se complete otra tarea anterior para evitar

cuellos de botella. Una vez que se completa el sprint, el equipo debe tener una reunión

retrospectiva para identificar qué funcionó y qué no.

 En definitiva, la metodología Agile ayuda a una mejor colaboración, reuniones

eficientes, una comunicación más productiva, la priorización de tareas estratégicas y la

estructuración de sprints. (Delgado, 2022)

 ARTEFACTOS

Los principales artefactos del scrum ágil son el backlog del producto, el backlog

de sprint y los incrementos.

A menudo, el término “artefacto” se asocia a ruinas arqueológicas y reliquias

antiguas.

¿Qué son los artefactos del scrum ágil?

Los artefactos del scrum ágil son información que un equipo de scrum y las

partes interesadas utilizan para detallar el producto en desarrollo, las acciones para

producirlo y las tareas realizadas durante el proyecto. Estos artefactos ofrecen metadatos

que dan una idea del rendimiento de un sprint. Son herramientas esenciales para todos

los equipos de scrum, ya que posibilitan los atributos básicos de transparencia,

inspección y adaptación.

Los artefactos se crean durante las actividades principales de un sprint de scrum:

 Planificación del trabajo y futuros objetivos

 Creación de tareas para lograr estos objetivos

 Organización de las tareas en sprints en función de las dependencias y la

prioridad

 Realización de las tareas

 Revisión y análisis de los resultados para compararlos con los objetivos

 Repetición de estos pasos

 Principales artefactos del scrum ágil

Los principales artefactos del scrum ágil son el backlog del producto, el backlog

de sprint y los incrementos.

Backlog del Producto:

Es una lista dinámica de requisitos y tareas necesarias para el producto.

Mantenida por el propietario del producto y actualizada con nueva información.

Contiene elementos que han sido parte de sprints anteriores y tareas que han

dejado de ser prioritarias.

Backlog de Sprint:
 Subset del backlog del producto seleccionado para desarrollarse en el siguiente

incremento.

Creado durante la planificación del sprint y dividido en tareas manejables.

Se actualiza durante la planificación de sprints según la capacidad del equipo y

prioridades cambiantes.

Incremento del Producto:

Es la entrega al cliente al completar tareas del backlog del producto durante un

sprint.

Incluye los incrementos de todos los sprints anteriores.

Decidido durante la planificación de Scrum y se entrega al cliente al finalizar el

sprint.

Artefactos Ampliados:

Además de los artefactos oficiales, hay artefactos ampliados como el Diagrama

de Evolución y la Definición de "Hecho".

Diagrama de Evolución:

No es oficial, pero muchos equipos lo utilizan para visualizar y comunicar el

progreso durante el sprint.

Ayuda a medir la velocidad del equipo y ajustar estimaciones basándose en

experiencias anteriores.

Definición de "Hecho:

Define claramente lo que se considera finalizado.

 Documenta y comparte las condiciones de finalización, como pruebas

automatizadas y despliegue en producción. Cómo Utilizarlos:

 Planificación y Creación:

 Durante la planificación, selecciona y organiza tareas en el Backlog del

Producto.

 Crea Backlogs de Sprint dividiendo tareas para el siguiente incremento.

 Realización de Tareas:

 Desarrolla tareas durante el sprint y asegúrate de cumplir con la

Definición de "Hecho".

 Revisión y Análisis:

 Al finalizar el sprint, revisa y analiza los resultados frente a los objetivos.

 Actualización y Repetición:

 Actualiza Backlogs según la retroalimentación y aprendizajes del sprint.

 Repite el ciclo en los siguientes sprints.

 Importancia de la Transparencia:

Todos los equipos deben tener acceso y visibilidad a los artefactos para mejorar

la eficiencia.

Revisiones regulares con propietarios del producto y expertos en Scrum ayudan

a identificar ineficiencias y mejorar la velocidad.

Utiliza herramientas de gestión ágil que integren automáticamente estos

artefactos. Fomenta la colaboración constante entre miembros del equipo y partes

interesadas. Ajusta procesos basándote en retroalimentación acumulada durante los

sprints.
 En el desarrollo ágil, la correcta implementación de roles, prácticas y artefactos

es esencial para el éxito del proyecto. Estos elementos proporcionan una estructura

organizativa clara, promueven la comunicación efectiva y aseguran la entrega continua

de valor al cliente. Su uso adecuado no solo impulsa la eficiencia operativa, sino que

también permite la adaptabilidad frente a cambios y la mejora constante, aspectos

críticos en un entorno empresarial dinámico (HARRIS)

2. Desarrollo de Software Orientado a Objetos (OO) Enfoque, conceptos

básicos

Cuando se va a construir un sistema software es necesario conocer un lenguaje

de programación, pero con eso no basta. Si se quiere que el sistema sea robusto y

mantenible es necesario que el problema sea analizado y la solución sea cuidadosamente

diseñada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si

se sigue un proceso de desarrollo que se ocupa de plantear cómo se realiza el análisis y

el diseño, y cómo se relacionan los productos de ambos, entonces la construcción de

sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un

sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente

cuando se trata de un equipo de desarrollo formado por varias personas. Para este curso

se va a seguir el método de desarrollo orientado a objetos que propone Craig Larman

[Larman99]. Este proceso no fija una metodología estricta, sino que define una serie de

actividades que pueden realizarse en cada fase, las cuales deben adaptarse según las

condiciones del proyecto que se esté llevando a cabo. Se ha escogido seguir este

proceso debido a que aplica los últimos avances en Ingeniería del Software, y a que

adopta un enfoque eminentemente práctico, aportando soluciones a las principales

dudas y/o problemas con los que se enfrenta el desarrollador. Su mayor aportación

consiste en atar los cabos sueltos que anteriores métodos dejan. La notación que se usa
para los distintos modelos, tal y como se ha dicho anteriormente, es la proporcionada

por UML, que se ha convertido en el estándar de facto en cuanto a notación orientada a

objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo

a nuevos miembros y compartir con otros equipos la documentación, pues es de esperar

que cualquier desarrollador versado en orientación a objetos conozca y use UML (o se

esté planteando su uso). Se va a abarcar todo el ciclo de vida, empezando por los

requisitos y acabando en el sistema funcionando, proporcionando así una visión

completa y coherente de la producción de sistemas software. El enfoque que toma es el

de un ciclo de vida iterativo incremental, el cual permite una gran flexibilidad a la hora

de adaptarlo a un proyecto y a un equipo de desarrollo específicos. El ciclo de vida está

dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los

futuros usuarios del mismo. Así no se pierde de vista la motivación principal que

debería estar en cualquier proceso de construcción de software: el resolver una

necesidad del usuario/cliente.

Visión General

El proceso a seguir para realizar desarrollo orientado a objetos es complejo,

debido a la complejidad que nos vamos a encontrar al intentar desarrollar cualquier

sistema software de tamaño medio-alto. El proceso está formado por una serie de

actividades y subactividades, cuya realización se va repitiendo en el tiempo aplicado a

distintos elementos. En este apartado se va a presentar una visión general para poder

tener una idea del proceso a alto nivel, y más adelante se verán los pasos que componen

cada fase. Las tres fases al nivel más alto son las siguientes:

 Planificación y Especificación de Requisitos: Planificación,

definición de requisitos, construcción de prototipos, etc.

  Construcción: La construcción del sistema. Las fases dentro de esta

etapa son las siguientes:

 Análisis: Se analiza el problema a resolver desde la perspectiva de los

usuarios y de las entidades externas que van a solicitar servicios al

sistema.

 Diseño: El sistema se especifica en detalle, describiendo cómo va a

funcionar internamente para satisfacer lo especificado en el análisis.

 Implementación: Se lleva lo especificado en el diseño a un lenguaje de

programación.

 Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el

software funciona correctamente y que satisface lo especificado en la

etapa de Planificación y Especificación de Requisitos

 Instalación: La puesta en marcha del sistema en el entorno previsto de

uso. De ellas, la fase de Construir es la que va a consumir la mayor parte

del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a

cabo se va adoptar un enfoque iterativo, tomando en cada iteración un

subconjunto de los requisitos (agrupados según casos de uso) y

 llevándolo a través del análisis y diseño hasta la implementación y

pruebas. El sistema va creciendo incrementalmente en cada ciclo. Con

esta aproximación se consigue disminuir el grado de complejidad que se

trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema

funcionando que se puede contrastar con el usuario/cliente.

Fase de Planificación y Especificación de Requisitos

Esta fase se corresponde con la Especificación de Requisitos tradicional

ampliada con un Borrador de Modelo Conceptual y con una definición de Casos de Uso

de alto nivel. En esta fase se decidiría si se aborda la construcción del sistema mediante

desarrollo orientado a objetos o no, por lo que, en principio, es independiente del

paradigma empleado posteriormente.

Las actividades de esta fase son las siguientes:

1. Definir el Plan.

2. Crear el Informe de Investigación Preliminar.

3. Definir los Requisitos.

4. Registrar Términos en el Glosario.

5. Implementar un Prototipo.

6. Definir Casos de Uso.

7. Definir el Modelo Conceptual.

8. Definir la Arquitectura del Sistema. 9. Refinar el Plan.

El orden propuesto es el que parece más lógico, y en él los pasos 5 y 7 pueden

estar en posiciones distintas. De todos modos, el orden no es estricto, lo normal es que

las distintas actividades se solapen en el tiempo. Esto sucede también en las actividades

de las fases de Análisis y de Diseño, que se verán más adelante. De estas actividades no

se va a entrar en las que corresponden al campo de la planificación de proyectos

software, como las correspondientes a creación de planes e informes preliminares. Tan

solo se va a ver por encima la actividad de Definición de Requisitos en cuanto está

relacionada con los Casos de Uso, pues son éstos los que van a servir de punto de

partida en el Análisis Orientado a Objetos.

Requisitos Un requisito es una descripción de necesidades o aspiraciones

respecto a un producto. El objetivo principal de la actividad de definición de requisitos

consiste en identificar qué es lo que realmente se necesita, separar el grano de la paja.

Esto se hace en un modo que sirva de comunicación entre el cliente y el equipo de

desarrollo. Es aconsejable que un documento de Especificación de Requisitos tenga los

siguientes puntos:

Propósito.

Ámbito del Sistema, Usuarios.

Funciones del Sistema.

Atributos del Sistema.

El formato del documento de Especificación de Requisitos no está definido en

UML, pero se ha incluido este punto para resaltar que la actividad de definición de

requisitos es un paso clave en la creación de cualquier producto software. Para refinar

los requisitos y mejorar la comprensión de los mismos la técnica de casos de uso

constituye una valiosa ayuda.

 Casos de Uso: Un Caso de Uso es un documento narrativo que describe la

secuencia de eventos de un actor (un agente externo) que usa un sistema para completar

un proceso [Jacobson92]. Es una historia o una forma particular de usar un sistema. Los

casos de uso no son exactamente requisitos ni especificaciones funcionales, pero

ilustran e implican requisitos en las historias que cuentan. En la página 9 se definió la

notación de UML para los Diagramas de Casos de Uso. Nótese que UML no define un

formato para describir un caso de uso. Tan sólo define la manera de representar la

relación entre actores y casos de uso en un diagrama (Diagrama de Casos de Uso). El

formato textual que se va a usar en este texto para definir los casos de uso se va a definir

a continuación, mientras que la representación de los escenarios correspondientes a un

caso de uso por medio de Diagramas de Secuencia se verá más adelanté. En un primer

momento interesa abordar un caso de uso desde un nivel de abstracción alto, es lo que

se denomina Caso de Uso de Alto Nivel.

Construcción del Modelo de Casos de Uso Para construir el Modelo de Casos

de Uso en la fase de Planificación y Especificación de Requisitos se siguen los

siguientes pasos:

1. Después de listar las funciones del sistema, se definen los límites del sistema

y se identifican los actores y los casos de uso.

2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan

como primarios, secundarios u opcionales.

3. Se dibuja el Diagrama de Casos de Uso.

4. Se relacionan los casos de uso y se ilustran las relaciones en el Diagrama de

Casos de Uso.
 5. Los casos de uso más críticos, importantes y que conllevan un mayor riesgo,

se describen en el formato expandido esencial. Se deja la definición en formato

expandido esencial del resto de casos de uso para cuando sean tratados en posteriores

ciclos de desarrollo, para no tratar toda la complejidad del problema de una sola vez.

6. Se crean casos de uso reales sólo cuando: · Descripciones más detalladas

ayudan significativamente a incrementar la comprensión del problema. · El cliente pide

que los procesos se describan de esta forma.

7. Ordenar según prioridad los casos de uso.

Planificación de Casos de Uso según Ciclos de Desarrollo: La decisión de qué

partes del sistema abordar en cada ciclo de desarrollo se va a tomar basándose en los

casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementación de

uno o más casos de uso, o versiones simplificadas de casos de uso. Se asigna una

versión simplificada cuando el caso de uso completo es demasiado complejo para ser

tratado en un solo ciclo

 Para tomar la decisión de qué casos de uso se van a tratar primero es necesario

ordenarlos según prioridad. Las características de un caso de uso específico que van a

hacer que un caso de uso tenga una prioridad alta son las siguientes:

a. Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta

muchas clases al modelo del dominio o requiere persistencia en los datos.

b. Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo

relativamente bajo.

c. Incluye funciones complejas, críticas en el tiempo o de nivel elevado de

riesgo.

d. Implica bien un trabajo de investigación significante, o bien el uso de una

tecnología nueva o arriesgada.

e. Representa un proceso de gran importancia en la línea de negocio.

f. Supone directamente un aumento de beneficios o una disminución de costes.

Para realizar la clasificación se puede asignar a cada caso de uso una valoración

numérica de cada uno de estos puntos, para conseguir una puntuación total aplicando

pesos a cada apartado. En la siguiente tabla se muestra un ejemplo de tal tipo de

clasificación:
 Fase de Construcción: Análisis

En la fase de Análisis de un ciclo de desarrollo se investiga sobre el problema,

sobre los conceptos relacionados con el subconjunto de casos de uso que se esté

tratando. Se intenta llegar a una buena comprensión del problema por parte del equipo

de desarrollo, sin entrar en cómo va a ser la solución en cuanto a detalles de

implementación. Cuando el ciclo de desarrollo no es el primero, antes de la fase de

Análisis hay una serie de actividades de planificación. Estas actividades consisten en

actualizar los modelos que se tengan según lo que se haya implementado, pues siempre

se producen desviaciones entre lo que se ha analizado y diseñado y lo que finalmente se

construye. Una vez se tienen los modelos acordes con lo implementado se empieza el

nuevo ciclo de desarrollo con la fase de Análisis. En esta fase se trabaja con los modelos

de Análisis construidos en la fase anterior, ampliándolos con los conceptos

correspondientes a los casos de uso que se traten en el ciclo de desarrollo actual.

Las actividades de la fase de Análisis son las siguientes:

1. Definir Casos de Uso Esenciales en formato expandido.

2. Refinar los Diagramas de Casos de Uso.

3. Refinar el Modelo Conceptual.

4. Refinar el Glosario.

5. Definir los Diagramas de Secuencia del Sistema.

6. Definir Contratos de Operación.

7. Definir Diagramas de Estados

Modelo Conceptual
 Una parte de la investigación sobre el dominio del problema consiste en

identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar

un Diagrama de Estructura Estática de UML, al que se va a llamar Modelo Conceptual.

En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no

de componentes software. El objetivo de la creación de un Modelo Conceptual es

aumentar la comprensión del problema. Por tanto, a la hora de incluir conceptos en el

modelo, es mejor crear un modelo con muchos conceptos que quedarse corto y olvidar

algún concepto importante.

Creación del Modelo Conceptual Para crear el Modelo Conceptual se siguen los

siguientes pasos:

1. Hacer una lista de conceptos candidato usando la Lista de Categorías de

Conceptos de la Tabla 1 y la búsqueda de sustantivos relacionados con los requisitos en

consideración en este ciclo.

2. Representarlos en un diagrama.

3. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos

que es necesario conocer.

4. Añadir los atributos necesarios para contener toda la información que se

necesite conocer de cada concepto.

Identificación de Atributos: Es necesario incorporar al Modelo Conceptual los

atributos necesarios para satisfacer las necesidades de información de los casos de uso

que se estén desarrollando en ese momento. Los atributos deben tomar valor en tipos

simples (número, texto, etc.), pues los tipos complejos deberían ser modelados como

conceptos y ser relacionados mediante asociaciones. Incluso cuando un valor es de un

tipo simple es más conveniente representarlo como concepto en las siguientes

ocasiones:

Se compone de distintas secciones. Por ejemplo: un número de teléfono, el

nombre de una persona, etc. ·

 Tiene operaciones asociadas, tales como validación. Ejemplo: NIF.

 Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha

de fin.

 Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en

pesetas o en euros.

Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo

no es un modelo definitivo, pues a lo largo del Análisis y del Diseño se va refinando

según se le añaden conceptos que se habían pasado por alto.

 Diagramas de Secuencia del Sistema Además de investigar sobre los conceptos

del sistema y su estructura, también es preciso investigar en el Análisis sobre el

comportamiento del sistema, visto éste como una caja negra. Una parte de la

descripción del comportamiento del sistema se realiza mediante los Diagramas de

Secuencia del Sistema.

 Fase de Construcción: Diseño En la fase de Diseño se crea una solución a nivel

lógico para satisfacer los requisitos, basándose en el conocimiento reunido en la fase de

Análisis.

Las actividades que se realizan en la etapa de Diseño son las siguientes:

1. Definir los Casos de Uso Reales.

2. Definir Informes e Interfaz de Usuario. 3.

Refinar la Arquitectura del Sistema.

4. Definir los Diagramas de Interacción.

5. Definir el Diagrama de Clases de Diseño.

6. Definir el Esquema de Base de Datos.

El paso de Refinar la Arquitectura del Sistema no tiene por qué realizarse en la

posición 3, puede realizarse antes o después.

Diagrama de Clases de Diseño Al construir los Diagramas de Colaboración se

van usando clases procedentes del Modelo Conceptual, junto con otras creadas para

encargarse de responsabilidades específicas. El conjunto de todas las clases usadas,

junto con sus relaciones, forma el Diagrama de Clases de Diseño.

 Un Diagrama de Clases de Diseño muestra la especificación para las clases

software de una aplicación. Incluye la siguiente información

Clases, asociaciones y atributos.

Interfaces, con sus operaciones y constantes.

Métodos.

Navegabilidad.

Dependencias

A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra

definiciones de entidades software más que conceptos del mundo real.

 Fases de Implementación y Pruebas Una vez se tiene completo el Diagrama de

Clases de Diseño, se pasa a la implementación en el lenguaje de programación elegido.

El programa obtenido se depura y prueba, y ya se tiene una parte del sistema

funcionando que se puede probar con los futuros usuarios, e incluso poner en

producción si se ha planificado una instalación gradual. Una vez se tiene una versión

estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos

de uso asignados a tal ciclo

Estructura de los sistemas de información utilizando la encapsulación herencia y

polimorfismo

Para el desarrollo de software a lo largo del tiempo se han definido varios

paradigmas de programación implementados en los lenguajes de programación.

Los primeros lenguajes de programación utilizaban un paradigma imperativo

con un conjunto de instrucciones ejecutadas de forma secuencial y organizada en

funciones que manipulan datos. Posteriormente, surge el paradigma de programación

orientado a objetos en el que el código se organiza en objetos que encapsulan los datos y

las funciones que los manipulan. Otro paradigma es la programación funcional donde el

código se organiza en funciones puras que dados unos datos de entrada genera un

resultado y en vez de cambiar de estado a los datos existentes genera nuevos datos

haciendo a los datos inmutables.

Muchos de los lenguajes de programación hacen uso u ofrecen formas de aplicar

al mismo tiempo varios de estos paradigmas de programación. Por ejemplo, el lenguaje

de programación C aún siendo un lenguaje de programación que hace uso del

paradigma imperativo también es posible utilizar conceptos de la programación

orientada a objetos o funcionales, aunque el lenguaje en sí no ofrezca abstracciones

propias de orientación a objetos o funcionales. El lenguaje de programación Java es

orientado a objetos aunque también en el código de los métodos utiliza programación

imperativa y con las novedades incluidas en Java 8 con las lambdas, streams, o los

records en Java 16 y el soporte en las estructuras de datos de las colecciones permite

utilizar conceptos de la programación funcional.

En la programación orientada a objetos hay varios conceptos que definen este

paradigma de programación, la encapsulación de datos, abstracciones de los modelos en

los programas, los objetos, clases e instancias, herencia, polimorfismo y composición.

Conceptos de la programación orientada a objetos

Los lenguajes de programación orientados a objetos se diferencian de los

imperativos en que el propio lenguaje incluye abstracciones y sintaxis específica para el

soporte de la programación orientada a objetos.

El lenguaje de programación Java considerado como un lenguaje de

programación a objetos incluye palabras reservadas para la definición de clases e

interfaces e implementa los conceptos de herencia y polimorfismo.

Encapsulación

La encapsulación no es un concepto propio de la programación orientada a

objetos pero es fundamental, los objetos son la abstracción que proporciona la

encapsulación.

La encapsulación consiste en hacer que los datos sean modificados únicamente

por las funciones destinadas a tal efecto. La encapsulación permite que los datos

conserven un estado válido y consistente, trata de evitar que cualquier código pueda
modificar una estructura de datos con el consiguiente problema de generación de

inconsistencias.

Se denomina encapsulación porque los datos y sus estructuras de datos no están

accesibles de forma directa, sino que para acceder a los datos o manipularlos se ha de

realizar a través de las funciones asociadas, los datos están encapsulados.

Abstracción

La abstracción es el concepto por el que un modelo es creado con las

propiedades relevantes a observar. Un programa trata únicamente con las propiedades

de un objeto que al programa le interesa. Las clases son la abstracción de los conceptos

que maneja la aplicación, pueden ser conceptos que existan en el mundo real pero

simplificado al tener únicamente las propiedades relevantes para la aplicación. Las

clases también pueden ser conceptos que no tengan una existencia física en el mundo

real como una lista de elementos, una dirección IP o un archivo de ordenador.

Un avión es un objeto físico del mundo real con multitud de propiedades, desde

su fabricante y modelo, color, tamaño, número de asientos, ubicación, capacidad de

carga, peso, año de diseño y fabricación, materiales de fabricación, altitud, posición

GPS, dirección, velocidad y distancia máxima y muchas otras. De todas estas

propiedades en una aplicación de gestión de embarque le interesará únicamente las

propiedades de los asientos, quizá en otra aplicación para la programación de vuelo le

interesa otras propiedades como altitud, posición GPS, dirección, velocidad aeropuerto

origen y destino o distancia.

 Herencia e interfaces

Otro de los conceptos propios de la programación orientada a objetos es la

herencia. Al implementar una clase y para reutilizar el código una clase puede extender

de otra, heredando el comportamiento de la clase extendida. La relación de herencia

entre las clases es una relación

En Java las clases abstractas no pueden instanciarse pero si ser extendidas por

otras clases que no sean abstractas. Una clase al implementar una interfaz ha de

proporcionar una implementación para todos los métodos de la interfaz, en caso de no

implementar algún método la clase ha de declararse como abstracta con la palabra

reservado abstract
 Polimorfismo

El polimorfismo es una propiedad por la cual el método invocado varía en

función de la clase de la instancia de un objeto. El polimorfismo es una característica

única en la programación orientada a objetos, mientras que la encapsulación y herencia

es posible conseguirla en lenguajes no orientados a objetos de una manera

razonablemente segura el polimorfismo al usar punteros a funciones es propensa a

errores. Los lenguajes orientados lo que proporcionan es un uso sencillo y seguro del

polimorfismo ocultando los detalles internos de su implementación de sus punteros a

funciones.
 En una jerarquía de clases que representen diferentes figuras geométricas dos

operaciones son el cálculo del área y de la longitud del perímetro. La fórmula

matemática depende de la clase de figura. En el caso de un cuadrado y de un círculo las

fórmulas para el cálculo del área y perímetro son distintas.

Referencias
Cordero Vindas, E. (2008). repositorio.ulacit.ac.cr. Obtenido de Los lenguajes de

informática orientados a objetos y orientados a eventos.:

https://repositorio.ulacit.ac.cr/bitstream/handle/123456789/4663/036325.pdf?

sequence=1

Delgado, S. (28 de Junio de 2022). Las cinco mejores prácticas de Agile para un

desarrollo de software eficaz. Obtenido de

https://www.muycomputerpro.com/2022/06/28/cinco-mejores-practicas-agile-

desarrollo-software

Desconocido. (s.f.). Qué es la metodología ágil. Obtenido de Descripción general del

desarrollo de software ágil y modelos ágiles:

https://www.nimblework.com/es/agile/metodologia-agil/

Desconocido. (s.f.). Qué es la metodología ágil. (Axarnet, Ed.) Obtenido de

Descripción general del desarrollo de software ágil y modelos ágiles:

https://axarnet.es/blog/desarrollo-agil#

F., J. (15 de junio de 2010). scholar.google.es. Obtenido de Fundamentos del Modelo.

Análisis Orientado a Objeto para los Sistemas de Información, Metodología de

Grady Booch.: https://scholar.google.es/scholar?

hl=es&as_sdt=0%2C5&q=Estructura+de+los+sistemas+de+informaci

%C3%B3n+utilizando+la+encapsulaci

%C3%B3n+herencia+y+polimorfismo+&btnG=

Grau, X. F. (2008). www.uv.mx. Obtenido de Desarrollo orientado a objetos con UML.

Recuperado el, 1.:

https://www.uv.mx/personal/maymendez/files/2011/05/umltotal.pdf
HARRIS, C. (s.f.). Artefactos del scrum ágil. Obtenido de En qué consisten los

artefactos del scrum ágil y cómo pueden ayudar durante el desarrollo del

producto: https://www.atlassian.com/es/agile/scrum/artifacts#:~:text=Los

%20principales%20artefactos%20del%20scrum,ruinas%20arqueol

%C3%B3gicas%20y%20reliquias%20antiguas.

Latam, D. (19 de Octubre de 2022). ¿Qué es el Desarrollo Ágil de Software ? Obtenido

de https://devopslatam.com/que-es-el-desarrollo-agil-de-software-ciclo-de-vida-

metodologia-y-ejemplos/

picodotdev.github.io. (2021). Obtenido de Los conceptos de encapsulación, herencia,

polimorfismo y composición de la programación orientada a objetos:

https://picodotdev.github.io/blog-bitix/2021/03/los-conceptos-de-encapsulacion-

herencia-polimorfismo-y-composicion-de-la-programacion-orientada-a-objetos/

Silverthorner, K. B. (s.f.). Desarrollo de software ágil o Agile. (TechTarget, Ed.)

Obtenido de https://www.computerweekly.com/es/definicion/Desarrollo-de-

software-agil-o-Agile

Sotomayor, S. G. (14 de Noviembre de 2023). Las metodologías ágiles más utilizadas y

sus ventajas dentro de la empresa. Obtenido de

https://www.iebschool.com/blog/que-son-metodologias-agiles-agile-scrum/