lOMoARcPSD|23408676

Resumen 1ER Parcial - Ingeniería de Software

Ingeniería de Software I (Universidad de Buenos Aires)

Studocu no está patrocinado ni avalado por ningún colegio o universidad.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)
 lOMoARcPSD|23408676

CAPÍTULO 1: SOFTWARE E INGENIERÍA DE SOFTWARE

El software es un producto ubicuo: está presente en todas partes, forma parte de la vida cotidiana. Tiene doble valor:
es un producto en sí mismo, pero a la vez es un vehículo (una herramienta) para entregar un producto.

Diferencias entre desarrollo de software y la fabricación de productos tradicionales

1. El SW se desarrolla o modifica con intelecto; no se manufactura en el sentido clásico
La industria tradicional compra materias primas y, mediante procesos industriales, las ensambla y transforma
para lograr un producto final. Mientras los productos tradicionales se construyen en fábricas, procesando
insumos para convertirlos en el producto, el SW, casi en su totalidad, es una producción intelectual.
2. El cálculo de costos es distinto y no siguen un esquema tradicional
En el SW, los costos principales son los recursos humanos. En un esquema productivo tradicional, los gastos de
fabricación se prorratean entre todas las unidades producidas (mano de obra directa, indirecta, materia prima y
gastos operativos).
3. La mayor parte del software se construye para un uso individualizado, aunque la industria se mueve hacia la
construcción basada en componentes
En la industria se crean un conjunto de componentes estandarizados que facilitan la producción (ej.: tornillos
estándar y circuitos integrados). Para la construcción de SW se diseña e implementa código que pueda
reutilizarse. Incorporando tanto los datos, como el procesamiento que se les aplica, permitiendo que el ingeniero
de software cree nuevas aplicaciones a partir de partes susceptibles de volverse a usar.
4. El software no se desgasta
El HW tiene una tasa de fallas llamada “curva de la bañadera”, indica que tiene una tasa de fallas elevada en una
etapa temprana de su vida, luego estos defectos se corrigen y la tasa se mantiene estable durante un tiempo,
conforme el mismo pasa, las fallas aumentan y el HW comienza a desgastarse.
El software no se desgasta, ¡pero sí se degrada! Los errores de programación no detectados en la etapa de
prueba generan tasas elevadas al comienzo de vida de un programa, cuando se corrigen, la curva se aplana de
modo “permanente” (curva ideal). Clare que, como el SW tiene cambios y agregados en su vida útil con c/nueva
versión, la tasa de error inicial se hace presente. Con los cambios y agregados constantes, la curva de fallas se
dispara y no llega a un estado estable: el software se está deteriorando como consecuencia del cambio.

Problemas al desarrollar un software

1. Se demora mucho tiempo en desarrollar software.
2. Las estimaciones de costos y plazos de entrega no son sencillas. Una vez presentado el presupuesto y plan inicial
aparecen cambios y nuevas necesidades no contempladas originalmente.
3. Es difícil medir el avance del proyecto mientras se desarrolla o mantiene el software.
4. Los costos de desarrollo son altos. Habitualmente, es necesario presentar un presupuesto de cuándo saldrá el
desarrollo antes de tener los datos necesarios como para poder calcular los costos de un modo razonable.
5. Por mejor que se realice la prueba, es imposible encontrar todos los errores y asegurar que el software
entregado no tendrá fallas.
6. Se gasta mucho tiempo y esfuerzo en mantenimiento.
7. Los tiempos del cliente son cada vez más cortos. Necesitan tener el software funcionando “casi de inmediato”.

Componentes principales de un sistema informático

1. HARDWARE
2. REDES
3. SOFTWARE

¿Cuál de estos componentes puede generar un factor diferencial o una ventaja competitiva?
1. HARDWARE: no, hoy es casi un “commodity” (bien producido en masa). Se consigue en el mercado, está
disponible para cualquier empresa, y no es necesario montar un centro de cómputo, se puede usar Cloud
Computing.
2. REDES: no, es poco probable que podamos montar una red de comunicaciones propia.
3. SOFTWARE: si, tener un mejor SW que un competidor permitirá dar un mejor servicio, reducir costos y/o
aportarle al producto un valor agregado (que lo hace más atractivo para los compradores). Un buen SW permite
generar ventajas competitivas y alimentar la cadena de valor. Ese desarrollo es propio y no podrán tenerlo
nuestros competidores. Y aun cuando contratemos software ya desarrollado, SAP, por ejemplo, las
personalizaciones y diferentes implementaciones que hagamos nos darán ventajas por sobre el resto.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

Ingeniería de Software
Es el establecimiento y uso de principios solidos de la ingeniería para obtener económicamente un software confiable
y que funcione de modo eficiente en máquinas reales. Es una disciplina de la ingeniería que integra el proceso, los
métodos, y las herramientas para el desarrollo de software de computadora.

Aspectos claves de Somerville:

 Todos los aspectos de la producción son importantes, no solo la etapa de la construcción.
 El proceso de SW incluye todas las actividades que intervienen en el desarrollo, las de especificación, desarrollo,
validación y evolución son parte de todos los procesos de desarrollo de SW.
 El SW no es solo un programa o un conjunto de programas, sino que también incluye documentación.
 Los atributos esenciales de los productos de software son mantenimiento, confiabilidad, seguridad, eficiencia y
aceptabilidad.
 Existen diferentes tipos de sistemas y c/u requiere para su desarrollo herramientas y técnicas adecuadas de la
