Unidad temática 1: Software e Ingeniería de Software

Objetivos de aprendizaje: analizar las características diferenciadas del desarrollo del software , su
naturaleza y sus problemas para comprender la necesidad de aplicar ingeniería al software.

Aplicar procesos de ingeniería para que los sistemas funcionen bien (y que sea así desde el inicio y
hasta el fin de su ciclo de vida (mantenimiento)). El desarrollo del software es un desarrollo
intelectual, con lo cual es difícil determinar los costos en comparación a productos tangibles (materia
prima, instalaciones, etc).

El COSTO de investigación y desarrollo se lo lleva la primera unidad vendida, para las siguientes
unidades su costo es cero ya que son copias del sistema. En cuanto a la amortización y desgaste, el
software no se desgasta, como por ejemplo el hardware, ya que puede vivir con el paso de los años
funcionando igual que desde su creación.

El software es un conjunto de programas, datos, instrucciones y documentación que se utilizan para

controlar y gestionar el funcionamiento de un sistema informático, y es desarrollado mediante
procesos de ingeniería de software con el objetivo de crear programas de alta calidad.

La importancia del software:

Beneficios:
Las aplicaciones cambiaron aspectos claves de la vida humana. En la actualidad se utiliza el software
para cualquier actividad. Es imposible operar en el mundo actual y moderno sin software (servicios
públicos, finanzas, salud, entretenimiento, etc). Es el software un producto ubicuo: está presente
en todas partes.

El software tiene un doble valor: es un producto en sí mismo, pero a la vez, la herramienta que nos
permite mejorar uno de los grandes activos de la actualidad: la información.

Cuando el software comienza a fallar:

Con lo cual desarrollar y/o utilizar software que no sea de calidad pone en riesgo de modo directo la
salud, la seguridad, los derechos, los bienes o la formación de los habitantes. Cuando el software
deja de funcionar, las organizaciones dejan de operar, y los problemas pueden ser muy grandes.

El desarrollo de software es una actividad crítica. Entregar software con fallas puede poner en
riesgo y de modo directo, la salud, los derechos o bienes de las personas.

La ingeniería del software es esencial para el funcionamiento de las sociedades, tanto a nivel
nacional como internacional. Es importante la aplicación de los principios para desarrollar
aplicaciones de calidad, que satisfagan a organizaciones cada vez más complejas y a usuarios cada
vez más adaptados al mundo digital.

Ingeniería de software:
El concepto surge en 1968 en una conferencia en Alemania. Crisis de software 1960 - 1980, se
comprendió aquí que los métodos de desarrollo de software informales no podrían ser efectivos para
los nuevos grandes y complejos proyectos. Anteriormente el desarrollo dependía de los
conocimientos del programador y no se tenía un estándar (procesos formales) como otras disciplinas.

Es una disciplina que busca que se desarrolle software bajo un paradigma de calidad construyendo
aplicaciones confiables, seguras y que se generen dentro de un proceso de trabajo sustentable y
ético. La Ingeniería de Software se ocupa de la aplicación de principios, métodos y herramientas para
el desarrollo y mantenimiento de software de alta calidad, que cumpla con los requisitos de los
usuarios y las organizaciones.

1
Abarca todo el ciclo de vida del software, desde la planificación, análisis de requisitos, diseño,
implementación, pruebas, despliegue y mantenimiento del software. Su objetivo es aplicar los
principios de la ingeniería para desarrollar software de manera sistemática, con un enfoque en la
calidad, la eficiencia, la seguridad y la confiabilidad del software producido.
No sólo implica la creación de software, sino también la gestión del proceso de desarrollo, incluyendo
la planificación, la gestión de proyectos, la gestión de requisitos, la gestión de configuración y la
gestión de pruebas.

En resumen, la ingeniería de software es una disciplina que aplica los principios de la ingeniería para
el desarrollo y mantenimiento de software de alta calidad, que cumpla con los requisitos de los
usuarios y las organizaciones, a través de un enfoque sistemático en todo el ciclo de vida del
software.

Ingeniería de Software según Ian Sommerville:

“Es una disciplina de la ingeniería 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”.
● La ingeniería de software es una disciplina de ingeniería que se interesa por todos los
aspectos de la producción de software, no solamente por la etapa de construcción.
● El proceso de software incluye todas las actividades que intervienen en el desarrollo, incluso
las actividades de alto nivel de especificación, desarrollo, validación y evolución.
● El software no es solo un programa o conjunto de programas, sino que también incluye
documentación.
● Las ideas fundamentales de la ingeniería de software son aplicables a todos los tipos de
sistemas de software. Dichos fundamentos incluyen procesos de administración de software,
confiabilidad y seguridad, ingeniería de requerimientos y reutilización.
● Los ingenieros de software tienen responsabilidades con la profesión de ingeniería 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 esperados de sus miembros.

2
La ingeniería del software es importante por dos motivos:
● Por el gran uso de este en la sociedad. Con lo cual se debe producir económica y
rápidamente sistemas que sean confiables.
● A largo plazo es más barato utilizar estas técnicas que prescindir de ellas. Costo de
mantenimiento, este incrementa si se lleva sólo con técnicas de desarrollo profesional.

Los problemas al desarrollar software:

1. Se demora mucho tiempo en el desarrollo.
2. Las estimaciones de costos y plazos de entrega no son fáciles (esto también tiene relación
con que es un desarrollo intelectual, lo que dificulta estas estimaciones). Así mismo, ante el
cambio del contexto, es posible que no se tengan estas estimaciones de costos y tiempos.
3. Es difícil medir el avance.
4. Altos costos de desarrollo, y en ocasiones luego son mayores a los estimados inicialmente.
5. Es imposible encontrar todos los errores, aún realizando todas las pruebas necesarias.
Siempre surgirá alguna falla.
6. Mucho gasto de tiempo y esfuerzo en mantenimiento: entre el 60% y 80% del esfuerzo es
luego de su entrega.
7. Los tiempos de los clientes son cada vez más cortos: prioridades y urgencias, lo requieren
funcionando casi de inmediato, muchas veces esto hace que se pierda la calidad del
software.
Si se usa la ingeniería de software es posible eliminar/minimizar estos problemas.

