Apunte 1
Los desarrolladores de software tienen una enorme responsabilidad, ya que cuando los sistemas dejan de
funcionar, las organizaciones se ven afectadas en su operatividad y los perjuicios pueden ser enormes. Es crucial
reconocer la importancia de garantizar la estabilidad y el correcto funcionamiento del software para todos los
aspectos de nuestras vidas, desde el comercial, el educativo, el financiero, el de entretenimiento y hasta el de
salud.
Este trabajo tiene como objetivo profundizar en la importancia del software, tanto en el ámbito empresarial como
en nuestra vida diaria. En este sentido, la aplicación de los principios de ingeniería se vuelve fundamental para
construir aplicaciones de alta calidad, que satisfagan las crecientes necesidades, tanto de las organizaciones,
como de los usuarios inmersos en el mundo digital. Estos principios nos ayudan a garantizar que las aplicaciones
sean robustas, eficientes y confiables, y que funcionen sin fallos catastróficos o interrupciones.
En resumen, se reconoció que los métodos informales de desarrollo de software, que habían sido efectivos para
proyectos pequeños, no eran adecuados para enfrentar los desafíos de mayor envergadura. Los proyectos, que
solían ser llevados a cabo por grupos de programadores entusiastas y autodidactas, que experimentaban y
aprendían informalmente, requerían ahora estandarización y profesionalización.
La improvisación y la dependencia de habilidades individuales ya no eran suficientes para garantizar la calidad y la
eficiencia de los sistemas. Se requería un enfoque disciplinado y estructurado, respaldado por procesos
estandarizados y mejores prácticas. Era imprescindible formar profesionales especializados capaces de enfrentar
la creciente complejidad de los sistemas modernos.
Como respuesta a estas demandas, era el momento de crear la Ingeniería de Software. Esta nueva disciplina se
enfocaría en aplicar principios y técnicas de ingeniería para el desarrollo de software, abordando aspectos como el
diseño, la implementación, la prueba y el mantenimiento de sistemas.
La ingeniería de software busca establecer estándares, metodologías y herramientas que permitan gestionar la
complejidad y asegurar la calidad de los sistemas desarrollados.
La profesionalización del desarrollo del software implicaba reconocer la importancia de la formación académica y
la adquisición de conocimientos especializados en el campo de la ingeniería de software. Se requería contar con
profesionales capacitados que comprendieran los fundamentos teóricos y prácticos de la disciplina, y que pudieran
aplicarlos de manera sistemática en los proyectos.
En conclusión, el surgimiento de la necesidad de estandarizar y profesionalizar el desarrollo de software fue una
respuesta a los desafíos cada vez mayores de los proyectos de mayor envergadura. La disciplina de la ingeniería
de software surgió como un enfoque más estructurado y profesional para garantizar el éxito en el desarrollo de
software a gran escala.
El software es un producto ubicuo, indispensable y vital: No sólo controla computadoras y teléfonos, sino robots,
automóviles, aviones, equipos médicos, juguetes, relojes, TV, etc. El software forma parte, para bien o para mal,
en nuestra vida cotidiana y ha cambiado el mundo tal y como lo conocíamos.
Los beneficios del software son innegables, pero es importante reconocer que las fallas en el software pueden
tener consecuencias graves que comprometen la vida y el funcionamiento de diversas entidades y servicios, como
pérdida de datos importantes, interrupción de servicios, problemas de seguridad, errores en transacciones
financieras, pérdidas de dinero, exposición de información confidencial, funcionamiento de sistemas críticos,
riesgos de vida (aviones y salud), etc.
Y en este punto cabe entonces afirmar que el desarrollo de software es una actividad crítica. Entregar software
con fallas puede poner en riesgo y de modo directo, la salud, la seguridad, los derechos o los bienes de las
personas.
Los profesionales que desarrollan software tienen una responsabilidad fundamental en asegurar que el software
que crean cumpla con las mejores prácticas de desarrollo, siga estándares de calidad y sea seguro y confiable.
Esto implica utilizar métodos y técnicas de desarrollo adecuadas, realizar pruebas exhaustivas, implementar
medidas de seguridad y seguir principios éticos en su trabajo.
A diferencia de los productos físicos, en el desarrollo de software los defectos o errores descubiertos durante la
etapa de producción pueden ser corregidos sin que el producto final se vea afectado.
Por lo dicho anteriormente, la ecuación básica de costos (costo = materia prima + mano de obra + costos de
fabricación) no es aplicable al desarrollo de software. En este caso, los costos principales se concentran en el
costo de los recursos que se emplean para desarrollarlo y el tiempo durante el cual son utilizados esos recursos.
Los principales recursos que utiliza la industria del software son recursos humanos.
En el desarrollo de software, el costo principal recae en la creación de la primera unidad, ya que producir otras
copias (ya sea una o cien mil), prácticamente no generan costos adicionales o son marginales, ya que existen
algunos costos asociados a la personalización o comercialización de esas otras unidades.
La mayor parte del software se construye para un uso individualizado, aunque la industria se mueve hacia la
construcción basada en componentes.
A medida que una disciplina evoluciona, surgen conjuntos de componentes estandarizados que simplifican la
creación de productos.
Aunque en el ámbito del software existen facilidades para reutilizar componentes en diferentes desarrollos
mediante la copia y pegado del código, es común que se construya cada nuevo sistema desde cero. Esto se debe,
en parte, a la rápida evolución de la industria, lo cual hace que los programas queden obsoletos con gran
frecuencia.
Sin embargo, existen numerosas ventajas al diseñar e implementar código que pueda ser reutilizado en múltiples
programas. Los modernos componentes reutilizables, integran tanto los datos como el procesamiento que se les
aplica, lo que permite a los ingenieros de software crear nuevas aplicaciones a partir de partes que pueden ser
reutilizables.
Los mayores costos que deben asumirse al construir componentes reutilizables, se ven recuperados con creces
cuando estos componentes se incorporan en un segundo desarrollo.
También hay que mencionar que no estamos ante un proceso de reciclado o de reutilización de componentes
usados, los componentes siempre funcionan a nuevo y hasta con la ventaja de tener pruebas o mejoras previas
que hacen que sea quizá mejor que un desarrollo nuevo.
El software no se desgasta, a diferencia del hardware que presenta una tasa de fallas relativamente elevada en
una etapa temprana de su vida, luego los defectos se corrigen y la tasa de fallas se mantiene en un nivel estable
(muy bajo, generalmente) durante cierto tiempo. No obstante, conforme pasa el tiempo, la tasa de fallas aumenta
de nuevo a medida que los componentes del hardware comienzan a sentir los efectos acumulativos de suciedad,
vibración, abuso, temperaturas extremas y muchos otros inconvenientes ambientales.
En pocas palabras, el hardware comienza a desgastarse y a fallar.
Sin embargo, no es el software el que se desgasta y suma problemas, ya que si reemplazamos el hardware por
uno nuevo, el software seguirá funcionando igual que antes (o incluso mejor).
Algunos errores de programación, no detectados en la etapa de prueba, ocasionarán tasas elevadas de fallas al
comienzo de la vida de un programa. Sin embargo, estas se corrigen y la curva se aplana de modo permanente. El
software continúa funcionando de este modo hasta que, finalmente deja de operar.
Claro que tampoco es cierto que el software no tenga cambios y agregados durante su vida útil. Con cada nueva
versión, la tasa de “error inicial” vuelve a hacerse presente. Aún así, la implicación es clara: el software no
experimenta desgaste, pero sí se degrada como resultado de los constantes cambios y aquí será tiempo de
reemplazarlo por otro que no requiera tantas modificaciones.
Desafíos que enfrentan los programadores individuales en la actualidad:
1- Se demora mucho tiempo en desarrollar software.
2- Estimar los costos y plazos de entrega del software no es una tarea sencilla, ya que conllevan cambios y
nuevas necesidades.
3- Es difícil medir el avance del proyecto mientras se desarrolla o mantiene el software.
4- Los costos de desarrollo son altos, frecuentemente mucho mayores a los estimados inicialmente.
5- A pesar de realizar pruebas exhaustivas, es imposible garantizar que el software entregado estará libre de
errores.
6- Se gasta mucho tiempo y esfuerzo en mantenimiento.
7- Los clientes tienen expectativas de tiempos cada vez más cortos.
Para desarrollar software de alta calidad y sin errores, seguro y evitar fallos catastróficos, es necesaria la
aplicación de la Ingeniería de Software.
Un sistema informático está compuesto por 3 componentes básicos que interactúan entre sí (cuatro si
consideramos al usuario): hardware, software y las redes de comunicación.
Por supuesto, en cada proyecto estos componentes tendrán un peso específico diferente en cuanto a costos.
El modelo de la cadena de valor plantea la idea fundamental de que cada actividad realizada en una empresa
debe agregar más valor al producto final de lo que cuesta llevar a cabo dicha actividad. Basándose en esta
cadena de valor, las empresas pueden obtener ventajas competitivas, las cuales no son permanentes sino que
deben ser mantenidas a lo largo del tiempo.
Las estrategias para crear y mantener una ventaja competitiva pueden centrarse en dos enfoques principales: la
reducción de costos o la diferenciación del producto (o servicio).
Es difícil que una empresa pueda diferenciarse teniendo un hardware mejor o diferente que el de sus
competidores, ya que hoy el equipamiento es casi un “commodity” y se consigue fácilmente en el mercado.
De igual forma sucede con marcar una diferencia a través de una red de comunicaciones.
Pero con el software el asunto es distinto, puedo construir uno a medida y que agregue valor diferencial. Este
desarrollo es propio y no podrán tenerlo nuestros competidores, aunque contratemos software ya desarrollado, las
personalizaciones y diferentes implementaciones que hagamos nos darán ventajas por sobre el resto: permitirá
dar un mejor servicio, reducir costos y/o aportarle al producto un valor agregado a la experiencia del cliente.
Pero claro, esto sirve por la positiva pero también por la negativa: si el software falla, no sólo no se obtendrán
ventajas, sino que habrá un impacto muy malo para los negocios. Por esto es necesario construir software de
calidad y aplicar ingeniería de software.
La ingeniería de software es una disciplina que comprende todos los aspectos de la producción de software
desde las etapas iniciales de la especificación del sistema hasta el mantenimiento de este después que se utiliza.
Aspectos clave de la ingeniería de software según Sommerville:
- Se interesa por todos los aspectos de la producción, no sólo por la etapa de construcción.
- El proceso de software incluye todas las actividades que intervienen en el desarrollo de software.
- El software no es sólo un programa, sino que también incluye documentación.
- Los ingenieros de software tienen responsabilidades con la profesión y también con la sociedad. No deben
preocuparse únicamente por temas técnicos sino también contemplar los temas éticos vinculados con el
desarrollo.
- Las sociedades profesionales publican usualmente códigos de conducta que establecen los estándares de
comportamiento esperado de sus miembros.
El proceso de desarrollo de software es aquel en que las necesidades del usuario son traducidas en
requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el
código es probado, documentado y certificado para su uso operativo.
Inicialmente y de forma general, el desarrollo de software sigue una serie de etapas interconectadas que abarcan
desde el contacto inicial con el cliente hasta la implementación del software. En algunos casos, pueden surgir
nuevas versiones del software, lo que implica repetir este proceso.
Definición inicial: En esta etapa se defina globalmente el proyecto y los resultados esperados. Se hacen los
acuerdos básicos, incluso un primer presupuesto inicial, que permiten comenzar con el proyecto.
Análisis de los requerimientos y su viabilidad: Iniciado el proyecto, se procede a recopilar, examinar y obtener
todos los requerimientos del cliente, así como detectar restricciones y ver si el proyecto es viable de desarrollar.
Diseño general y detallado: A partir de los requerimientos recopilados, se procede al diseño de la aplicación
informática que satisfaga las necesidades del cliente. Para ello, se plantean primero los requisitos generales de la
arquitectura de la aplicación, seguidos por el detalle de cada uno de sus componentes. Este proceso requiere una
precisión que permita su posterior construcción, siendo equivalente al plano que guía la edificación de un edificio.
Codificación: En esta etapa los componentes diseñados a nivel teórico se programan utilizando lenguaje de
programación.
Pruebas: Una vez programado, será necesario verificar que el software no contenga errores, y que cumple con los
requerimientos originalmente solicitados por el usuario.
Implementación: Finalmente, el software se instala en las computadoras del usuario y el sistema comienza a
funcionar. También en esta etapa se capacita a los usuarios que vayan a utilizarlo.
Evolución: Una vez que el software comienza a funcionar, seguramente requerirá cambios, ya sea para corregir
algún error no detectado, o para incorporar nuevas funcionalidades.
Estas etapas no aseguran un producto de calidad, para ello son necesarias una serie de 8 actividades que Roger
Pressman denomina “Sombrilla” o “Protectoras de la calidad”:
1- Seguimiento y control del proyecto de software: permite que el equipo de software evalúe el progreso,
comparándolo con el plan del proyecto, y que pueda tomar cualquier acción necesaria para corregir
desvíos que se detecten.
2- Gestión del riesgo: Es necesaria una permanente evaluación de los riesgos que puedan afectar el
resultado del proyecto o la calidad del producto, como también establecer acciones que deben realizarse
para minimizar su probabilidad de ocurrencia o su impacto.
3- Aseguramiento de la calidad del software: Se establecen normas, protocolos y estándares a cumplir, a los
fines de que el producto final sea de aceptable calidad.
4- Revisiones técnicas: Evalúa los productos del trabajo de la ingeniería de software a fin de descubrir y
eliminar errores antes de que se propaguen a la siguiente actividad.
5- Mediciones y métricas: Define y reúne mediciones para ayudar al equipo a conocer el estado del proyecto,
detectar eventuales necesidades de aplicar alguna corrección, o servir al proceso de mejora continua.
6- Gestión de la configuración del software: administra los efectos del cambio a lo largo del proceso del
software.
7- Administración de la reutilización: Define criterios para volver a usar el producto del trabajo y establece
mecanismos para obtener, desde el inicio, componentes reutilizables en futuros proyectos.
8- Preparación y producción del producto del trabajo: agrupa las actividades requeridas para crear productos
del trabajo, tales como modelos, documentos, registros, formatos y listas.
Entonces, en la siguiente imagen puede verse de modo completo el proceso de desarrollo de software para
asegurar un software de calidad:
Apunte 2 (Desarrollo basado en un plan)
En el enfoque tradicional o dirigido por un plan, no se permiten cambios significativos. Contar con un plan tiene
sus ventajas, ya que permite presupuestar costos y estimar tiempos, y el desarrollo se vuelve más predecible, con
etapas secuenciales previamente definidas. Los requisitos planteados y acordados al inicio del proyecto serán los
que se reflejen en la versión final del software.
Claro que en estas ventajas también están las principales críticas: los proyectos de software rara vez son tan
lineales, hay poca interacción con el cliente, los errores u omisiones de una etapa se arrastran con facilidad a
etapas posteriores, los requerimientos deben obtenerse al comienzo sin posibilidad de cambio, es difícil aplicarlo
en proyectos grandes o complejos.
Aunque también es cierto que no todas las organizaciones se mueven en escenarios cambiantes, de hecho
algunas utilizan procesos que llevan años funcionando del mismo modo y con eficacia. Para este tipo de
entidades, los modelos de desarrollo dirigidos por un plan resultan sin duda la mejor alternativa.
En el otro extremo, en la actualidad, muchas organizaciones se comportan de un modo diferente: sus procesos y
sistemas están en permanente cambio y adaptación a un contexto cambiante. Para estos casos, los modelos
basados en un plan no son eficaces y allí es donde las actuales metodologías ágiles son más eficientes.
Modelo clásico de sistemas dirigidos por un plan:
El modelo tradicional podría ser mejorado al agregar algunas etapas y redefinir otras. Al combinar estas etapas
con los aspectos de calidad, la siguiente figura ilustra una propuesta integral y mejorada del modelo genérico para
el desarrollo de software basado en un plan:
Existen varios factores que pueden complicar la construcción de un sistema y desviarlo de sus estimaciones
iniciales. Entre estos factores podemos mencionar:
- El tamaño del software a desarrollar.
- La complejidad para obtener requerimientos debido a la dificultad de la comunicación entre los
especialistas en informática y los clientes, ya que los clientes no conocen de sistemas ni los analistas de
negocios.
También pueden ocultarse cosas, ya sea por omisión o a propósito.
- La complejidad técnica, ya que no todos los desarrolladores tienen la suficiente experiencia.
- El tiempo disponible es una importante restricción al proyecto.
- El riesgo, como puede ser cambios de personal, de presupuesto, de legislaciones, de mercado, etc.
En algunos casos, un modelo inicialmente más costoso puede generar ahorros significativos a largo plazo. Por
ejemplo, un modelo que permita una mejor comprensión de los requerimientos puede evitar reprogramaciones y
costos adicionales. Aún con presupuestos limitados debe elegirse el modelo más adecuado y no necesariamente
el más barato.
Modelo lineal secuencial o “En cascada”:
Para sistemas simples y pequeños, optar por un modelo simple es una excelente elección.
Este sistema consta de 5 etapas, las cuales comparten características muy similares al modelo clásico:
Modelo lineal secuencial iterativo o incremental:
Puede ocurrir que, por razones de tamaño, tiempo u operativas, sea conveniente construir y entregar el sistema en
partes. De este modo puede construirse una primera versión con algunas funcionalidades y una vez implementada
esta versión, se vuelve a emplear el modelo lineal secuencial para producir una nueva versión más completa. Es
decir, las etapas son sucesivas iteraciones del modelo lineal secuencial.
En cada iteración se entrega un sistema completo y operable, no módulos sueltos. El cliente puede usar el sistema
en entornos productivos, aún cuando este no tenga completas todas sus funcionalidades.
No debe confundirse con desarrollo ágil. En este modelo, los componentes de la primera versión están todos
planeados y definidos desde el comienzo, así como las sucesivas versiones. En contraste, en desarrollo ágil las
mejoras se van incorporando de manera incremental y periódica y no existe una planificación inicial exhaustiva,
sino que los requerimientos emergen a medida que avanzan y se priorizan para su desarrollo.
Modelo de Prototipos:
Se mencionó la dificultad existente para obtener requerimientos y para asegurar que los analistas entendieron lo
mismo que los usuarios quisieron explicar. También la existencia de procesos técnicos complejos sobre los que se
tienen dudas si se pueden realizar.
Por esto, los ingenieros de software pueden construir un prototipo de lo que será el producto final. Este prototipo
es una versión acotada del software, construida solamente a los fines de poder interactuar con el usuario y poder
tener una mejor visión de qué es lo que se está planificando hacer.
El prototipo podrá ser parcial e incluir sólo aquellas funciones más representativas. El desarrollador también podrá
usar el prototipo para probar algún algoritmo determinado o alguna funcionalidad compleja del software.
Lo habitual es que un prototipo sea un software simple, no se busca que el cliente pueda utilizar funcionalmente el
prototipo, sólo que pueda comprender y visualizar cómo funcionará la aplicación final.
El prototipo puede tener varias versiones, cambios y ajustes hasta que se llegue al acuerdo final y se avanza a la
construcción del software.
Es importante destacar que una vez que el prototipo es aprobado y los requerimientos han quedado claros, este
debe desecharse para iniciar la construcción del software real y se podrá usar cualquiera de los modelos de
desarrollo.
Modelo en espiral
Ya se ha mencionado que, en escenarios riesgosos, no todos los proyectos que se inician terminan en un software
que se implementa en forma exitosa. Boehm (1988) propuso un marco del proceso de software dirigido por el
riesgo. Utilizó para representarlo gráficamente un espiral donde, cada ciclo, representa una fase de desarrollo.
Este modelo es una buena elección en situaciones de riesgo e incertidumbre.
La característica distintiva y saliente del modelo consiste en que agrega a las etapas habituales un análisis de
riesgo.
En cada una de las iteraciones se evalúan los riesgos y el proyecto puede ser modificado, acotado, pausado o
abortado si las condiciones lo imponen.
Modelo de desarrollo rápido de aplicaciones (RAD)
Los actuales entornos avanzados de desarrollo de aplicaciones proveen a los desarrolladores de poderosas
herramientas que permiten generar código con gran rapidez y exactitud.
La utilización de estas herramientas da origen a un modelo de desarrollo rápido de aplicaciones (RAD), el cual
hace referencia a la posibilidad de generar aplicaciones con mayor velocidad que los desarrollos tradicionales.
Para agilizar los tiempos de desarrollo el software se divide en partes, para que puedan ser desarrolladas por
varios equipos que trabajan en forma concurrente. Esta división, más la reutilización de componentes y las
herramientas RAD permiten construir piezas de software completo y de calidad en tiempos que van de 30 a 90
días. La permanente comunicación con el cliente y entre los equipos de trabajo se vuelve imprescindible para el
éxito final.
Otros modelos
Desarrollo basado en componentes: Este modelo centra su desarrollo en la reutilización de software y en el
ensamble de componentes existentes.
Muchas empresas utilizan este modelo para software comercial: poseen una aplicación parcialmente desarrollada
con opciones genéricas ya programadas y la posibilidad de ajustar los requerimientos específicos del cliente.
Las ventajas de este tipo de desarrollo son:
- Implementación rápida de un sistema fiable
- Ahorro de costos
- Menos tiempo y riesgo
- Se facilita la actualización
Métodos formales: Este modelo intenta hallar modelos matemáticos formales para asegurar un desarrollo de
software libre de errores. Sirve cuando se requiere software con alto grado de precisión, por ejemplo, el
desarrollado para fines médicos o manejo de vehículos autónomos, aviones o grandes maquinarias. No es un
modelo utilizado para el desarrollo de software comercial.
Para elegir un modelo adecuado es importante saber que estos modelos no deben considerarse como caminos
rígidos que se deben seguir de manera obligatoria. Un proyecto puede requerir el uso de características de varios
modelos en su desarrollo.
Entre las limitaciones de estos modelos podemos mencionar:
- Todos los requerimientos deben plantearse de antemano y no permiten incorporar cambios.
- Los cronogramas son definidos de antemano, impidiendo que el usuario cambie las prioridades.
- Existe escasa participación del usuario en el proceso de desarrollo. El sistema finalmente entregado no
siempre cumple sus expectativas y requiere una capacitación importante.
- El ciclo de desarrollo resulta demasiado extenso para algunas organizaciones que se enfrentan a cambios
permanentes.
- La documentación y los procesos formales no siempre son bienvenidos por todas las organizaciones,
aunque es un punto favorable para aquellas que deben cumplir con normativa externa, certificaciones, o
que exijan tener documentados todos sus procesos y aplicaciones informáticas.
Apunte 3 (Desarrollo ágil)
En lugar de seguir un enfoque rígido y predecible, se adoptan metodologías ágiles que fomenten la flexibilidad,
adaptabilidad y la entrega temprana de valor. Los métodos ágiles permiten responder de manera rápida a los
cambios y ajustar el enfoque a medida que se van adquiriendo nuevos conocimientos y se comprenden mejor las
necesidades del cliente.
Asimismo, es fundamental adoptar una mentalidad de mejora continua y aprendizaje. A través de ciclos iterativos y
feedback constante, se puede adaptar el desarrollo del software a medida que se avanza y se obtienen nuevos
aprendizajes. Esto permite maximizar el valor entregado al cliente y mantenerse en sintonía con los cambios del
entorno.
Permiten la producción rápida de software útil y de calidad en periodos de tiempo más cortos.
Estos modelos se basan en la idea de que el software no se desarrolla como una única entidad completa, sino
como una serie de incrementos que agregan gradualmente nuevas funcionalidades a una aplicación que ya está
en funcionamiento, pero también en constante evolución.
El desarrollo ágil se lleva a cabo mediante equipos reducidos de profesionales altamente capacitados y se van
realizando pequeños incrementos de acuerdo con las prioridades establecidas por el cliente, los cuales se
ejecutan en ciclos breves de desarrollo conocidos como iteraciones o sprints.
Cada iteración incluye una serie de etapas tales como planificación, análisis de requerimientos, diseño,
codificación, revisión, implementación y documentación, aunque no se llevan a cabo con la misma formalidad que
en los modelos tradicionales.
Las tareas se llevan a cabo de manera colaborativa y se prioriza la comunicación y la entrega temprana de valor.
Las iteraciones permiten obtener rápidamente resultados tangibles y retroalimentación del cliente, lo que facilita la
adaptación y mejora continua del producto.
Los requerimientos del cliente se recopilan y se les asignan prioridades, quedando en espera.
En cada iteración, no es necesario que se agregue una gran cantidad de funcionalidades para justificar una nueva
versión. En cambio, se seleccionan las funcionalidades que pueden ser programadas e implementadas dentro de
los cortos plazos del sprint. El objetivo es tener un producto constantemente operativo y en continua mejora.
Al concluir cada iteración, el equipo revisa nuevamente los requerimientos pendientes y toma decisiones sobre
qué funcionalidades se incluirán en el siguiente sprint. Este ciclo iterativo se repite hasta que se determine que el
producto no necesita más evolución. El equipo busca maximizar el valor entregado en cada sprint y asegurarse de
que el producto siga evolucionando de manera efectiva.
Es frecuente escuchar que los modelos tradicionales son lentos, pesados y burocráticos, mientras que los modelos
ágiles son percibidos como rápidos y livianos. Esta afirmación es válida en cierta medida, ya que los modelos
tradicionales pueden resultar ineficientes en entornos que experimentan cambios constantes, sin embargo, los
métodos ágiles también resultan ineficientes en organizaciones que necesitan documentación exhaustiva y no
operan en entornos cambiantes, o cuando se necesita desarrollar sistemas críticos como medicina o aviones.
El manifiesto ágil es un documento fundamental que aborda técnicas y procesos para el desarrollo de software.
Fue redactado por críticos de los enfoques tradicionales y en este manifiesto se establecen 4 valores y 12
principios que conforman la filosofía de los métodos ágiles.
Valores del manifiesto ágil:
- Individuos e interacciones sobre procesos y herramientas.
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
Principios que rigen el desarrollo ágil:
1- Entrega temprana y continua de software de valor
2- Son bienvenidos los requisitos cambiantes.
3- Entregar con frecuencia software que funcione.
4- Clientes y desarrolladores deben trabajar juntos de forma cotidiana en el proyecto.
5- Individuos motivados, dándoles oportunidad y apoyo que necesiten.
6- Conversaciones cara a cara para mayor eficiencia.
7- El software que funciona es la principal medida del progreso.
8- Ritmo constante de desarrollo sostenido.
9- Atención continua a la excelencia técnica.
10- Simplicidad como arte de maximizar la cantidad de trabajo que se hace.
11- Equipos que se autoorganizan.
12- Regularmente, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta.
Programación Extrema (XP)
XP es un método ágil que engloba un conjunto de prácticas de programación efectivas. Esta metodología se
destaca por su enfoque en las liberaciones frecuentes del software, la mejora continua y la participación activa del
cliente en el equipo de desarrollo. Se centra en potenciar las relaciones interpersonales como un factor clave para
el éxito en el desarrollo del software, promoviendo el trabajo en equipo, fomentando el aprendizaje de los
desarrolladores y creando un ambiente de trabajo positivo. El término “Extreme Programming” fue acuñado por
Kent Beck en el año 2000.
Valores de XP:
- Simplicidad: Se simplifica el diseño para agilizar el desarrollo y facilitar el entendimiento. En ciertas
ocasiones, puede ser necesaria la refactorización del código para hacerlo más simple.
- Comunicación: Crea un ambiente de cooperación y unidad, al estar el cliente integrado, su opinión sobre
el estado del proyecto se conoce en tiempo real.
- Retroalimentación: Retroalimentación concreta y frecuente del cliente, del equipo y de los usuarios finales
da una mayor oportunidad de dirigir el esfuerzo eficientemente.
- Coraje: La valentía permite a los desarrolladores sentirse cómodos para reconstruir su código cuando sea
necesario. Otro ejemplo es saber cuándo desechar código obsoleto, sin importar cuánto costo y esfuerzo
llevó hacerlo. Valentía significa persistencia, un programador puede encontrarse estancado en un
problema complejo por mucho tiempo y luego lo resolverá rápidamente sólo si es persistente.
- Respeto
Prácticas de XP:
- Planeación del incremento: Los requerimientos se registran en tarjetas de historia (story cards). Las
historias que se van a incluir en la próxima liberación se determinan por el tiempo disponible y la prioridad.
- Liberaciones pequeñas: Al principio se desarrolla el conjunto mínimo de funcionalidad útil que ofrece valor
para el negocio.
- Diseño simple: Se realiza un diseño sólo suficiente para cubrir aquellos requerimientos actuales.
- Desarrollo de la primera prueba: Las pruebas de unidad (para probar el funcionamiento del módulo de
modo aislado del resto) son frecuentes y continuas.
- Refactorización: Se espera que todos los desarrolladores refactoricen el código de manera continua, tan
pronto como sea posible y se encuentren mejoras de éste, lo cual conserva el código simple y mantenible.
- Programación en pares: Los desarrolladores trabajan en pares y cada uno comprueba el trabajo del otro.
Además, ofrecen apoyo para que se realice siempre un buen trabajo.
- Propiedad colectiva: Los desarrolladores en pares trabajan en todas las áreas del sistema, por lo cual
ambos son responsables por el código de modo que no se generen “islas de experiencia”. Cualquiera
puede cambiar cualquier función.
- Integración continua: Apenas se completa una tarea, se integra en todo el sistema y luego deben probarse
todas las pruebas de unidad y de integración en el sistema.
- Ritmo sustentable: Grandes cantidades de tiempo extra no se consideran aceptables, ya que el efecto
neto de este tiempo libre con frecuencia es reducir la calidad del código y la productividad.
- Cliente en sitio: Un representante del usuario final del sistema (el cliente) tiene que disponer de tiempo
completo para formar parte del equipo XP. El cliente es miembro del equipo de desarrollo y responsable de
llevar los requerimientos del sistema al grupo para su implementación.
Roles en XP:
- Programador: Es quien escribe las pruebas unitarias y produce el código del sistema. Debe existir una
comunicación y coordinación adecuada entre programadores y otros miembros del equipo.
- Cliente: Encargado de escribir las historias de usuario (user stories) y las pruebas funcionales para validar
su implementación. Además, es quien asigna la prioridad a las historias de usuario y decide cuáles se
implementan en cada iteración para aportar mayor valor al negocio.
Este documento contiene más páginas...
Descargar Completo
Ingeniería de Software Resumen 1P-2C-2023 César Briano.docx
Estamos procesando este archivo...
Lamentablemente la previsualización de este archivo no está disponible. De todas maneras puedes descargarlo y ver si te es útil.
Descargar
Estamos procesando este archivo...
Lamentablemente la previsualización de este archivo no está disponible. De todas maneras puedes descargarlo y ver si te es útil.