ingeniería de SW.
 Los ingenieros de SW tienen responsabilidades con la profesión de ingeniería y la sociedad. No debe
preocuparse solo por temas técnicos, sino también contemplar temas éticos vinculados con el desarrollo. Deben
jurar desempeñar el código de ética y práctica profesional de la ingeniería de software.

Quienes desarrollan SW debe, primordialmente, respetar:

 LA CONFIDENCIALIDAD: Por lo general, debe respetar la confidencialidad de sus empleadores o clientes sin
importar si se firmó o no un acuerdo formal sobre la misma.
 SUS COMPETENCIAS: No debe desvirtuar su nivel de competencia. Es decir, no hay que aceptar de manera
intencional trabajo que esté fuera de su competencia.
 LOS DERECHOS DE PROPIEDAD INTELECTUAL: Tiene que conocer las leyes locales que rigen el uso de la
propiedad intelectual, como las patentes y el copyright. Debe ser cuidadoso para garantizar que se protege la
propiedad intelectual de empleadores y clientes.
 EVITAR EL MAL USO DE COMPUTADORAS: No debe emplear sus habilidades técnicas para usar incorrectamente
las computadoras de otros individuos.

EL PROCESO DE DESARROLLO DEL SOFTWARE

El proceso de desarrollo de software es: “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”.

El proceso de ingeniería de software se define como “un conjunto de etapas parcialmente ordenadas con la intención
de lograr un objetivo, en este caso, la obtención de un producto de software de calidad”.

Etapas:
1. DEFINICIÓN INICIAL: se define globalmente el proyecto y los resultados esperados y se hacen los acuerdos
básicos (incluyendo un presupuesto inicial).
2. ANÁLISIS DE LOS REQUERIMIENTOS Y SU VIABILIDAD: se procede a recopilar, examinar y obtener todos los
requerimientos del cliente, y detectar las restricciones. Se decide la viabilidad del proyecto.
3. DISEÑO GENERAL Y DETALLADO: se diseña la aplicación informática que responderá a las necesidades del
cliente. Se plantean requisitos generales de la arquitectura de la aplicación y, luego, el detalle de c/componente
de la aplicación. Equivale a un plano.
4. CODIFICACIÓN: los componentes diseñados se programan en lenguaje de computación.
5. PRUEBAS: se verifica que no contenga errores y que cumpla con los requerimientos originalmente solicitados.
6. IMPLEMENTACIÓN: se instala en las computadoras del usuario y comienza a funcionar. Incluye la capacitación
necesaria para los usuarios.
7. EVOLUCIÓN: ya funcionando, el software requerirá cambios, para corrección o incorporación de nuevas
funcionalidades.

Actividades sombrilla o protectoras de la calidad

Uno de los principales objetivos de la ingeniería de software es la construcción de aplicaciones de calidad. Para esto,
cualquiera sea el modelo elegido, se recomienda el desarrollo en paralelo de una serie de actividades “Sombrilla” o
“protectoras de la calidad”:
 Seguimiento y control del proyecto de software: permite que el equipo de software evalúe el progreso
comparándolo con el plan y tome acciones correctivas.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

 Gestión del riesgo: evalúa los riesgos que pueden afectar el resultado del proyecto o la calidad del producto y
las acciones que puedan realizarse para minimizar su probabilidad de ocurrencia o su impacto.
 Aseguramiento de la calidad del software: se establecen normas, protocolos y estándares a cumplir a los
fines de que el producto final sea un producto de aceptable calidad.
 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.
 Mediciones y métricas: define y reúne mediciones para ayudar al equipo a conocer el estado del proyecto,
detectar eventuales necesidades de aplicar correcciones o servir al proceso de mejora continua.
 Gestión de la configuración del software: administra los efectos del cambio a lo largo del proceso del
software.
 Administración de la reutilización: define criterios para volver a usar el producto del trabajo y establece
mecanismos para obtener componentes reutilizables.
 Preparación y producción del producto del trabajo: agrupa las actividades requeridas para crear productos
del trabajo: modelos, documentos, registros, formatos y listas.

CAPÍTULO 2: EL PROCESO DEL SOFTWARE

Existen diferentes procesos de software, pero todos deben incluir cuatro actividades fundamentales para la ingeniería
de software:
1. ESPECIFICACIÓN: donde se busca comprender y definir qué servicios se requieren del sistema, así como también
la identificación de las restricciones sobre la operación y el desarrollo.

2. DISEÑO E IMPLEMENTACIÓN: una descripción de la estructura del software que se va a implementar, los modelos
y las estructuras de datos utilizados por el sistema, las interfaces entre componentes del sistema y, en ocasiones,
los algoritmos usados.

3. VALIDACIÓN: en la que se buscará demostrar que un sistema cumple tanto con sus especificaciones como con las
expectativas del cliente.

4. EVOLUCIÓN: una vez implementado el software, este seguirá siendo modificado para que siga respondiendo a la
organización y su contexto durante su vida útil.

CAPÍTULO 3: DESARROLLO DIRIGIDO POR UN PLAN

El paradigma tradicional planteado por IS indica que el desarrollo se basa en comenzar analizando cuáles son las
necesidades del cliente y, en base a estas, elaborar un plan que ira encadenando una serie de etapas, hasta que
finalmente el software queda funcionando.

Desarrollo basado en un plan vs. Metodologías Ágiles