Las características del software y la particularidad de su desarrollo:

Conjunto de atributos que debe cumplir el software:
1. Mantenimiento: debe escribirse de forma que pueda evolucionar para satisfacer las
necesidades cambiantes del cliente. En el ámbito empresarial los cambios son recurrentes,
con lo cual este atributo es crítico.
2. Confiabilidad y seguridad: debe contar con fiabilidad, seguridad y protección. Debe ser
confiable en caso de falla y no debe permitir el acceso no autorizado para causar daño.
3. Eficiencia: no debe desperdiciar los recursos del sistema, incluye capacidad de respuesta,
tiempo de procesamiento, utilización de memoria, etc.
4. Aceptabilidad: debe ser aceptable al tipo de usuarios para el cual fue diseñado. Con lo cual
debe ser comprensible, utilizable y compatible con otros sistemas utilizados.

Un proceso de software es una secuencia de actividades que conducen a la elaboración de un

producto de software.

Naturaleza del SW:

1. El SW se desarrolla o modifica con el intelecto, no se manufactura en el sentido clásico.
2. El cálculo de costos es distinto y no siguen un esquema tradicional: utiliza principalmente
RRHH, el costo se lo lleva la primera unidad (costo de la copia, costo marginal).
3. La mayor parte del software se construye para un uso individualizado, aunque la industria se
mueve hacia la construcción basada en componentes. Estos componentes, actualmente,
permiten la creación de ventanas gráficas, menús desplegables y una amplia variedad de
mecanismos de interacción.
4. El software no se desgasta: el HW se desgasta (curva de la bañadera, es decir que en un
inicio tiene alta tasa de fallas, luego se corrigen con lo cual estas disminuyen y luego
incrementa nuevamente debido a su uso propio del HW), esto no pasa con el SW (curva
idealizada, el comportamiento es el siguiente: se tienen errores al inicio, se corrigen y la
curva se aplana de modo permanente, y esto se repite en cada etapa que se modifique el

3
 software). El SW se degrada por consecuencia de los cambios que se le incorporan, que no
deja que se estabilice la curva (pensar si es mejor arreglarlo o reemplazarlo).
Ética en el desarrollo de software:
La ingeniería de software se realiza dentro de un marco social y legal que limita la libertad de la gente
que trabaja en el área. Se basa en la honestidad e integridad, y no se debe hacer uso de la profesión
para realizar actos deshonestos. La responsabilidad profesional se basa en:
1. Confidencialidad.
2. Competencia: se debe realizar la labor para la cual fue capacitado. No se deberían invadir
competencias de aquello a lo que no se encuentran capacitados, sino que se debería dejar el
lugar para aquellos que posean la competencia.
3. Derechos de propiedad intelectual: se debe proteger este derecho (patentes y copyright).
4. Mal uso de computadoras: no se debe usar la computadora de terceros de forma
incorrecta.
Los ingenieros de software deben comprometerse a hacer el análisis, especificación, diseño,
desarrollo, prueba y mantenimiento, una profesión benéfica y respetada.

Unidad temática 2: El Proceso de Software

Objetivos del aprendizaje: definir las etapas del proceso de desarrollo de software así como
también del marco de calidad. Estudiar los diferentes modelos de desarrollo, sus características,
aplicaciones y criterios de selección.

Los modelos son formas de llevar a cabo los procesos, depende del modelo como se realizará. En
resumen:
● Especificación del software: recolectar las necesidades, el problema que se quiere resolver
con el desarrollo del software.
● Diseño e implementación: planos para el desarrollo.
● Validación.
● Evolución: que el software sea capaz de ser adaptado en el futuro, que pueda tener
modificaciones.
● Protección de la calidad: esta es paralela al proceso de construcción, actividades
protectoras.

¿Por qué deben existir procesos de SW? Para elaborar un producto final que es el SW, cómo hacer
las cosas.

Las etapas generales del proceso de software:

El desarrollo de software debe cumplir con ciertas etapas que se encuentran encadenadas:
1. Definición inicial: definición del proyecto y resultados esperados.
2. Análisis de los requerimientos y su viabilidad: recopilar, examinar y obtener todos los
requerimientos del cliente, restricciones, establecer si es viable hacerlo.
3. Diseño general y detallado: se diseña la aplicación. El plano.
4. Codificación: desarrollo del programa.
5. Pruebas: verificar que no se tengan errores y que se cumple con lo solicitado.
6. Implementación: instalación del programa y posterior capacitación al usuario.
7. Evolución: incorporación de nuevas funcionalidades.

Importante: se debe contar con actividades protectoras de la calidad y se deben realizar de forma
que acompañen las actividades principales mencionadas anteriormente.

4 actividades fundamentales que debe incluir todo proceso de software según la Ingeniería de
Software:

4
Un proceso de software es una secuencia de actividades que conducen a la elaboración de un
producto de software. En este se tienen 4 actividades fundamentales y comunes:
1. Especificación: el cliente define el alcance. Sus requerimientos sobre el sistemas.
2. Desarrollo: se diseña y programa.
3. Validación: se verifica lo desarrollado para determinar si cumple con lo solicitado.
4. Evolución: se modifica el software debido a los requerimientos cambiantes del cliente y
mercado.
La forma en que se llevan a cabo las actividades depende del tipo de software, del personal y de la
inclusión de estructuras organizativas.

Desarrollo → En cascada: se organizan en secuencia | Incremental: se entrelazan.

Especificación del software:

Conocer cuál es el problema (diagnóstico) para el cual se quiere hacer el SW.

Ingeniería de requerimientos. En esta etapa consiste en comprender y definir qué servicios se

requieren del sistema, así como también las restricciones sobre la operación y el desarrollo. Es una
etapa crítica ya que los errores en esta etapa conducen de manera inevitable a problemas
posteriores tanto en el diseño como implementación.

La etapa de especificación del software es una fase crucial dentro del proceso de ingeniería de
software, que se enfoca en definir con precisión y detalle los requerimientos y funcionalidades del
software que se desea construir. En términos simples, esta etapa consiste en establecer qué es lo
que el software debe hacer y cómo debe hacerlo.