Premisas del Desarrollo Tradicional:
1. Una vez establecido el plan, no se puede cambiar.
Ventajas: permite presupuestar costos y tiempos y permite asegurarnos que, cuando se entregue, este contemple
todas las necesidades del cliente.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

Desventajas: 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, que los requerimientos deben obtenerse al
comienzo sin posibilidad de cambio, es difícil de aplicar en proyectos grandes o complejos.
2. Cuando la organización no se mueve en un escenario cambiante, está forma dirigida por un plan es la más
conveniente.

¿Cuándo optar por desarrollo basado en un plan o metodologías ágiles?

o Si es posible tener una especificación y un diseño muy detallados antes de dirigirse a la implementación,
probablemente use un enfoque basado en un plan.
o Si es práctica una estrategia de entrega incremental, le sirve al cliente utilizar un software con
funcionalidades acotadas y la retroalimentación del cliente es importante uso de métodos ágiles.
o ¿Qué tan grande es el sistema que se desarrollará? Los métodos ágiles son más efectivos cuando el sistema
logra diseñarse con un pequeño equipo asignado que se comunique de manera informal. Esto sería imposible
para los grandes sistemas que precisan equipos de desarrollo más amplios, de manera que tal vez se utilice un
enfoque basado en un plan.
o ¿Qué tipo de sistema se desarrollará? Los sistemas que demandan mucho análisis antes de la
implementación (por ejemplo, sistemas que responden a una normativa compleja o que se vinculan con
dispositivos o maquinarias), por lo general, necesitan un diseño bastante detallado para realizar este análisis. En
tales circunstancias, quizá sea mejor un enfoque basado en un plan.
o ¿Cómo está organizado el equipo de desarrollo? Si el equipo de desarrollo está distribuido, o si parte del
desarrollo se subcontrata, entonces tal vez se requiera elaborar documentos de diseño para comunicarse a
través de los equipos de desarrollo. Quizá se necesite planear por adelantado cuáles son.
o ¿Existen problemas culturales que afecten el desarrollo del sistema? Las organizaciones de ingeniería
tradicionales presentan una cultura de desarrollo basada en un plan, pues es una norma en ingeniería. Esto
requiere comúnmente una amplia documentación de diseño, propia de los desarrollos tradicionales, en vez del
conocimiento informal que se utiliza en los procesos ágiles.
o Si el sistema está sujeto a regulación externa para ser aprobado (por ejemplo, la Agencia de Aviación Federal
[FAA] estadounidense aprueba el software que es crítico para la operación de una aeronave), entonces, tal vez se
requerirá documentación detallada como parte del sistema de seguridad.

Desarrollo de sistemas dirigidos por un plan – enfoque clásico

ETAPAS DEL MODELO TRADICIONAL: modelo lineal, en el cual se desencadena las siguientes etapas (solo cuando
finaliza una etapa se pasa a la siguiente):
o Análisis: Es la etapa en la cual los analistas relevan una determinada organización para detectar sus
necesidades y los problemas a ser resueltos por un sistema informático. El resultado de esta etapa en un
documento que (cumpliendo determinadas reglas y convenciones) refleje todos los requerimientos de los
usuarios.
o Diseño: En esta etapa se diseña una solución informática a los problemas encontrados, contemplando los
requerimientos obtenidos en la fase anterior. Generan la documentación, con el detalle técnico necesario, para
que los programadores puedan construir el código.
o Codificación: Basado en las especificaciones del diseño, los programadores construyen el código del
programa, utilizando algún lenguaje de programación.
o Prueba: Consiste en buscar posibles errores en un sistema antes de que este comience a utilizarse. Los
errores encontrados se reportan para su corrección.
o Puesta en Marcha/Implementación: En esta etapa se instala el programa en las computadoras del cliente y se
capacita a los usuarios para que puedan utilizar el nuevo software.

PROPUESTA INTEGRAL: el modelo tradicional no abarca todas las etapas existentes en un proyecto de
construcción, se lo mejora agregando/reformulando algunas etapas:
o Comunicación Inicial: primer contacto entre desarrollador y cliente. Se acuerdan lineamientos básicos del
proyecto y se presentan en forma global los problemas, las necesidades y las restricciones existentes.
o Estudio de Factibilidad: Es necesario entonces estudiar la factibilidad o no seguir adelante con el proyecto.
o Plan y presupuesto: Es necesario planificar el proyecto de desarrollo en su totalidad. Estimar recursos: Humanos
(contratación y/o asignación temporal de personal), de software (licencias, entornos de desarrollo, componentes
reutilizables, etc.) y de entorno (hardware, espacio físico de trabajo, etc.). En función del tipo de software a
desarrollar, se define el modelo de desarrollo de SW a utilizar, estimación de tiempos por c/etapas. Elaboración

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

de un primer presupuesto económico para presentarle al cliente, no será posible presupuestar de antemano la
totalidad del sistema (presupuesto parcial que alcance solo las próximas etapas).
o Construcción de la aplicación utilizando un modelo: Los modelos de desarrollo de software abarcan las etapas
de análisis, diseño, codificación, prueba y puesta en marcha.
o Garantía: es necesario contemplar una etapa en donde se solucionen los errores que pueda tener el software. El
costo de corregir los eventuales problemas debe ser contemplado dentro de los costos generales del proyecto.
o Mantenimiento: Ni los sistemas ni las organizaciones son estáticos. Una vez instalado un sistema es posible que
sean necesarios cambios o mejoras. Existen casos donde esta etapa no se lleva a cabo.
Complicaciones en el desarrollo de un software
1. El tamaño del software a desarrollar: es más difícil desarrollar un software de gran tamaño que uno pequeño.
Por otro lado, un software pequeño conlleva poco presupuesto, con lo cual el desarrollo debe ser lo más simple
posible.