Durante esta etapa, se lleva a cabo un proceso de comunicación entre los diferentes stakeholders del
proyecto de software, como los usuarios finales, los clientes, los desarrolladores y los ingenieros de
calidad. El objetivo es definir con claridad los requerimientos del software, identificando las
funcionalidades y características que el software debe tener para satisfacer las necesidades de los
usuarios finales. La especificación del software incluye la definición de casos de uso, diagramas de
flujo, prototipos de interfaz de usuario, entre otros elementos que permiten visualizar de manera
detallada las funcionalidades del software. También se define el alcance del proyecto y los plazos
y presupuestos estimados. Una vez que se han definido los requerimientos y especificaciones del
software, se procede a la siguiente fase del proceso de ingeniería de software, que es el diseño y
desarrollo del software en sí mismo. Es importante destacar que la calidad del software final depende
en gran medida de la calidad de la especificación del software, por lo que esta etapa es crucial para
el éxito del proyecto de software.

Actividades principales en el proceso de ingeniería de requerimientos:

1. Estudio de factibilidad: entender si se puede desarrollar dentro del presupuesto, una
relación costo-beneficio. Este estudio debe ser rápido y como resultado debe informar la
decisión sobre continuar o no con un análisis más detallado.
2. Obtención y análisis de requerimientos: recopilar y entender los requerimientos del
sistemas en función de las necesidades del cliente, se pueden utilizar modelos y prototipos
para un mejor entendimiento.
3. Especificación de requerimientos: en un documento se vuelca la información recopilada en
el análisis e incluye dos tipos de requerimientos: de usuario y de sistema.
4. Validación de requerimientos: verifica que los requerimientos sean realistas, coherentes y
completos.

El análisis de requerimiento continúa durante la definición y especificación, y a lo largo de todo el

proceso surgen nuevos requerimientos.

5
Diseño e implementación del software:
Diseñar una solución adaptada al cliente y sus necesidades.
Diseño: descripción de la estructura del software que se implementará, los modelos y estructuras de
datos, interfaces y algoritmos usados. Es un proceso iterativo y se suele utilizar el backtracking.

Entradas de diseño:
● 1.a: Entorno en donde se ejecutará el software.
● 1.b: Descripción de la funcionalidad que debe brindar.
● 1.c: Si se deben procesar datos se debe tener su especificación.
Actividades de diseño:
● 2.a: estructura global del sistema (módulos y relaciones).
● 2.b: especificaciones de la interfaz a utilizar.
● 2.c: se define para cada componente del sistema como funcionará.
● 2.d: se diseña la estructura de sistema de datos.

Implementación: Proceso de convertir una especificación del sistema en un sistema ejecutable.

La etapa de diseño e implementación es la fase del proceso de software que sigue a la etapa de
especificación. Una vez que se han definido los requerimientos y especificaciones del software en la
etapa de especificación, se procede a diseñar y construir el software.

En la etapa de diseño, se definen las soluciones técnicas para satisfacer los requerimientos del
software. Esta fase implica la creación de una arquitectura de software que describa la estructura del
sistema, así como la definición de componentes y módulos que conformen el software. También se
establecen las interfaces de usuario, bases de datos, algoritmos y estructuras de datos necesarios
para implementar el software.

6
Una vez que se ha definido la arquitectura y componentes del software, se procede a la
implementación del código fuente. La etapa de implementación implica la codificación del software
en un lenguaje de programación específico, siguiendo las especificaciones definidas en la etapa de
diseño. Es en esta fase donde los desarrolladores crean, prueban y depuran el software.

Es importante destacar que el proceso de diseño e implementación se realiza de manera iterativa. Es

decir, se construyen pequeñas partes del software y se prueban de manera continua para asegurarse
de que funcionan correctamente. Esto permite detectar y solucionar problemas a medida que surgen,
evitando que se acumulen y compliquen el proceso de desarrollo.

Una vez que se ha completado la etapa de diseño e implementación, se procede a la etapa de

pruebas, donde se verifica que el software cumpla con los requerimientos definidos en la etapa de
especificación y se detectan posibles errores o problemas. Si el software cumple con los
requerimientos y está libre de errores, se procede a su entrega al cliente o usuario final. Si no, se
realizan ajustes y correcciones hasta que el software cumpla con los estándares de calidad definidos
para el proyecto.

Validación del software:

Que funciona y cumple con los requerimientos. Se crea para mostrar que un sistema cumple tanto
con sus especificaciones como con las expectativas del cliente. Principal técnica de validación →
pruebas del programa.

Los sistemas no deben ponerse a prueba como una unidad monolítica, sino que se pone a prueba en
3 etapas:
1. Prueba de componentes: se prueba cada componente de manera independiente.
2. Prueba del sistema: integración de los componentes y pruebas, detección de errores.
3. Prueba de aceptación: pruebas antes de que se ponga operativo con datos que proporciona
el cliente.

La etapa de validación es una de las fases finales del proceso de software, que sigue a la etapa de
diseño, implementación y pruebas. La validación se enfoca en asegurar que el software cumpla con
los requerimientos y expectativas de los usuarios finales y el cliente.

La validación del software implica la realización de pruebas y análisis para verificar que el software
funcione correctamente, de acuerdo a las especificaciones y requerimientos definidos en la etapa de
especificación. Estas pruebas pueden incluir pruebas de funcionalidad, pruebas de rendimiento,
pruebas de seguridad y pruebas de usabilidad.

Durante la etapa de validación, también se verifica que el software sea compatible con los sistemas
operativos, hardware y otras aplicaciones con las que interactúa. Esto es importante para asegurarse
de que el software funcione correctamente en diferentes ambientes y contextos.

Es importante destacar que la etapa de validación es crucial para asegurar que el software cumpla
con los objetivos del proyecto y las expectativas del cliente y usuarios finales. Si el software no
cumple con estos requisitos, se deben realizar ajustes y correcciones en la etapa de
retroalimentación o feedback.

En resumen, la etapa de validación se enfoca en asegurar que el software cumpla con los
requerimientos y expectativas del cliente y usuarios finales, y que funcione correctamente en
diferentes ambientes y contextos. Esta etapa es crucial para asegurar la calidad y éxito del software
en el mercado.