2. La complejidad para obtener requerimientos: la comunicación entre los especialistas en informática y los
clientes no es tarea sencilla. Los usuarios no conocen de sistemas. Pueden no tener en claro sus necesidades o no
saberlas expresarlas correctamente. Los analistas, por su lado, suelen no comprender los términos propios de la
organización, o cómo funcionan sus procesos más complejos.

3. La complejidad técnica: muchas veces deben desarrollarse software para un nuevo sistema operativo; o con
nuevos lenguajes de programación; o vinculados con dispositivos de hardware especial. Estos pueden ser
desafíos adicionales para el desarrollador, que quizá no tiene la suficiente experiencia en esa tecnología.

4. El tiempo disponible: muchas veces las organizaciones requieren tener disponible el software para una fecha
específica.

5. El riesgo: existen situaciones propias del proyecto que implican riesgos concretos. Se debe prestar especial
atención a estas situaciones ya que pueden determinar la necesidad de redefinir o incluso de abandonar el
proyecto.

MODELOS:
“LINEAL SECUENCIAL” (EN CASCADA O CICLO DE VIDA)
Ingeniería de requerimientos: hace referencia a una actitud
activa en la búsqueda de todos los problemas y en tratar de
obtener los requerimientos de la manera más completa y
exacta posible, aun aquellos que los usuarios ocultan o
desconocen. Además de relevar usuarios debe también
analizarse la documentación, la normativa vigente y los procesos
internos de la organización.
Despliegue: el software ya probado es instalado en el entorno
productivo del cliente. Deben contemplarse todas las tareas
adicionales necesarias para que el sistema esté operativo,
incluyendo la instalación de servidores y redes, la configuración
de hardware y software de los equipos de trabajo, la entrega de
documentación y manuales y la provisión de todo aquel
material necesario para la operación del sistema, además de la
correcta capacitación.

Ventajas  Pueden producirse estados de bloqueos por

 Modelo Simple, sencillo y probado. la secuencialidad de las etapas.
 Menos costoso y más rápido.  Es difícil que el cliente especifique todos los
Desventajas requerimientos al inicio.
 Los proyectos rara vez siguen el flujo  No prevé la posibilidad de introducir cambios
secuencial. en el medio del proyecto.
 Los errores de las primeras etapas se  El cliente no ve el proyecto hasta que el
arrastran a las posteriores. software está terminado.

“SECUENCIAL ITERATIVO O INCREMENTAL”

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

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. Una vez implementada esta
versión, se vuelve a emplear el modelo lineal secuencial para producir una nueva versión más completa. En cada
iteración de entrega un sistema completo y operativo. El cliente puede probar el sistema en entornos productivos. No
debe confundirse con Desarrollo Ágil. En este modelo los componentes de la primera versión están todos planeados y
definidos al comienzo. En desarrollo ágil, las pequeñas mejoras se van incorporando en forma periódica. No existe una
planificación inicial.
Ventajas
 Entregas parciales reducen complejidad y
mejoran estimaciones Desventajas
 El usuario recibe rápidamente una primera  Sigue siendo secuencial, aunque menos
versión para cubrir sus primeras necesidades estricto.
 Requiere menos personal concurrente y los  Errores se arrastran
recursos se asignan mejor en el tiempo  Bloqueos por secuencialidad
 Implementaciones parciales son más sencillas
que una total.

“PROTOTIPOS”
Este prototipo es una versión acotada del software, construida solamente a los fines de poder
interactuar con el cliente y poder tener una mejor visión de que es lo que se está planificando
hacer. Seguramente no todas las funciones, pantallas u opciones del software serán incluidas en
el prototipo, que podrá ser parcial e incluir sólo aquellas funciones más representativas. Puede
tener varias versiones, cambios o ajustes. Una vez que el prototipo es aprobado y que los
requerimientos han quedado finalmente claros, este debe desecharse para iniciar la
construcción del software real. Para ello, podrá utilizarse cualquiera de los modelos de
desarrollo, según las necesidades específicas del proyecto.
Etapas del modelo
a) Relevamiento rápido: esta etapa se realiza un relevamiento general y luego de relevan con
más detalle aquellas opciones que serán incluidas en el prototipo. No se hace de un modo tan exhaustivo.
b) Diseño del Prototipo: se diseña el prototipo, detallando el modo en el que se presentará y cuál será el alcance de
cada una de las opciones de este.
c) Generación del prototipo: para construirlo, puede utilizarse el mismo lenguaje de programación que luego se
utilizará para programar el sistema, usar alguna herramienta específica de desarrollo de prototipos, o incluso mostrar
ejemplos gráficos sin programación.
d) Prueba: si el prototipo es un software operable, el mismo deberá ser probado para buscar posibles errores.
e) Despliegue y retroalimentación: no se entrega el prototipo al cliente, sino que el desarrollador lo ejecuta y analiza
con él. A partir de este análisis, podría modificarse el prototipo, construirse uno nuevo o comenzar el desarrollo final.
f) Construcción de la aplicación utilizando un modelo: una vez definidos los requerimientos o probada alguna
funcionalidad específica, de utilizará el prototipo como un elemento de análisis y diseño y se generará la aplicación
final, utilizando alguno de los modelos.
Ventajas no es un producto para usarse
 Permite una mejor definición y comprensión operativamente.
de los requerimientos iniciales.  El desarrollador puede pretender ajustar el
 Permite un testeo de aquellas funciones prototipo y entregarlo como producto final,
técnicamente complejas. incumpliendo pautas de calidad o seguridad
 Reduce la incertidumbre al brindar al cliente en el desarrollo.
un modelo real de lo que será el futuro  Algunas de las funcionalidades presentes en
sistema. el prototipo podrían no ser tenidas en cuenta
en la versión final o quizá sean imposibles de
construir en el entorno real.

Desventajas
 Si es un software, el cliente puede pretender
usar el prototipo. Debe tenerse en claro que

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

“ESPIRAL”
Las primeras de estas iteraciones del espiral podrían corresponder a una
primera versión o bien al desarrollo de un prototipo. Luego aparecerán,
de modo similar al modelo lineal secuencial iterativo, diferentes
versiones operativas y más completas del software hasta que,
finalmente, se completa el software. 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 estas iteraciones se evalúan los riesgos del
proyecto. A partir de dicho análisis el proyecto puede ser modificado,
acotado, puesto en pausa o incluso abortado sí las condiciones de riesgo
evaluado así lo imponen.

Ventajas
 Las entregas sucesivas y el análisis de riesgo lo vuelven un modelo apto para desarrollos en entornos
riesgosos y con incertidumbre.
 Como otros modelos incrementales, puede utilizarse durante todo el ciclo de vida útil de un sistema,
produciendo sucesivas versiones mejoradas del producto inicial.
Desventajas
 No es simple medir los riesgos, mucho menos cuando de ellos depende o no la continuidad del proyecto. Un
análisis impreciso llevaría a decisiones equivocadas.
 No siempre el cliente entiende que, a pesas de sus etapas y mejoras sucesivas, es un modelo controlado con
un final previamente planificado.
 Puede resultar más caro que otros modelos por los costos de las actividades de medición de riesgos, aunque
también puede permitir ahorros si se toman medidas correctivas oportunamente.
“DESARROLLO RÁPIDO DE APLICACIONES”
0Los actuales entornos avanzados de desarrollo de aplicaciones proveen
a los desarrolladores de poderosas herramientas que permiten generar
código con gran rapidez y exactitud. Refiere a la posibilidad de generar
aplicaciones con mayor velocidad que los desarrollos tradicionales. Las
aplicaciones son conocidas como RAD. Para agilizar los tiempos de
desarrollo el software debe dividirse 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 de calidad en tiempos que van de 30 a 90 días.

Ventajas  No todos los proyectos pueden dividirse ni

 Los tiempos de desarrollo se acortan son aptos para desarrollo con herramientas
significativamente. RAD.
 También se reducen los tiempos de prueba y  El código generado en forma automática
los errores no detectados. suele tener menor performance y consumir
 Pueden construirse sistemas portables o de más recursos.
fácil migración entre diferentes entornos y  Se complica su implementación en proyectos
sistemas operativos. grandes porque requiere mucho personal en
Desventajas forma concurrente.
 El cliente también debe comprometerse con
los plazos cortos de desarrollo: asignar más
personal y con más carga horaria.
OTROS MODELOS
a. Desarrollo Basado en Componentes
Centra su desarrollo en la reutilización de software y en el ensamble de componentes existentes. Suele usarse para
software comercial: la aplicación se desarrolla parcialmente, con opciones genéricas ya programadas y la posibilidad
de parametrizar los requerimientos específicos del cliente.
Ventajas
 Implementación rápida de un sistema fiable.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

 Posibilita analizar el software antes de  Se facilita la actualización, ya que el

implementarlo y ver si es adecuado para las desarrollador puede actualizar opciones
necesidades de la organización. generales para todos sus clientes.
 Ahorro de costos.
 Tiempos de desarrollo más cortos y con
menos riesgo.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

 Posibilidad de utilizar software como servicios

(en la nube).
b. Métodos Formales
Busca hallar modelos matemáticos formales para asegurar un desarrollo de software libre de errores. Útil cuando se
requiere software con alto grado de precisión (diagnóstico médico o vehículos autónomos, aviones, etc.). No es
utilizado para el desarrollo de SW comercial.

Elección de un modelo adecuado

1. TAMAÑO
-sistemas de tamaño pequeño: modelo lineal secuencial.
- sistemas de gran tamaño: modelos “evolutivos”, es decir, que permiten construir versiones sucesivas e
incrementales.
2. COMPLEJIDAD DE LOS REQUERIMIENTOS
-modelo de prototipo ya que ayuda a la comprensión de los requerimientos.
- modelos evolutivos, ya que evitan que todos los requerimientos sean explicitados al comienzo del relevamiento.
3. COMPLEJIDAD TÉCNICA
-modelo de prototipo, para ir probando funcionalidades técnicas complejas.
- en espiral ya que permite contemplar y monitorear riesgos técnicos conforme se avance con el desarrollo.
4. TIEMPOS DISPONIBLES
- modelo de desarrollo rápido de aplicaciones permite reducir los tiempos de generación de aplicaciones.
5. ENTORNOS RIESGOSOS
- modelo en espiral contempla situaciones de riesgo y la evaluación de impacto sobre el sistema.
Limitaciones

Existen escenarios en los cuáles los modelos se vuelven ineficaces.

 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 determinado tipo de organizaciones que se enfrentan a
escenarios de cambio permanente.
 La documentación y los procesos formales no siempre son bienvenidos por todas las organizaciones.