7
Evolución del software:
Requerimientos cambiantes en el tiempo. Antes o después del desarrollo se pueden hacer cambios.
El software cambia continuamente a lo largo de su vida, en función de los requerimientos y las
necesidades cambiantes del cliente (proceso evolutivo).

Actividades protectoras de la calidad:

Existen 8 actividades que Roger Pressman denomina “Sombrilla” o “Protectoras de la calidad” y se
encuentran presentes a lo largo de todo el proyecto para asegurar su calidad:
1. Seguimiento y control del proyecto de software: para evaluar el progreso comparándolo
con el plan del proyecto, y medir/corregir desvíos.
2. Gestión del riesgo: evaluación de los riesgos que puedan afectar al proyecto o calidad del
producto, acciones para mitigarlos.
3. Aseguramiento de la calidad del software: establecimiento de normas, protocolos y
estándares a cumplir.
4. Revisiones técnicas: se evalúa lo que ya se tiene producido para evitar que se propague a
las siguientes actividades.
5. Mediciones y métricas: para entender cómo viene el estado del proyecto, detectar
necesidades de corrección o tener un proceso de mejora continúa.
6. Gestión de la configuración del software: administra los efectos del cambio a LP del
proceso.
7. Administración de la reutilización: definición de criterios para la reutilización de
componentes.
8. Preparación y producción del producto del trabajo: actividades requeridas como
modelos, documentos, registros, formatos y listas.

Unidad temática 3: Desarrollo Dirigido por un plan

Objetivos del aprendizaje: definir las etapas del proceso de desarrollo, así como también, del marco
de calidad. Estudiar los diferentes modelos de desarrollo, sus características, aplicaciones y criterios
de selección.
Existen dos formas de desarrollar el software:
1. Desarrollo basado en un plan: se planifica al momento inicial y se va desarrollando a partir
de diferentes etapas.
2. Metodologías ágiles: no hay un plan inicial, sino que hay un software funcionando y a este
se le va incorporando periódicamente modificaciones pequeñas (incrementando su
funcionalidad).

8
Problemas al desarrollar: tamaño, obtención de los requisitos, complejidad técnica, escenarios
riesgosos que amenazan al proyecto.

Desarrollo basado en un plan vs. metodologías ágiles:

Paradigma tradicional
Esta metodología debería usarse en proyectos que no cuentan con escenarios cambiantes. En
aquellas empresas que llevan años funcionando del mismo modo y les resulta eficaz.

El desarrollo se basa en comenzar analizando cuáles son las necesidades del cliente y, en base a
estas, elaborar un plan. Este plan será el que vaya guiando una serie de etapas sucesivas, hasta que
finalmente el software quede funcionando.

Para este paradigma → NO SE PERMITEN CAMBIOS una vez establecido el plan.

Ventajas Desventajas

Permite presupuestar costos y tiempos. Los proyectos no son lineales, con lo cual
siempre surgen cambios.

El desarrollo se vuelve predecible, con etapas
secuenciales previstas de antemano.
El desarrollo se vuelve demasiado largo aún
utilizando modelos evolutivos como el
incremental.
Ante cambios ese desarrollo debería verse
modificado, porque sino se entregaría algo que
no genera valor al usuario.

Los requerimientos planteados y acordados al Los requerimientos deben obtenerse al

inicio serán los que aparecerán en la versión comienzo sin posibilidad de cambios y para ello
final → alcance definido. se requiere al cliente en constante participación,
También queda definido el cronograma al inicio. lo cual es muy difícil de lograr. Los
requerimientos siempre cambian.
El usuario se encuentra limitado con el
cronograma, lo que impide que cambie las
prioridades.
Modelo lineal, clásico, secuencial: las etapas se encadenan, una vez concluida una etapa pasa a
la siguiente. Las etapas deben ser desarrolladas una tras otra hasta arribar al producto final
instalado, al ser secuenciales, una etapa puede iniciar si finaliza su predecesora (este modelo no
abarca todas las etapas que existen en un proyecto de construcción).

Propuesta integral:
Se mejora al tradicional agregando algunas etapas y reformulando otras.
(1) Se las complementa con aquellas que son protectoras de la calidad.

9
 (2) Reformulación → LINEAL SECUENCIAL, CASCADA: Se cambia análisis por ingeniería de
requerimientos (queda más clara la idea, ya que se debe recopilar la información (búsqueda
activa de problemas) que luego será analizada) y puesta en marcha por despliegue (+ que
implementar, también capacitar, etc.). Ideal para sistemas sencillos y pequeños.

Los diferentes problemas y como cada modelo resulta más apropiado para
resolverlo:
Factores que pueden afectar la construcción de un sistema:
1. Tamaño del software a desarrollar: no es lo mismo un sistema chico que grande, este
último puede requerir más recursos, tener más usuarios y requerimientos, así como un
presupuesto asignado mayor que el de uno chico (+ grande + complejo).
2. Complejidad para obtener requerimientos: el usuario no sabe lo que quiere mayormente o
no sabe cómo plasmarlo para que eso pueda ser llevado a un sistema informático, puede
ocultar cosas, no tienen tiempo para dedicarle a los analistas. Los analistas puede que no
entiendan el negocio.
3. Tiempo disponible: urgencias que puede tener el cliente, el tiempo es una restricción para
el proyecto.
4. Riesgos: a lo largo de un proyecto se pueden presentar muchos riesgos que pueden
impactar en este y así perjudicar el funcionamiento planteado inicialmente.

Diferentes modelos - etapas, ventajas, desventajas, para que tipo de proyecto

conviene usarlo y sus particularidades:
(2) LINEAL SECUENCIAL → CASCADA → CICLO DE VIDA → REFORMULACIÓN DE ETAPAS
DEL TRADICIONAL:
Es igual que el modelo tradicional, sólo que reformula las etapas con otros nombres más
representativos. La idea es la misma, se plantea y programa todas las actividades del proceso antes
de comenzar a trabajar con ellas. No se puede empezar una fase si no termina su fase previa (el
resultado de cada una consiste en uno o más documentos.
→ Ventajas:
● Modelo simple, sencillo y probado.
● Para proyectos sencillos, menos costoso y más rápido.
→ Desventajas:
● No es posible partir en etapas.
● Los proyectos no son secuenciales (lineales). Las etapas normalmente se
retroalimentan entre sí.
● Se arrastran errores de las primeras etapas (ya que se pueden encontrar pero se
reprograman por no ser considerados prioritarios). Se descubren al entregar el
sistema (etapa de despliegue), y esto puede implicar que se entregue un producto
que no genere valor al usuario.

10
 ● Estados de bloqueos para que inicie la próxima etapa.
● Dificultad de obtener todos los requerimientos al inicio por el cliente.
● No tiene en cuenta los cambios.
● No se ve el proyecto hasta que no se finalice el desarrollo.

LINEAL SECUENCIAL ITERATIVO O INCREMENTAL:

Se basa en diseñar una implementación inicial, que el usuario la revise, y luego desarrollar sus
diversas versiones hasta tener el sistema final adecuado. Cada incremento incorpora nuevas
funciones. Sucesivas iteraciones del modelo lineal. Dentro de cada iteración se tiene al modelo lineal
secuencial. Entregar el sistema por partes, una primera versión y sobre esta nuevas funcionalidades
(sistema completo y operable) que se trabajan con el modelo lineal secuencial. Los componentes de
la primera versión están planeados y definidos desde el comienzo, esto lo diferencia de los modelos
ágiles.

→ Ventajas:
● Es mejor que el de cascada.
● Las entregas parciales reducen la complejidad del proyecto y mejoran las
estimaciones. Esto ya que se reduce el costo de adaptar los requerimientos
cambiantes del cliente, por ser dividido en etapas más pequeñas.
● El usuario tiene una primera versión con sus necesidades cubiertas. Es más fácil
obtener retroalimentación del cliente sobre el trabajo ya realizado y no tener que
esperar al final como el modelo lineal secuencial.
● Requiere menos personal y se asignan mejor los recursos.
● Más fácil y rápida la implementación de software útil al usuario debido a la entrega
en etapas parciales.
→ Desventajas:
● Sigue siendo un esquema secuencial.
● Se siguen arrastrando los errores a las siguientes etapas.
● Estados de bloqueo, menores por ser etapas parciales.
● El proceso (no software) no es visible, al desarrollar más rápido resulta costoso y
poco efectivo documentar cada versión.
● El sistema se degrada por incorporar nuevas funcionalidades. Esto se relaciona con
la degradación del SW que no deja que termine de llegar a la parte plana del ciclo de
vida que se le agregan más cosas.

MODELO DE PROTOTIPOS:
Un prototipo es una versión acotada del software, construida solamente a los fines de poder
interactuar con el usuario y tener una mejor visión de lo que se planifica hacer (en principio sólo las
funciones representativas).
→ Se debe definir el objetivo del prototipo y al finalizarlo este debe cumplir con ello.
→Debe ser simple, para que el cliente comprenda y visualice cómo funcionará la aplicación final.
→ Puede tener varias versiones, cambios y ajustes, hasta el obtener el entendimiento de los
requerimientos.
→ Una vez que es aprobado debe desecharse para iniciar la construcción del software real (para
esta construcción se puede usar cualquier otro modelo).

11
→ Etapas: (1) relevamiento rápido, (2) diseño del prototipo (se define el alcance), (3) generación del
prototipo, (4) prueba, (5) despliegue y retroalimentación (no se entrega el prototipo al cliente, se
ejecuta y analiza con él). Finalmente si es aprobado se avanza con la generación del software
usando un modelo.
→ Ventajas:
● Mejor definición y comprensión de requerimientos. Ayuda con la selección y
validación de requerimientos del sistema. Para buscar soluciones específicas de SW
y apoyar el diseño de interfaces de usuario (esencial en el proceso de diseño).
● Posible testeo de funciones complejas.
● Reduce la incertidumbre. Revela errores u omisiones.
→ Desventajas:
● El cliente puede tentarse de usar el prototipo. Este no es un producto que pueda
utilizarse como primera versión operativa, además de que quizás el propio prototipo
no se utilice de la misma forma que el sistema final.
● El desarrollador puede tentarse de ajustarlo para hacer el producto final sobre este.
Esto no está bien ya que puede no ser posible corregirlo para cubrir todas las
necesidades.
● Funcionalidades del prototipo pueden no estar presentes en el producto final.
● El prototipo, al ser un desarrollo rápido, no se encuentra documentado.

MODELO EN ESPIRAL (BOEHM):

Se propone un marco del proceso de software dirigido por el riesgo. Gráficamente es un espiral
donde cada ciclo representa una fase de desarrollo. Este modelo es bueno para situaciones de
riesgo e incertidumbre.

(1) Se busca determinar los posibles riesgos.

(2) Esta etapa actúa como vía de escape, es posible abortarlo para no gastar más recursos en
un proyecto inviable.
→ Las primeras iteraciones del espiral corresponden a la primera versión o al desarrollo del prototipo.
Luego se utiliza el modelo lineal secuencial iterativo hasta finalizar el software.
→ Agrega análisis de riesgo, para cada una de las iteraciones. Se determina en base a esto la
continuidad del proyecto.
→ Ventajas:
● Entregas sucesivas y análisis de riesgo.
● Puede usarse durante todo el ciclo de vida útil produciendo nuevas versiones.
→ Desventajas:
● No es simple medir los riesgos, se debe hacer correctamente para no desechar
aquellos que realmente si eran viables o al revés.
● Es un modelo controlado y con un final planificado.
● Es más caro por realizar el análisis de riesgos, pero puede ahorrar los costos al
tomar medidas correctivas para su mitigación.
MODELO RAD:

12
Desarrollo rápido de aplicaciones por contar con varios equipos, reutilizar componentes y
herramientas RAD (son herramientas de software que permiten a los desarrolladores crear
aplicaciones de forma rápida y eficiente, utilizando técnicas de programación visual y prototipado
rápido. Estas herramientas permiten a los desarrolladores crear aplicaciones más rápidamente, ya
que se enfocan en la automatización y la reutilización de código. Ejemplo: visual studio code).
→ Posibilidad de crear aplicaciones con mayor velocidad que los desarrollos tradicionales.
Igualmente se tiene planificado todo al inicio, no es agile.
→ Se divide el desarrollo en partes para trabajar con varios equipos.
→ Se reutilizan componentes. Se pueden construir piezas de calidad entre 30 y 90 días.
→ Necesaria comunicación entre el cliente y equipo para el éxito.

(1) Las necesidades del sistema se plantean teniendo en cuenta una división de este para que
pueda ser tomado por diferentes equipos de forma simultánea.
(2) Se diseña en función de herramientas RAD, se analizan los componentes a reutilizar.
(3) Se usa la herramienta RAD, el código se genera mediante un proceso semiautomático.
(4) Pruebas automatizadas por herramienta RAD.

→ Ventajas:
● Menor tiempo de desarrollo.
● Menor tiempo de prueba y errores no detectados.
● Se pueden construir sistemas portables o de fácil migración entre diferentes
entornos.
→ Desventajas:
● El cliente debe asignar más personal al proyecto y con mayor carga horaria, ya que
son plazos cortos.
● No todos los proyectos pueden dividirse ni usar herramientas RAD.
● Código automático → menor performance y consume más recursos.
● Es complicado usar en proyectos grandes porque requiere mucho personal.

DESARROLLO BASADO EN COMPONENTES (ingeniería de SW orientada a la reutilización):

reutilización de SW y ensamble de componentes existentes. Utilizado para SW comercial, se tiene
una app casi desarrollada, con opciones genéricas ya incluidas y posibilidad de ajustar según la
necesidad del cliente. COTS.
1. Especificación de requerimientos.
2. Análisis de componentes: según los requerimientos se buscan componentes.
3. Modificación de los requerimientos: se analizan los requerimientos luego de tener
información exacta de los componentes a utilizar.
4. Diseño de sistema con reutilización: se diseña el marco conceptual del sistema o se
reutiliza uno existente.
5. Desarrollo e integración: se desarrolla aquello que no se puede reutilizar y se integran a los
componentes existentes.
→ Ventajas:
● Reduce la cantidad de SW a desarrollar.
● Disminuye costos y riesgos.
● Entregas más rápidas.
→ Desventajas:

13
 ● El compromiso de los requerimientos, entregar un sistema que no cubra las
necesidades reales de los usuarios.
● Se pierde control sobre la evolución del sistema con respecto a nuevas versiones de
los componentes sobre los que no se tiene influencia.

MÉTODOS FORMALES: usa modelos matemáticos formales para asegurar un desarrollo libre de
errores. Esto puede ser utilizado para aquellos que requieren un alto grado de precisión como
diagnóstico médico o programa de un auto, más no para software comercial.

Conclusión: no hay un modelo mejor que otro, sino que se debe determinar cual es adecuado
utilizar según el proyecto y sus características, el tipo de cliente, la experiencia y forma de trabajo del
equipo de desarrollo. También puede utilizarse una mezcla de estos, utilizar por ejemplo prototipos y
luego herramientas RAD o el modelo incremental, es decir que no son “competitivos” entre sí, sino
posibles caminos a seguir que no son obligatorios o excluyentes en lo absoluto.

CUANDO UTILIZAR UN MODELO U OTRO → RESUMEN:

Problema Modelo recomendado

Tamaño Pequeños → lineal secuencial.

Grandes → modelos evolutivos, aquellos que permitan la
entrega de sucesivas versiones (etapas) de manera
incremental.

Complejidad de requerimientos Elaborar prototipos para una mejor comprensión.

Al no conocer los requerimientos desde un inicio, es
recomendable los modelos evolutivos.
En aquellos proyectos donde se entienden bien los
requerimientos y sea improbable un cambio radical durante
el desarrollo se debe usar un modelo en cascada.

Complejidad técnica Usar prototipos para probar funcionalidad técnica compleja.

Utilizar el modelo espiral para analizar los riesgos y
monitorearlos.

Tiempos disponibles (para la RAD, para reducir el tiempo de desarrollo, pruebas y

entrega) errores.

Entornos riesgosos Modelo espiral.

Dar una revisión rápida a RUP, capítulo 2.

Unidad temática 4: Desarrollo Ágil de Software

Objetivos del aprendizaje: conocer el proceso de desarrollo utilizando métodos ágiles y
analizar los principales modelos de desarrollo que respaldan dicha metodología.
Escenarios cambiantes donde no es posible mantener un plan (4, 6 meses) sino que
requiere tener un SW funcional al cual se le puedan ir agregando nuevas cosas. Para este
caso el desarrollo utilizando metodologías tradicionales no son efectivas.
El desarrollo ágil de SW se basa en ideas que ciertos desarrolladores (en el 2001) volcaron
en un manifiesto ágil y que da nuevas pautas para producir el SW.
- Preferir SW funcional (incorporando nuevas funcionalidades) a documentación
extensiva.
- Equipos autónomos → personal técnico muy capacitado.
Este modelo no sirve para todo tipo de escenarios, dependerá de la empresa y
características del proyecto.

14
Metodologías ágiles vs modelos tradicionales:
Metodologías ágiles
Esta metodología debería utilizarse en ambientes de permanente cambio y evolución. En
organizaciones donde sus procesos, y por ende sistemas, se encuentran en permanente
cambio y evolución. Aquellas que se enfrentan a contextos variables, que tengan estructuras
flexibles y que se amoldan a lo que sucede en el exterior, no pueden trazar un plan rígido para
el desarrollo.

1980 → métodos tradicionales:

→ Se pensaba en que la mejor forma de desarrollar SW era con una cuidadosa planificación.
Ejemplo: sistemas aeroespaciales.
→ Enfoques basados en un plan incluyen costos operativos significativos en la planificación.
Diseño. Documentación del sistema.
Dicho esto, no pueden aplicarse a sistemas de negocios pequeños y medianos, que se encuentran
en constante cambio, debido al propio movimiento del mercado.

1990 → métodos ágiles:

→ Enfoque en el desarrollo.

Los modelos ágiles surgen como respuesta a aquellas organizaciones que operan en entornos
cambiantes y que necesitan adaptarse con rapidez para afrontar nuevos desafíos y oportunidades. El
software se desarrolla como una serie de incrementos que agregan nuevas funcionalidades a una
aplicación ya operativa pero que se encuentra en permanente mejora (hasta que se decide no
evolucionarlo más).
AGILIDAD → SISTEMAS EMPRESARIALES | SISTEMAS CRÍTICOS ← TRADICIONAL

El manifiesto ágil y los principios que guían el desarrollo ágil:

Manifiesto→2001. Documento sobre técnicas y procesos para el desarrollo de SW.
4 VALORES:
1. Individuos e interacciones sobre procesos y herramientas → Humano = principal factor
del éxito.
2. Software funcionando sobre documentación extensiva → producir los documentos
necesarios sobre lo fundamental, deben ser cortos.
3. Colaboración con el cliente sobre negociación contractual → cliente parte del equipo
desde el inicio hasta el final.
4. Respuesta ante el cambio sobre seguir un plan → ante los frecuentes cambios no se
debe tener una planificación estricta, sino que se debe ser flexible para responder
correctamente.

12 PRINCIPIOS:
1. Satisfacer al cliente con entrega temprana y continua de SW de valor.
2. Se aceptan los requisitos cambiantes.
3. Entregar frecuentemente SW funcionando en períodos cortos.
4. Trabajo en conjunto con devs y personas que conocen el negocio.
5. Motivación a los individuos.
6. Comunicar información cara a cara es más efectivo y eficiente.
7. Se mide el progreso a través del SW que funciona.
8. Desarrollo sostenido, ritmo constante.
9. La atención continua y la excelencia técnica.
10. Simplicidad para maximizar la cantidad de trabajo.

15
 11. Debido a equipos autoorganizados se tienen mejores arquitecturas, requisitos y diseños.
12. El equipo reflexiona sobre cómo se hizo el trabajo y de ser necesario ajustarlo para mejor.

Scrum:
Este modelo también se enfoca en la gestión general de proyectos, y no exclusivamente de
desarrollo. En lo que respecta a desarrollo, su enfoque está en la administración iterativa del
desarrollo. Tiene tres fases:
1. Planeación del bosquejo: se establecen objetivos generales del proyecto y el diseño de la
arquitectura de SW.
2. Ciclos sprint: en cada sprint se desarrolla un incremento del sistema.
3. Cierre del proyecto (revisión): se evalúa si hay que mejorar algo.

Sprint: es una unidad de planeación en la que se valora el trabajo que se va a realizar, se

seleccionan las particularidades por desarrollar y se implementa el SW. Se entrega funcionalidad
completa. Tienen longitud fija (2 a 4 semanas) y una vez definido su duración no se puede modificar
ya que con esto se determina el ritmo de trabajo.

Product Backlog: lista de trabajo pendiente de realizar. En función de las prioridades asignadas se
va avanzando con los sprints que lo contienen.

Priorización: se junta todo el equipo y se prioriza las funcionalidades a desarrollar dentro del sprint.

Se inicia el desarrollo, para revisar su progreso se realizan reuniones diarias. La forma de realizar
el trabajo varía en cada equipo y depende del problema. Las comunicaciones se canalizan por medio
del Scrum Master quien tiene la tarea de proteger al equipo de distracciones y atender sus
necesidades. Luego del sprint se realiza una revisión y demo.

CEREMONIAS:
1. Sprint planning: qué y cómo se hará, el equipo estima que se podría incluir en el próximo
sprint.
2. Daily meeting: que tarea se hará e impedimentos.
3. Sprint review: se presenta el software funcionando en PRD, no es demo.
4. Sprint retrospective: reflexión sobre el sprint finalizado. Identificar mejoras para el próximo.
5. Refinamiento del product backlog.
ROLES:
Comprometidos directamente con el proyecto:
1. PO: responsable de lograr el máximo valor empresarial del proyecto.
2. SM: facilitador que asegura que 3 esté dotado de un ambiente propicio para completar el
proyecto con éxito. Responsable de que se cumpla la metodología.
3. Equipo scrum: responsables de entender los requisitos. Crean los entregables.
Involucrados: no participan directamente del proceso Scrum.

→ Ventajas:
● Adaptabilidad: por las entregas iterativas, que permiten cambios.
● Transparencia: por el tablero, se visualiza el avance de cada sprint.
● Retroalimentación continua: por daily y review.
● Mejora continua: por los entregables en c/sprint.
● Entrega continua de valor: al cliente en cada iteración.
● Ritmo sostenible: en el trabajo por el diseño de los procesos scrum.
● Motivación: entre los empleados.
● Resolución rápida de problemas: por la colaboración de equipos.

16
 ● Entregables efectivos: el product backlog y revisiones periódicas después de cada
sprint segura entregas efectivas para el cliente.
→ Desventajas - críticas:
● Estrés del equipo por la entrega continua.
● Para terminar más rápido el equipo puede sacrificar calidad o seguridad.
● Difícil de aplicar en proyectos grandes y en aquellos que tienen fecha de entrega y
precios cerrados por contrato.
● Se requiere experto que monitorice el cumplimiento de la metodología.
● Presupone que el equipo está formado y motivado. Así también que el cliente está
100% involucrado.
● Pérdida de productividad que puede ser causada por muchas reuniones.
XP:
La Programación Extrema (XP, por sus siglas en inglés) es una metodología ágil de desarrollo de
software que se enfoca en la entrega temprana y frecuente de software funcional, de alta calidad y
adaptado a las necesidades del cliente. Es el más conocido y más ampliamente usado. Integra un
rango de buenas prácticas de programación, como las liberaciones frecuentes del SW, el
mejoramiento continuo de SW y la participación extrema del cliente en el equipo de desarrollo.

Los requerimientos se expresan como escenarios (US) que se implementan directamente como una
serie de tareas. Los programadores trabajan en pares y antes de escribir el código se desarrollan las
pruebas para cada tarea. Cada US es lo suficientemente comprensible y delimitada para que los
programadores puedan implementarla en unas pocas semanas (se descompone en tareas, se estima
y asigna los recursos necesarios).

Esta metodología se basa en un conjunto de prácticas que incluyen la planificación incremental, el

desarrollo iterativo, la colaboración estrecha entre el equipo de desarrollo y el cliente, la
programación en pareja, la integración continua, la refactorización continua del código y las pruebas
automáticas. El objetivo principal de XP es maximizar el valor que se entrega al cliente,
minimizando el tiempo y los costos necesarios para hacerlo. Para lograr este objetivo, XP se centra
en la simplicidad, la comunicación efectiva, la retroalimentación constante y la capacidad de
respuesta a los cambios.

En resumen, XP es una metodología ágil de desarrollo de software que se enfoca en la entrega

temprana y frecuente de software funcional y de alta calidad, a través de un conjunto de prácticas
que promueven la simplicidad, la colaboración, la retroalimentación y la capacidad de respuesta a los
cambios.

Valores:
1. Simplicidad: del diseño para agilizar el desarrollo y facilitar el entendimiento.
2. Comunicación: dentro del equipo y con el cliente.
3. Retroalimentación: del cliente, equipo y usuarios de forma frecuente.
4. Coraje: para reconstruir el código y desecharlo de ser necesario.
5. Respeto: en el equipo.
Prácticas:
1. Planeación del incremento: US.
2. Liberaciones pequeñas: se desarrolla un conjunto mínimo de funcionalidad útil y se
entregan incrementos posteriores.
3. Diseño simple: para cubrir los requerimientos actuales.
4. Desarrollo de la primera prueba: pruebas unitarias de cada módulo.
5. Refactorización: de manera continua el código, que este se mejore (optimice).
6. Programación en pares: cada desarrollador revisa el código del otro.

17
 7. Propiedad colectiva: todos los devs se responsabilizan por el código. El código es de todo
el grupo.
8. Integración continua: cuando se termina una tarea se integra al sistema, se deben hacer
pruebas sobre esto.
9. Ritmo sustentable: no se acepta tiempo extra ya que reduce la calidad del código y la
productividad de término medio.
10. Cliente en sitio: debe disponer de tiempo completo para formar parte del equipo.
ROLES:
Programador. Cliente. Tester. Tracker. Coach. Consultor. Gestor.
PRUEBAS (características claves):
1. Desarrollo de la primera prueba.
2. Desarrollo de pruebas incrementales a partir de escenarios.
3. Involucramiento del usuario en el desarrollo y la validación de pruebas.
4. El uso de marcos de pruebas automatizadas.
PROGRAMACIÓN EN PARES:
Los programadores trabajan en pares para desarrollar el software. Cada miembro realiza una acción
que el otro no está haciendo actualmente. Roles: conductor (implementa el código) y acompañante
(analiza para mejoras).
→Ventajas de pair programming:
● Apoya la idea de la propiedad y responsabilidad colectivas para el sistema.
● Actúa como un proceso de revisión informal: dos personas viendo el código.
● Ayuda a la refactorización.
● Promueve la distribución de conocimiento en el equipo.
● Muchos devs contribuyen al diseño. Se pueden ayudar para resolver un problema.
● Mayor disciplina.
VENTAJAS Y DESVENTAJAS DE XP:
→ Ventajas:
● Se adapta para sistemas grandes y pequeños.
● Optimiza el tiempo de desarrollo.
● Complementa conocimientos.
● Código sencillo y entendible.
→ Desventajas:
● No se tiene definición de costo y tiempo por parte del cliente.
● Al igual que otros modelos requiere la presencia del cliente 100%, y esto es difícil de
lograr.
● Celos de programadores.
● + programadores capacitados + costos.

Ventajas, dificultades y limitaciones de los desarrollos ágiles:

→Ventajas:
● Rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto.
● El cliente puede observar cómo va avanzando el proyecto.
● Al ofrecer entregables parciales se puede empezar con lo más sencillo y cuando se
tiene más experiencia y tiempo con lo más complejo.
● Los cambios tendrán un menor impacto, ya que es sobre los entregables y no sobre
un proyecto en su totalidad como el lineal.
● Reducción de tiempos y costos de capacitación e implementación.
● Stakeholders → se les asigna un rol y se los involucra.
Dificultades:
● Los clientes no siempre pueden estar 100% a disposición de las necesidades del
equipo.
● Miembros que no cuenten con la personalidad adecuada para afrontar el trabajo.

18
 ● Es difícil la priorización y más aún si hay muchos interesados.
● Mantener la simplicidad requiere trabajo adicional, esto suele no hacerse debido a la
presión en las fechas de entrega.
● Empresas que ya tienen una metodología de trabajo de años, ya definidos, les
resulta difícil moverse a un modelo informal como este.
Limitaciones:
● Falta de documentación del diseño.
● Falta de procesos rigurosos y documentación escrita, lo que puede producir
problemas si se quiere certificar o auditar.
● Al ser la comunicación mayormente oral eso no queda documentado en ningún lado,
lo que puede generar problemas a futuro.
● No existe siempre la secuencialidad, puede pasar que para implementar B se
necesite primero A.
● Restricciones en el tamaño del proyecto.
● No hay documentación o hay poca, lo que hace que el conocimiento e información
quede en la mente de unos pocos.
● Contratos por tiempo, a veces es complicado de controlar.
● Difícil la subcontratación y la presupuestación.

RESUMEN AGILIDAD VS TRADICIONAL

AGILIDAD TRADICIONAL

Para organizaciones que operan en entornos Para organizaciones que operan en entornos
cambiantes, con procesos flexibles y donde se estables, con normas y procesos definidos.
sabe que el software estará en permanente Para SW que deba cumplir funcionalidades
cambio. críticas.

No se tiene una especificación inicial detallada. Requisitos definidos al inicio.

Cambios frecuentes durante el desarrollo. No se permiten cambios.

Sistema en permanente desarrollo. Siempre se Se entrega de forma completa o en etapas

incorpora nueva funcionalidad. (incremental) pero siempre completo y
planificado de antemano.

El usuario participa con el equipo de desarrollo. El usuario no forma parte del equipo. Solo hace
las pruebas finales cuando se le entrega el
producto.

El sistema se adapta al contexto. El usuario se adapta al sistema.

Metodología crystal.

Metodología de desarrollo de sistemas dinámicos.

19