CAPÍTULO 4: DESARROLLO ÁGIL DE SOFTWARE

Metodología Ágil
Las organizaciones operan actualmente en entornos que cambian constantemente. Sus procesos deben ser flexibles y
adaptarse con rapidez al contexto. Las metodologías ágiles pueden producir rápidamente software útil, de calidad y
en periodos cortos de tiempo. El software se desarrolla como una serie de incrementos que agregan sucesivamente
nuevas funcionalidades a una aplicación que está operativa, pero a la vez en permanente cambio.
El desarrollo se realiza mediante equipos pequeños de gente altamente capacitada, que comparte inicialmente la
visión general del producto o servicio que se quiere implementar. Sobre ella, van ejecutando pequeños incrementos,
de acuerdo con las prioridades definidas por el cliente. Los ciclos breves de desarrollo se llaman Iteraciones, o sprints.
Cada iteración del ciclo de vida incluye:

- planificación - revisión
- análisis de requerimientos - implementación
- diseño - documentación
- codificación

Metodología Ágil vs Tradicional

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

Modelos Tradicionales Modelos Ágiles

Útiles para organizaciones que operan en entornos Útiles para organizaciones que operan en entornos
estables y con normas y procesos definidos y para cambiantes, con procesos flexibles y donde se privilegia tener
software con funcionalidades críticas. un software siempre listo y con posibilidad de cambios.

Requisitos definidos al inicio. No existe una especificación inicial detallada del sistema.

Sin posibilidad de cambios. Los cambios son frecuentes conforme se avanza con el
desarrollo.

El sistema se entrega en forma completa (o en El sistema está en constante desarrollo. Se incorporan

sucesivos módulos completos). permanentemente nuevas funcionalidades.

El usuario no forma parte del equipo de desarrollo. La participación del usuario es vital ya que participa en la
especificación y evaluación de cada nueva versión.

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

El Manifiesto Ágil y los principios que guían el desarrollo ágil

El “Manifiesto Ágil” es un documento firmado en 2001 sobre técnicas y procesos para desarrollar software compuesto
por cuatro valores y doce principios de la filosofía de métodos ágiles. Los firmantes valoran:

 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

Son principios que rigen el desarrollo ágil:

1. La principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.

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

3. Entregar con frecuencia software que funcione en períodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana.

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

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

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo
es la conversación cara a cara.

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

8. Los procesos ágiles promueven el desarrollo sostenido. El ritmo es constante e indefinido.

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

10. Es esencial la simplicidad como arte de maximizar la cantidad de trabajo.

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

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

Ventajas

 Ofrecen una rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su
proceso iterativo.

 El cliente puede observar cómo va avanzando el proyecto y opinar.

 Los entregables parciales permiten ir atacando los objetivos más sencillos, ganando tiempo y experiencia para
atacar los más complejos.

 Los cambios que requiera el cliente tendrán un menor impacto. Si el cliente quiere cambiar algo entregado,
solo se habrá perdido unas semanas de trabajo.

 Se reducen los tiempos y costos de capacitación e implementación.

 Se involucra desde un principio y se da un rol a todos los stakeholders.

Dificultades

 Si bien es atractivo el participar, los representantes del cliente a menudo tienen que seguir realizando sus
tareas habituales, con sus propios tiempos y presiones que los hace no poder estar a disposición del equipo de
desarrollo.

 Algunos miembros del equipo pueden no tener la personalidad para trabajar e integrarse en equipo.

 Priorizar los cambios sería difícil, sobre todo cuando son muchos participantes. Cada uno ofrece diversas
prioridades. Además, hay que consensuar las necesidades operativas con las políticas.

 Mantener la simplicidad requiere trabajo adicional, que entra en conflicto con la presión de fechas de
entrego.

 Muchas organizaciones pasan años cambiando su cultura, de tal modo que los procesos se definan y
continúen. Estas encuentran difícil moverse hacia un modelo de trabajo con procesos informales y definidos por
el equipo de desarrollo.

Limitaciones

 Falta de documentación del diseño, puede complicar la reusabilidad.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

 Falta de procesos rigurosos y documentación escrita puede dificultad la certificación/auditoría del software.

 Problemas derivados de la comunicación oral, que da lugar a la ambigüedad. No siempre se entienden el

usuario, que no entiende cuestiones técnicas, y el desarrollador, que no entiende del negocio.

 El desarrollo no siempre tiene la misma secuencialidad ni necesidades que las prioridades fijadas.

 Restricciones en cuanto a tamaño de los proyectos, para el desarrollo de software de seguridad crítica, o para
implementaciones dispersas geográficamente.

 Cuando un proyecto ágil fracasa no hay documentación para no volver a repetirlo.

 Los contratos son por tiempo insumido y no siempre fáciles de administrar ni de controlar.

 Son difíciles las subcontrataciones y la presupuestación.

PROGRAMACIÓN EXTREMA

Es un método ágil muy difundido que integra un rango de buenas prácticas de programación. Es una metodología
centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software ,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen
clima de trabajo.
Valores

1. Simplicidad: se simplifica el diseño para agilizar el desarrollo y facilitar el entendimiento.

2. Comunicación: tanto en el equipo de trabajo como con el cliente. Fomenta un ambiente de cooperación y
unidad. Como el cliente es integrante del equipo, su opinión se conoce en tiempo real.

3. Retroalimentación: concreta y frecuente del cliente, del equipo y de los usuarios finales, para dirigir el
esfuerzo eficientemente.

4. Coraje: los programadores deben sentirse cómodos para reconstruir su código cuando sea necesario, o
desecharlo si es obsoleto, y persistir ante problemas complejos.

5. Respeto: entre el equipo, así XP puede aplicarse efectivamente.

Prácticas

o Planeación incremental: Los requerimientos se registran en tarjetas de historia, que se van incluyendo en
liberaciones según el tiempo disponible y la prioridad relativa.

o Liberaciones pequeñas: Al principio se desarrolla el conjunto mínimo de funcionalidad útil, luego se agregan
funcionalidades incrementando las funcionalidades de la primera liberación.

o Diseño simple: suficiente para cubrir solo aquellos requerimientos actuales.

o Desarrollo de la primera prueba: Las pruebas de unidad son frecuentes y continuas. Se escribe el código de la
prueba antes que la codificación, para tener de referencia.

o Refactorización: Se espera que todos los desarrolladores refactoricen de manera continúa el código y se
encuentren mejoras.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

o Programación en pares: cada uno comprueba el trabajo del otro, y se ofrecen apoyo.

o Propiedad colectiva: no se desarrollan islas de experiencia, todos son responsables de todo el código.

o Integración continua: tan pronto como esté completa una tarea, se integra con todo el sistema y se prueba
unidad e integración.

o Ritmo sustentable: no se aceptan grandes cantidades de tiempo extra ya que reduce la calidad del código y la
productividad.

o Cliente en sitio: un representante del cliente tiene que dispones de tiempo completa 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  Entrenador (coach)

 Cliente  Consultor
 Encargado de pruebas (tester)  Gestor (Big Boss)
 Encargado de seguimiento (tracker)
Ciclo de desarrollo de la programación extrema
Los requerimientos de software se expresan en historias de usuario, definidos y priorizados junto con el cliente. Cada
historia es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas
pocas semanas. Una vez diseñadas, el equipo de desarrollo las descompone en tareas y estima recursos requeridos
para implementarlas. El cliente participa en el desarrollo y es responsable de definir las pruebas necesarias para la
aceptación del software.
Pruebas en XP
Una fortaleza particular de la programación extrema, antes de crear una característica del programa, es el desarrollo
de pruebas automatizadas. Las características clave son:
 Desarrollo de la primera prueba: las pruebas se elaboran antes de escribir el código, y se ejecuta a medida
que se escribe, para detectar errores durante el desarrollo.
 Desarrollo de pruebas incrementales a partir de escenarios: el papel del cliente en este proceso es ayudar a
desarrollar pruebas de aceptación para las historias. Las mismas, como el desarrollo, son incrementales.
 Involucramiento del usuario en el desarrollo y la validación de pruebas: todo código nuevo se válida para
garantizar que eso sea lo que se necesita. Contar con el cliente para apoyar el desarrollo de pruebas de
aceptación puede ser una gran dificultad.
 El uso de marcos de pruebas automatizadas: Es esencial para el desarrollo de la primera prueba. Estas se
escriben como componentes ejecutables antes de implementar la tarea. Dichos componentes son
independientes, simulan el envío de la entrada a probar y verifica que el resultado cumple con la salida esperada.
Un marco de pruebas automatizadas es un sistema que facilita la escritura de pruebas realizables y envía una
serie de pruebas para su ejecución. Conforme se automatizan, siempre hay una serie de pruebas que se ejecutan
rápida y fácilmente, que pueden correrse de inmediato cuando se introduce un nuevo código.
Programación en pares
Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el código, las cuales
deben ejecutarse satisfactoriamente cuando el código nuevo se integre.
Roles de esta técnica:
a. Conductor: es el que implementa el código
b. Acompañante: observa y corrige en todo momento los errores cometidos por el conductor, considera soluciones
alternativas y sugiere nuevos casos de prueba.
Ventajas de la programación en parejas:
 Apoya la idea de la propiedad y responsabilidad colectivas para el sistema. El equipo tiene responsabilidad
colectiva para resolver dichos problemas.
 Actúa como un proceso de revisión informal, porque al menos dos personas observan cada línea de código.
 Ayuda a la refactorización, que es un proceso de mejoramiento del software.
 Enseñanza. La programación por parejas realmente mejora la distribución de conocimiento entre el equipo de un
modo rápido.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

 Múltiples desarrolladores contribuyen al diseño. Esto ayuda a crear mejores soluciones.

 Mayor disciplina. Se concentran en lo que tienen que hacer en lugar de tomar largos descansos.
Ventajas de XP
 Se adapta al desarrollo de sistemas pequeños y grandes.
 Optimiza el tiempo de desarrollo.
 Permite realizar el desarrollo del sistema en parejas para complementar los conocimientos.
 El código es sencillo y entendible, además de la poca documentación a elaborar para el desarrollo del sistema.
Desventajas de XP
 No se tiene la definición del costo y el tiempo de desarrollo, nadie puede decir que el cliente no querrá una
función más.
 Se necesita de la presencia constante del usuario, muy difícil de lograr.
 Algunos desarrolladores son celosos del código que escriben y no les es grato que alguien más modifique las
funciones que realizó o que su código sea desechado por no cumplir con el estado
SCRUM
No refiere solamente a un modelo de construcción de software, sino a metodología ágil enfocada en la gestión
general de proyectos.
El proceso Scrum
1. Planeación del bosquejo, se establecen los objetivos generales del proyecto y el diseño de la arquitectura del
software.
2. Ciclos (Sprints), donde cada uno desarrolla un incremento del sistema. En cada sprint, se valora el trabajo a
realizar, se seleccionan las particularidades a desarrollar y se implementa. Al final de un sprint, la funcionalidad se
entrega.
3. Revisión de Sprint y evaluación de posibles mejoras.
Características del proceso
1. Los Sprints tienen longitud fija (de 2 a 4 semanas). Miden el ritmo del trabajo.
2. El punto de partida para la planeación es el Product Backlog, la lista de trabajo pendiente de realizar. Los
nuevos requerimientos se incorporan a esta lista. Al comenzar un sprint, se revisan tareas pendientes, se
priorizan y se deciden las que serán desarrolladas en el mismo.
3. La fase de selección de tareas incluye a todo el equipo, para priorizar y elegir las características y la
funcionalidad a desarrollar.
4. Una vez seleccionadas las tareas, el equipo se organiza para desarrollar el software. Para revisar progreso y
reasignar prioridades, se realizan reuniones diarias breves. Durante esta etapa, el equipo se aísla del cliente y
la organización, comunicándose a través del Scrum Master. Este protege al equipo de desarrollo de
distracciones externas y atiende las necesidades que plantean en reuniones diarias.
5. La forma en que el trabajo se realiza puede variar, depende del problema y del equipo.
6. Al final del sprint, el trabajo se revisa y se presenta a los interesados.
Roles en Scrum
 El Product Owner es la persona responsable de lograr el máximo valor empresarial para el proyecto. Es
responsable de la articulación de requisitos del cliente.
 El Equipo Scrum es responsable de la comprensión de los requisitos y de la creación de los entregables.
 El Scrum Master es un facilitador que asegura que el equipo Scrum esté dotado de un ambiente propicio para
completar el proyecto con éxito. Guía, facilita y les enseña las prácticas de Scrum a todos los involucrados;
elimina los impedimentos que encuentra el equipo; y asegura que se estén siguiendo los procesos de Scrum
Las ceremonias de Scrum
 Sprint Planning o Planificación Inicial, con la participación de todo el equipo, donde el PO presenta la versión
actualizada y priorizada del Backlog, para que el equipo pueda estimar las tareas a incluir en el próximo sprint. Se
define qué y cómo se hará.
 Daily Meeting, donde cada miembro del equipo informa que tarea realizará ese día, e informa impedimentos
detectados.
 Sprint Review, la reunión final del sprint, donde el PO y el equipo presentan a los SH el incremento
terminado, para su inspección. No es una demo, se muestra software funcionando en producción. De esta
reunión pueden surgir nuevas necesidades que pasan a actualizar el Backlog.
 Sprint Retrospective, se reflexiona sobre el sprint que ha finalizado, identificando posibles mejoras, además
de aciertos y fallos.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)

 lOMoARcPSD|23408676

 Refinamiento del Product Backlog, se depura el listado pendiente y se completan, refinan o aclaran ciertas
historias de usuario que pudieron quedar pendientes.
Ventajas
 Adaptabilidad: las entregas iterativas hacen que los proyectos sean adaptables y abiertos a cambios.
 Transparencia: el Table hace visible el avance de cada Sprint y al ser compartido lleva a un ambiente de
trabajo abierto.
 Retroalimentación continua: a través de reuniones diarias y revisiones al finalizar cada sprint.
 Mejora continua: los entregables mejoran progresivamente a través del proceso de priorización del Product
Backlog.
 Entrega continua de valor: los procesos iterativos permiten la entrega continua de valor tan frecuentemente
como el cliente lo requiere.
 Ritmo sostenible: las personas pueden trabajar a un paso cómodo que puede continuar indefinidamente.
 Motivación: las reuniones diarias y retro conducen a mayores niveles de motivación entre los empleados.
 Resolución rápida de problemas: colaboración de equipos multi-funcionales conducen a la resolución de
problemas con mayor rapidez.
 Entregables efectivos: la confección del PB y las revisiones periódicas de entregables aseguran las entregas
efectivas para el cliente.
Críticas
 El equipo puede estresarse al estar de sprint en sprint inmerso en un ritmo muy intenso de trabajo.
 El equipo puede tentarse a tomar el camino más corto para sumar los puntos del sprint, sacrificando calidad o
seguridad.
 Es difícil de aplicar en grandes proyectos.
 Se requiere de un experto en la metodología para monitorear su cumplimiento.
 Es difícil de adoptar para proyectos restringidos a una fecha de entrega y precios cerrados por contrato.
 Presupone que el equipo está muy formado y motivado.
 Presupone que el cliente está muy involucrado en el desarrollo y revisa el avance de la funcionalidad.
 Muchas reuniones, por cortas que sean, pueden ocasionar pérdidas de productividad.
Conclusión de Metodologías Agiles
Los modelos de desarrollo ágil tienden, como su nombre lo indica, a agilizar y acotar los procesos tradicionales. Sin
embargo, existen metodologías y procesos para seguir.
En estos casos debemos recordar que:
• Metodologías ágiles no implica ausencia de documentación.
• Metodología ágil no implica suprimir etapas del ciclo de vida, en especial las pruebas.
• Metodología ágil no significa hacer todo más rápido. Hacer un producto de lleva tiempo y la calidad no se negocia.
• Metodologías ágiles no implica dejar de desarrollar actividades protectoras de la calidad y una adecuada gestión
del proyecto.

Descargado por Juan Aparicio (juangaparicio90@gmail.com)