Compilacion de Ingenieria de Software PDF

Con una visión
orientada a
proyectos
vinculados
con las
Ciencias
Económicas
Lic. César Ariel Briano

2021
PRIMERA EDCIÓN
Rev. 23.03
Compilación de Apuntes sobre Conceptos Fundamentales de la Ingeniería de Software - Lic. César Ariel Briano 1
Briano, Cesar Ariel
Compilación de apuntes sobre conceptos fundamentales de la Ingeniería de Software:
con una visión orientada a proyectos vinculados con las Ciencias Económicas / Cesar
Ariel Briano. - 1a ed. - Ciudad Autónoma de Buenos Aires: Cesar Ariel Briano, 2021.
Libro digital, PDF
Archivo Digital: descarga y online

ISBN 978-987-88-0152-0
1. Ingeniería de Software. I. Título.

CDD 004.071
Este libro está disponible gratis on-line en https://briano.com.ar/libro
Queda prohibida su comercialización y/o su distribución por cualquier medio que implique algún
tipo de pago o retribución, o que exija la registración de quien lo descargue.
Prólogo
Existe una enorme cantidad de material publicado sobre Ingeniería de software. Un puñado
de libros, incluso, se han convertido en Best Sellers y, también, en referencia mundial sobre el tema.
Sin embargo, nunca fue tarea sencilla seleccionar bibliografía para las materias de la Facultad
de Ciencias Económicas de la UBA. La razón: nuestro particular perfil. La mayoría de los desafíos que
tendrán nuestros profesionales sobre desarrollo de software será sobre sistemas de gestión para
organizaciones de diverso tipo. La bibliografía especializada tiene un alcance y profundidad que no
siempre es la adecuada. Algunos textos son excesivamente técnicos. Otros utilizan ejemplos
demasiado orientados a ingeniería o a otros países.
En algunos puntos la bibliografía nos excede y en otros nos queda corta. La visión local casi
nunca es abordada, y los problemas con los que habitualmente se enfrentan nuestros graduados no
siempre están contemplados en los libros de referencia.
Por esta razón, durante varios años, fui armando una serie de apuntes complementarios a la
bibliografía de la materia. Con el tiempo, se fueron actualizando y abarcando más temas, hasta que
finalmente, tuvo sentido compilarlos y armar esta publicación. Este libro, entonces, es una
compilación de 11 apuntes que abarcan las etapas del proceso de construcción de software. En cada
uno de ellos se hace foco en algunas temáticas que, a veces, quedan de lado en otros textos. En
todos los casos, siempre se trata de abordar cada tema desde una visión local y de las ciencias
económicas.
Finalmente, cabe aclarar que esta compilación no es un resumen de ningún libro, ni de la

materia. La ingeniería de software es mucho más amplia y compleja que lo que estos apuntes
pretenden abarcar. El estudio de la bibliografía es necesario e irremplazable.
Compilación de Apuntes sobre Conceptos Fundamentales de la Ingeniería de Software - Lic. César Ariel Briano
1
Índice de Contenido
Apunte 1 Conceptos Fundamentales de Ingeniería de Software ....................................... 6
1. Introducción ................................................................................................................................ 7
2. Un poco de historia ..................................................................................................................... 7
3. El software: Un producto ubicuo, indispensable y vital .............................................................. 8
4. La naturaleza del software ........................................................................................................ 11
5. Los problemas al desarrollar software ...................................................................................... 15
6. El software como ventaja competitiva. ..................................................................................... 16
7. Ingeniería de Software .............................................................................................................. 18
8. El proceso de desarrollo del software ....................................................................................... 19
9. Conclusiones .............................................................................................................................. 23
10. Bibliografía ................................................................................................................................. 23
Apunte 2 Conceptos Fundamentales del Desarrollo de Software Dirigido por un Plan ..... 24
1. Introducción .............................................................................................................................. 25
2. Desarrollo Dirigido por Plan versus Metodologías Agiles ......................................................... 25
3. Desarrollo de sistemas Dirigidos por un Plan. El enfoque clásico ............................................. 27
4. Una propuesta integral .............................................................................................................. 28
5. Distintos problemas y sistemas, distintos modelos .................................................................. 30
6. Modelo “Lineal Secuencial” (“En Cascada” o “Ciclo de Vida”) .................................................. 33
7. Modelo “Lineal Secuencial Iterativo o Incremental”................................................................. 35
8. Modelo de “Prototipos” ............................................................................................................ 36
9. Modelo en “Espiral” .................................................................................................................. 38
10. Modelo de “Desarrollo Rápido de Aplicaciones” ...................................................................... 40
11. Otros modelos ........................................................................................................................... 42
12. Elección de un modelo adecuado.............................................................................................. 43
13. Limitaciones ............................................................................................................................... 44
14. Bibliografía ................................................................................................................................. 44
Apunte 3 Conceptos Fundamentales del Desarrollo Ágil de Software ............................. 45

1. Introducción .............................................................................................................................. 46
2. Modelos Tradicionales versus Ágiles ......................................................................................... 46
3. El “Manifiesto Ágil”.................................................................................................................... 47
Valores del manifiesto Ágil ....................................................................................................... 48
Principios que rigen el desarrollo ágil....................................................................................... 48
4. Programación Extrema .............................................................................................................. 49
Valores de XP ............................................................................................................................ 49
Prácticas de XP .......................................................................................................................... 50
Roles en XP ............................................................................................................................... 51
Ciclo de desarrollo de la programación extrema...................................................................... 52
Las historias de usuario ............................................................................................................ 52
Pruebas en XP ........................................................................................................................... 53
Programación en pares ............................................................................................................. 54
Ventajas y desventajas de XP ................................................................................................... 54
5. Scrum ......................................................................................................................................... 55
El proceso Scrum ...................................................................................................................... 55
Roles en Scrum ......................................................................................................................... 56
Las ceremonias del Scrum ........................................................................................................ 57
El tablero Scrum........................................................................................................................ 58
2
¿Por qué utilizar Scrum? ........................................................................................................... 59
Críticas a la metodología Scrum ............................................................................................... 60
Scrum, no solo para desarrollo de Software ............................................................................ 60
6. Otras metodologías ágiles ......................................................................................................... 62
Metodología Crystal ................................................................................................................. 62
Método de Desarrollo de Sistemas Dinámicos ......................................................................... 63
7. Ventajas, dificultades y limitaciones de las metodologías ágiles .............................................. 63
Ventajas .................................................................................................................................... 63
Dificultades en la aplicación de los principios .......................................................................... 64
Limitaciones .............................................................................................................................. 65
8. Casos de estudio ........................................................................................................................ 65
Caso A: Éxito en metodología Scrum en un banco ................................................................... 66
Caso B: Después de mucho tiempo y esfuerzo, se logró el objetivo. ....................................... 66
Caso C: Scrum en la industria automotriz................................................................................. 67
Caso D: Problemas en metodología Scrum en una institución pública. ................................... 68
Caso E: Pérdida de tiempo y dinero en un banco. .................................................................... 68
9. Comentario final ........................................................................................................................ 69
10. Bibliografía y sitios consultados ................................................................................................ 70
Apunte 4 Ingeniería de Requerimientos Claves para un desarrollo exitoso ..................... 71

1. Introducción .............................................................................................................................. 72
2. Los resultados no siempre son exitosos .................................................................................... 72
3. Requerimientos contrapuestos ................................................................................................. 73
4. Tres conceptos clave sobre relevamiento ................................................................................. 74
5. El proceso de obtención de requerimientos ............................................................................. 75
6. Las situaciones habituales que dificultan el relevamiento ........................................................ 76
7. Otros problemas habitualmente no considerados .................................................................... 77
8. Escenarios hostiles..................................................................................................................... 78
9. Algunos mitos sobre el relevamiento ........................................................................................ 79
10. Un enfoque alternativo ............................................................................................................. 82
a. ¡Cuidado! Hay personas del otro lado. .............................................................................. 82
b. Ingeniería de requerimientos versus relevamiento. ......................................................... 83
c. Aprovechemos el primer encuentro. ................................................................................ 84
10. Relevamiento y Metodologías Agiles ........................................................................................ 85
11. Conclusiones .............................................................................................................................. 86
12. Bibliografía ................................................................................................................................. 86
Apunte 5 Conceptos Fundamentales del Diseño de Software ......................................... 87

1. Notas preliminares .................................................................................................................... 88
2. Repaso ....................................................................................................................................... 88
3. La etapa de diseño – Una mirada rápida ................................................................................... 89
4. El proceso del diseño ................................................................................................................. 91
5. El “arquitecto de software” ....................................................................................................... 93
6. Diseño de la Interfaz de usuario ................................................................................................ 95
7. El valor económico del diseño ................................................................................................... 97
8. Bibliografía ................................................................................................................................. 97
ANEXO 1 – Patrones Arquitectónicos ....................................................................................... 98
ANEXO 2 – Patrones de diseño ............................................................................................... 100
Apunte 6 Conceptos Fundamentales de la Codificación de Software ............................ 110

1. Introducción ............................................................................................................................ 111
3
2. La etapa de codificación de software ...................................................................................... 111
3. ¿Qué tareas realiza un programador? ..................................................................................... 112
4. EL proceso de la programación ............................................................................................... 116
5. La elección del lenguaje de programación .............................................................................. 117
6. Referencias .............................................................................................................................. 119
Apunte 7 Conceptos Fundamentales de las Pruebas de Software ................................. 120

1. Introducción ............................................................................................................................ 121
2. Buscar que falle, no probar que funcione ............................................................................... 121
3. La calidad y las pruebas ........................................................................................................... 122
4. La prueba es la única actividad optativa en el proceso de desarrollo..................................... 123
5. El equipo de pruebas ............................................................................................................... 124
6. Los casos de prueba................................................................................................................. 125
7. Los tipos de prueba ................................................................................................................. 126
8. ¿Caja blanca o caja negra? ...................................................................................................... 129
9. ¿Cuándo termina la prueba? ................................................................................................... 130
10. La depuración o debugging ..................................................................................................... 131
11. Consideración final .................................................................................................................. 133
12. Bibliografía ............................................................................................................................... 134
Apunte 8 Conceptos Fundamentales del Despliegue de Software ................................. 135

1. Introducción ............................................................................................................................ 136
2. Construir la versión final.......................................................................................................... 136
3. El manejo de múltiples versiones ............................................................................................ 138
4. La capacitación de usuarios ..................................................................................................... 140
5. Fechas de implementación ...................................................................................................... 141
6. Migración de datos .................................................................................................................. 144
7. Comenzando a operar ............................................................................................................. 145
8. La resistencia al cambio ........................................................................................................... 146
9. Bibliografía ............................................................................................................................... 147
Apunte 9 Conceptos Fundamentales del Mantenimiento de Software .......................... 148

1. Introducción ............................................................................................................................ 149
2. Definiciones ............................................................................................................................. 149
3. ¿Mantenimiento o Garantía? .................................................................................................. 150
4. Prueba versus Garantía ........................................................................................................... 151
5. La dificultad en los contratos de mantenimiento.................................................................... 152
6. El mantenimiento ocurre al final, pero se piensa al inicio ...................................................... 153
7. La preservación de los datos ................................................................................................... 154
8. Mantenimiento y gestión de sistemas heredados .................................................................. 155
9. Costos del mantenimiento ...................................................................................................... 155
10. Mantenimiento y Desarrollo Ágil. ........................................................................................... 156
11. El dilema del mantenimiento infinito ...................................................................................... 157
12. ¿Todo el software requiere mantenimiento? ......................................................................... 158
13. Bibliografía ............................................................................................................................... 159
Apunte 10 Conceptos Fundamentales de la Estimación, Costeo y Precio del Software .. 160

1. Introducción ............................................................................................................................ 161
2. Estimación de software ........................................................................................................... 161
3. Restricciones ............................................................................................................................ 163
4. Costo del software ................................................................................................................... 166
5. Presupuestación de software .................................................................................................. 167
6. Determinación del precio del software ................................................................................... 168
7. Particularidades del software .................................................................................................. 169
4
8. Presupuesto y costos de un desarrollo ágil ............................................................................. 169
9. Bibliografía ............................................................................................................................... 171
Apunte 11 Decisiones estratégicas antes de desarrollar software. ................................. 172

1. Introducción ............................................................................................................................ 173
2. El software no siempre es la solución ..................................................................................... 173
3. Desarrollar versus Comprar ..................................................................................................... 176
4. “On Premises” versus “Cloud”................................................................................................. 179
5. Tercerización (outsourcing) ..................................................................................................... 180
6. Conclusión ............................................................................................................................... 181
7. Bibliografía ............................................................................................................................... 181
Licencia, acuerdo de uso y distribución .......................................................................... 182
5
1
Apunte 1
Conceptos Fundamentales de
Ingeniería de Software
6
1. Introducción
El desarrollo de software se ha vuelto central en nuestros días. Las organizaciones necesitan

generar aplicaciones para interactuar con las nuevas generaciones de clientes y con los nuevos
modelos de negocios.
Por si faltaban ejemplos, la pandemia puso en evidencia como nunca en la historia, la

importancia del software. Al tiempo que la dura cuarentena nos impidió trabajar, estudiar, vender,
comprar y relacionarnos en forma presencial, también nos mostró que las operaciones a distancia
utilizando aplicaciones informáticas eran posibles e, incluso, permitían una nueva normalidad que
tenía algunas ventajas sobre la anterior.
En épocas de virtualidad, también comprendimos el rol primordial del software en las

empresas y en nuestra vida cotidiana. Si se caía Zoom, los chicos se quedaban sin clases. Si se caía
WhatsApp perdemos contacto con nuestro entorno. Si deja de operar el software de una
organización, esta desaparece del mundo por un rato. Si falla el campus virtual, no se podía cursar
en la Facultar. Ni que hablar con los sistemas de salud o emergencias. Esto representa una gran
responsabilidad para los desarrolladores: cuando el software deja de funcionar, las organizaciones
dejan de operar, y perjuicios pueden ser enormes.
Lo peor de la pandemia parece haber quedado atrás, pero, muchas de las cosas que nos
tomatón por sorpresa, se quedarán para siempre. Los dispositivos virtuales de enseñanza llegaron
para quedarse, los pagos digitales y por QR comienzan a desplazar al efectivo, preferimos los
trámites virtuales a las colas presenciales, las compras on-line se volvieron cotidianas, las reuniones
virtuales toman cada vez más protagonismo en las organizaciones… Y claro, nada reemplaza a un
encuentro presencial con amigos, pero cuando esto no es posible, un zoom a veces alcanza.
Aprendimos que internet, las apps, el celular y la computadora, que tanto nos ayudaron en
pandemia, pueden seguir siendo utilizadas ahora para mejorar nuestro día a día. Pero claro… para
que eso sea posible, el software tiene que funcionar bien.
El objetivo de este trabajo es comprender la importancia del software para los negocios y
para la vida cotidiana. La aplicación de principios de ingeniería para construir software se, vuelve
fundamental para desarrollar aplicaciones de calidad, que satisfagan a organizaciones con
necesidades cada vez más complejas y a usuarios cada vez más adaptados al mundo digital.
2. Un poco de historia
En el Blog del Museo de Informática de la Universidad Politécnica de Valencia se encuentra

la siguiente referencia sobre el origen de la Ingeniería de Software:
“El concepto de ingeniería del software surgió en 1968, tras una conferencia en
Garmisch (Alemania) que tuvo como objetivo resolver los problemas de la crisis del
software. El término crisis del software se usó desde finales de 1960 hasta mediados de
1980 para describir los frecuentes problemas que aparecían durante el proceso de
desarrollo de nuevo software. Tras la aparición de nuevo hardware basado en circuitos
integrados, comenzaron a desarrollarse sistemas y aplicaciones mucho más complejos,
7
que hasta entonces no era posible construir puesto que el hardware disponible no lo
permitía. Estos nuevos proyectos de desarrollo de software, en la mayoría de las
ocasiones, no se terminaban a tiempo, lo cual también provocaba que el presupuesto
final del software excediera de aquel que se había pactado. Algunos de estos proyectos
eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, etc.) que
sus implicaciones iban más allá de las pérdidas millonarias que causaban. Además, en
muchos casos el software no daba respuesta a las verdaderas necesidades del cliente o
había que ser un usuario experto para poder utilizarlo, todo ello sumado a que el
mantenimiento de los productos era complejo y muy costoso.”
En resumen, se detectó que los métodos de desarrollo de software informales, que hasta
entonces habían sido eficaces para proyectos pequeños, no eran suficientes para los nuevos
y grandes desafíos. Los desarrollos de software, que por aquel entonces muchas veces
provenían en un grupo de programadores entusiastas y autodidactas, que avanzaban a
prueba y error, debían comenzar a estandarizarse y profesionalizarse.
Los sistemas no podían tener resultados azarosos o depender de la pericia de un

programador estrella, que cuando se retiraba, dejaba código imposible de mantener por otros
colegas. Se necesitaban establecer procesos formales como los tenían otras disciplinas. Era
necesario empezar a formar profesionales especializados, que fueran capaces de lidiar con la
creciente complejidad de los nuevos sistemas. Se necesitaba crear la Ingeniería de Software.
3. El software: Un producto ubicuo, indispensable y vital
Durante mucho tiempo pensar en software era asociarlo inmediatamente con las
computadoras. Actualmente ya no es así. Por ejemplo, asociamos rápidamente Android o WhatsApp
con nuestro teléfono celular. El software es un producto ubicuo: está presente en todas partes.
Maneja computadoras y celulares, pero también robots, automóviles, aviones, equipamientos
médicos, juguetes, relojes, televisores, electrodomésticos… Ya no nos sorprendemos cuando
encontramos la versión “smart o inteligente” del producto que usamos por año, y eso es porque
tiene hardware y software embebido que lo potencia.
El software forma parte, para bien o para mal, en nuestra vida cotidiana y ha cambiado el
mundo tal y como lo conocíamos:
• Permite la creación de nuevos modelos de negocio (Ej. Uber, ventas por internet).
• Permite la creación de nuevas tecnologías (ej. Ingeniería genética).
• Permite la expansión de las tecnologías existentes (ej. Los mensajes de texto en las
comunicaciones).
• Reemplaza algunas tecnologías que pasan a quedar obsoletas (ej. Impresiones, CDs de
música).
• La inteligencia artificial potencia la investigación y la capacidad humana. (ej. nuevos

tratamientos y vacunas para el COVID).
8
• El análisis rápido y eficiente de grandes volúmenes de datos permite acceder a un nivel
de conocimiento superior y vuelve obsoletos algunos paradigmas de trabajo (ej. las
auditorias, que ya no necesitan recurrir a muestras para facilitar el análisis al ser posible
procesar el volumen completo de los datos sin esfuerzo adicional).
• Dejó de ser un producto empresarial para convertirse en un producto comercial, se

vende on-line e incluso en algunas tiendas físicas.
• Las empresas que desarrollan software son influyentes y dominan la economía mundial.
De las 10 empresas más grandes del mundo, 7 de ellas desarrollan o basan su negocio
principal en software.
• El software tiene un doble valor: es un producto en sí mismo, pero a la vez, la herramienta

que nos permite manejar uno de los grandes activos de la actualidad: la información.
• Internet, una red de hardware, pero basada y potenciada por el software, cambió para
siempre nuestra vida.
Claro, cuando las cosas andan bien todos nos beneficiamos. Pero ¿qué pasa cuando el
software falla? Las consecuencias pueden ser muy graves o incluso mortales: las empresas, los
bancos, el gobierno, las ciudades, los aviones, los servicios de emergencias necesitan software
seguro y que funcionen sin errores.
Y en este punto cabe entonces afirmar que el desarrollo de software es una actividad crítica.
Entregar software con fallas puede poner en riesgo y de modo directo, la salud, la seguridad, los
derechos o los bienes de las personas. Existe una clara responsabilidad de los profesionales que
desarrollan software en asegurar que su construcción ha seguido las mejores prácticas de desarrollo
y que ha alcanzado estándares de calidad.
Pueden presentarse cientos de ejemplos para reforzar estar idea, pero estos tres casos son
suficientes para entenderla:
El Boeing 787 podría pararse de repente por error software
Las tragedias aéreas, desgraciadamente, están sucediéndose con demasiada

frecuencia en los últimos tiempos. Pero más allá de errores humanos o de
maquinaria puntuales, nos llama estrepitosamente la atención que un avión se
pueda parar en pleno vuelvo. Sí, tal cual, mientras vuelas felizmente, en un golpe
de mala suerte, y por un error de software, un Boeing 787 podría detenerse. Y lo
peor de todo es que el piloto no podría hacer nada para evitarlo.
Esto ocurre cuatro años después de que el Boeing 787 comenzase a operar de
manera comercial, extendiendo así su innovación al terreno de la aviación
comercial.
Aportando más detalles sobre el problema en cuestión, se ha conocido que, si los
generadores eléctricos han permanecido encendidos de manera continua en los
último ocho meses, podrían desencadenar este grave problema.
Este problema en el software del Boeing 787 ha sido detectado por la
administración de la aviación federal (FAA), que ha elaborado un documento con
9
todas las pruebas derivadas de su investigación. Ahora se ha trasladado el problema
a los laboratorios, para realizar pruebas mucho más exhaustivas y poder poner una
solución a este fallo.
Este ejemplo nos muestra como un software con fallas puede afectar directamente
la seguridad de quienes vuelan en avión.
https://computerhoy.com/noticias/software/boeing-787-podria-pararse-
repente-error-software-27797
Una revisión invalida miles de estudios del cerebro.

Un fallo informático y malas prácticas generalizadas ponen en entredicho
15 años de investigaciones
La imagen por resonancia magnética funcional (fMRI, por sus siglas en inglés) es el
método más extendido para estudiar el esfuerzo que realiza una región
determinada del cerebro cuando se le asigna una tarea. La fMRI detecta qué zonas
están reclamando más energía del flujo sanguíneo gracias al oxígeno que
transporta. El resultado son esos mapas en 3D de la materia gris con unas zonas
iluminadas. Y los científicos nos dicen: esa es la parte de tu cabeza que se activa
cuando comes chocolate, cuando piensas en Trump, cuando ves películas tristes,
etc.
Ahora, un equipo de científicos liderados por Anders Eklund ha destapado que
muchas de esas zonas se pudieron iluminar por error, por un fallo del software y el
escaso rigor de algunos colegas. En su estudio, publicado en PNAS, cogieron 500
imágenes del cerebro en reposo, las que se usan como punto de partida para ver si
a partir de ahí el cerebro hace algo. Usaron los programas más comunes para
realizar tres millones de lecturas de esos cerebros en reposo. Esperaban un 5% de
falsos positivos y en algunos casos dieron hasta con un 70% de situaciones en las
que el programa iluminaba una región en la que no pasaba nada, dependiendo de
los parámetros mucho más exhaustivas y poder poner una solución a este fallo.
Estos programas dividen el cerebro humano en 100.000 voxels, que son como los
píxeles de una foto en versión tridimensional. El software interpreta las
indicaciones de la resonancia magnética e indica en cuáles habría actividad, a partir
de un umbral que en muchos casos ha sido más laxo de lo que debiera, propiciando
falsos positivos. Además, los autores de la revisión analizaron 241 estudios y
descubrieron que en el 40% no se habían aplicado las correcciones de software
necesarias para asegurarse, agravando el problema de los falsos positivos.
En este caso queda demostrado como un software con fallas puede afectar
directamente nuestra salud.
https://elpais.com/elpais/2016/07/26/ciencia/1469532340_615895.html
El Banco Nación duplica créditos y débitos de sus cuentas
Por un error informático, aparentemente vinculado a la Red Link, las operaciones

efectuadas por los clientes del Banco Nación durante el 20 y 21 de febrero de 2021
se duplicaron. De este modo, quien recibió transferencias en esos días, vio duplicar
el dinero que le ingresó en la cuenta, mientras aquellos que realizaron pagos,
sufrieron en el saldo el doble descuento del dinero.
Si bien el Banco solucionó rápidamente el inconveniente y lunes ya todo estaba
normalizado, esto representó un gran problema para muchas personas que
contaban con ese dinero para pasar el fin de semana. Se suman 2 agravantes: era
un fin de semana de vacaciones, donde muchos podían necesitar pagar
10
alojamiento, comida o entretenimiento, y además era un fin de semana cercano a
fin de mes, donde los saldos suelen ser menores.
Este es un claro ejemplo de cómo la falla en un software afecta directamente a los
bienes y derechos de las personas, que no contaron con su dinero para hacer vida
normal.
https://www.infobae.com/economia/2021/02/21/una-falla-tecnica-produjo-
duplicacion-de-debitos-en-cuentas-de-clientes-del-banco-nacion
4. La naturaleza del software
Vale citar en este punto, las consideraciones que Roger Pressman hace respecto de la
naturaleza del software en su libro “Ingeniería de Software, un enfoque práctico”. En dicha obra
destaca interesantes diferencias del desarrollo de software con respecto a la fabricación de
productos tradicionales. Estas diferencias explican, en cierto modo, el motivo por el cual los modos
de producción tradicional no siempre pueden adaptarse al desarrollo de software:
1. El software se desarrolla o modifica con el intelecto; no se manufactura en

el sentido clásico.
Aunque hay algunas similitudes entre el desarrollo de software y la fabricación

tradicional, por ejemplo, la del hardware, las dos actividades son diferentes en lo
fundamental: La industria tradicional compra materias primas y, mediante diversos
procesos industriales, las ensambla y las transforma para lograr un producto final. Esto
no ocurre al desarrollar software.
En ambas, la alta calidad se logra a través de un buen diseño, pero la fase de manufactura
del hardware introduce problemas de calidad que no existen en el software: Por ejemplo,
un componente defectuoso o de baja calidad puede originar que el producto final deba
ser desechado. En el software, los defectos o errores encontrados en la etapa de
producción pueden corregirse y el producto final no se ve afectado.
Ambas actividades dependen de personas, máquinas y herramientas, pero la relación

entre los individuos dedicados y el trabajo desarrollado es muy diferente. Las dos
actividades requieren la construcción de un “producto”, pero los enfoques son distintos.
Mientras los productos tradicionales se construyen en fábricas, procesando insumos
para convertirlos en el producto final, el software, casi en su totalidad, es una producción
intelectual.
2. El cálculo de costos es distinto y no siguen un esquema tradicional.
Por lo dicho anteriormente, la ecuación básica de costos (costo = materia prima + mano
de obra + costos de fabricación) no es aplicable al desarrollo de software. En este caso,
los costos principales se concentran, básicamente, en el costo de los recursos que se
emplean para desarrollarlo y el tiempo durante el cual son utilizados esos recursos. Los
principales recursos que utiliza la industria del software son recursos humanos.
11
Además, en un esquema productivo tradicional, los gastos de fabricación se prorratean
entre todas las unidades producidas. Cada unidad del producto tiene como costo el de
las materias primas que lo componen, la mano de obra directa y el proporcional de
gastos operativos.
En cambio, en el desarrollo del software todo el costo se lo lleva la primera unidad.

Producir una copia del software o cien mil es prácticamente el mismo. El costo de una
copia es a costo cero (o marginal). Lógicamente cuando se plantean desarrollos
comerciales, el costo de elaborar la primera unidad se va a prorratear entre todas las
unidades que se planifican vender. Pero en el caso de desarrollos particulares para un
cliente determinado, éste debe asumir todos los costos. Si después eventualmente el
desarrollador volviera a vender ese software (suponiendo por supuesto que no hubiera
impedimentos contractuales para hacerlo) sería todo ganancia, o casi todo, ya que por
lo general hay algunos costos de personalización o de comercialización de esta segunda
unidad.
Para ejemplificar lo dicho: Desarrollar una versión de Windows sale varios de millones
de dólares. Por supuesto Microsoft también espera vender millones de copias de ese
sistema operativo. El costo total de se proporcionará para obtener el costo de cada copia.
Si después se venden más copias de las estimadas, será todo ganancia. Si se venden
menos, tendrán pérdidas. Por supuesto otras industrias tienen esquemas parecidos,
como por ejemplo la farmacéutica donde no cargan a la primera vacuna todos los costos
que tuvo desarrollarla.
3. La mayor parte del software se construye para un uso individualizado,

aunque la industria se mueve hacia la construcción basada en
componentes.
A medida que evoluciona una disciplina, se crean un conjunto de componentes

estandarizados que facilitan la creación de productos. Los tornillos estándar y los
circuitos integrados preconstruidos, son solo dos de los miles de componentes estándar
que utilizan los ingenieros mecánicos y eléctricos conforme diseñan nuevos productos.
Los componentes reutilizables han sido creados para que el ingeniero pueda
concentrarse en los elementos verdaderamente innovadores de un diseño; es decir, en
las partes de éste que representan algo nuevo. No tendrá que perder tiempo en diseñar
un tornillo, simplemente indicar que debe utilizarse la pieza Philips M5 X 25mm de largo
y 2mm de diámetro.
En software, a pesar de facilidades de reutilizar el mismo componente para otro

desarrollo (basta simplemente copiar y pegar código), frecuentemente para cada nuevo
sistema se construye todo desde cero, en parte porque la rápida evolución que tiene la
industria que hace que muchas veces los programas queden obsoletos rápidamente.
Sin embargo, son muchas las ventajas de diseñar e implementar código que pueda
volverse a usar en muchos programas diferentes. Los modernos componentes
reutilizables incorporan tanto los datos, como el procesamiento que se les aplica, lo que
permite que el ingeniero de software cree nuevas aplicaciones a partir de partes
12
susceptibles de volverse a usar. Por ejemplo, las actuales interfaces interactivas de
usuario se construyen con componentes reutilizables que permiten la creación de
ventanas gráficas, menús desplegables y una amplia variedad de mecanismos de
interacción. Las estructuras de datos y el detalle de procesamiento que se requieren para
construir la interfaz están contenidos en una librería de componentes reusables para tal
fin.
Es importante destacar, conforme lo analizado en el punto anterior, que los mayores

costos que deben asumirse al construir componentes reutilizables1, se ven recuperados
con creces cuando estos componentes se incorporan en un segundo desarrollo.
También hay que mencionar que no estamos ante un proceso de reciclado o de

reutilización de componentes usados. Por las características propias del software los
componentes siempre funcionan a nuevo y hasta con la ventaja de tener pruebas o
mejoras previas que hacen que sea quizá mejor que un desarrollo nuevo.
4. El software no se “desgasta”.
En la siguiente figura se ilustra la tasa de falla del hardware como función del tiempo. La
relación, que por su forma se la suele conocer como “curva de la bañadera”, indica que
el hardware presenta una tasa de fallas relativamente elevada en una etapa temprana
de su vida (fallas que con frecuencia son atribuibles a defectos de diseño o
manufactura). Luego defectos se corrigen y la tasa de fallas se mantiene en un nivel
estable (muy bajo, generalmente) durante cierto tiempo. No obstante, conforme pasa
el tiempo, la tasa de fallas aumenta de nuevo a medida que los componentes del
hardware comienzan a sentir los efectos acumulativos de suciedad, vibración, abuso,
temperaturas extremas y muchos otros inconvenientes ambientales. En pocas palabras,
es el hardware comienza a desgastarse y a fallar.
1
Construir un componente reutilizable implica considerar que este pueda personalizarse fácilmente, por ejemplo,
mediante el uso de parámetros, de modo de que pueda ser utilizado en varias partes del desarrollo o en próximas
construcciones. Por ejemplo, en lugar componente que muestre un mensaje de error determinado, puede desarrollarse
uno genérico que reciba como un parámetro el mensaje a mostrar. Este componente podrá ser reutilizado cada vez que
se quiera mostrar un mensaje en pantalla. Es más complejo desarrollar un componente genérico, pero, sin embargo,
serán casi sin costo los usos sucesivos.
13
Sin embargo, no es el software el que se desgasta y suma problemas. A tal punto que, si
reemplazamos el hardware por uno nuevo, el software seguirá funcionando igual que
antes (o incluso mejor).
La curva de la siguiente figura muestra como los errores de programación, no detectados

en la etapa de prueba, ocasionarán tasas elevadas de fallas al comienzo de la vida de un
programa. Sin embargo, éstas se corrigen y la curva se aplana de modo permanente. El
software continúa funcionando de este modo hasta que, finalmente deja de operar.
Claro que tampoco es cierto que el software no tenga cambios y agregados durante su
vida útil. Con cada nueva versión, las tasa de “error inicial” vuelve a hacerse presente.
La curva de la tasa de fallas adopta entonces la forma de la “curva idealizada” que se
aprecia en la siguiente figura
La curva idealizada es una gran simplificación de los modelos reales de las fallas del
software. Aun así, la implicación está clara: el software no se desgasta, ¡pero sí se
degrada! Cuando por alguna circunstancia el software debe ser sometido a cambios y
agregados constantes, la curva no termina de estabilizarse. El nuevo cambio hace que la
curva se dispare otra vez. Poco a poco, el nivel mínimo de la tasa de fallas comienza a
aumentar: el software se está deteriorando como consecuencia del cambio. Será
necesario pensar en la conveniencia de reemplazar el software por otro que no requiera
ser modificado de modo permanente.
14
5. Los problemas al desarrollar software
Ya hemos mencionado la importancia del software en la actualidad. Esta enorme industria

se ha convertido en un factor dominante en las economías del mundo industrializado. Siete de las
diez empresas más grandes del mundo por capitalización bursátil tienen al software como su
principal producto. Equipos de especialistas de software, cada uno centrado en una parte de la
tecnología que se requiere para llegar a una aplicación compleja, han reemplazado al programador
de los primeros tiempos, que frecuentemente trabajaba en solitario o con algún amigo, en el garaje
de su casa2. A pesar de ello, los problemas que enfrentaba aquel programador son similares a los
que surgen cuando se construyen sistemas modernos:
1) Se demora mucho tiempo en desarrollar software. Habitualmente, más de lo previsto. No

es una tarea mecánica con tiempos preestablecidos.
2) Las estimaciones de costos y plazos de entrega no son sencillos. 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, frecuentemente mucho mayores a los estimados
inicialmente. Habitualmente, es necesario presentar un presupuesto de cuando costará el
desarrollo antes de tener los datos necesarios como para poder calcular de modo completo
los costos de un modo razonable (más adelante se profundizará este tema).
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. Los datos de la industria indican que
entre 60 y 80% de todo el esfuerzo dedicado al software, ocurrirá después de entregarlo al
cliente por primera vez.
7) Los tiempos del cliente son cada vez más cortos. Necesitan tener el software funcionando
“casi de inmediato”. No pueden esperar los meses o años que lleva un desarrollo completo
de una solución informática.
Cómo es posible que uno de los productos más importantes de nuestro siglo se enfrente a
tantas cuestiones aún no del todo resueltas ¿Es posible construir software de calidad y sin errores?
¿Se puede construir un software seguro y sin fallos catastróficos? La respuesta es sí, empleando
“Ingeniería de Software”
2
Muchas de las grandes empresas comenzaron de este modo: En 1975, Bill Gates junto a Paul Allen fundaron Microsoft
en el garaje donde se guardaba el auto de la familia Gates. En 1976, Steve Jobs junto a Steve Wozniack comenzaron
Apple en el garaje de la casa del padre de Jobs en Palo Alto, California. Google nació en el dormitorio del campus de
Larry Page, pero pronto, con su socio Sergey Brin, se mudaron al Garaje de la señora Susan Wojcicki, que alquilaron por
1700 dólares mensuales.
15
6. El software como ventaja competitiva.
Un sistema informático requiere de tres componentes básicos que interactúan ente sí

(cuatro, si consideramos al usuario). Es obvio que un software no funciona sino esta soportado en
un hardware determinado, el cual, a la vez, es inservible sino posee un software que lo administre.
Las redes de comunicación han sido la última pata en integrarse, pero hoy en día es imposible
concebir un software que funcione en un entorno aislado. Hardware, software y redes de
comunicación son los 3 componentes principales de un sistema informático:
Por supuesto, en cada proyecto informático, estos componentes tendrán un peso específico
diferente. Algunos, por ejemplo, solo funcionarán con un hardware particular, y este se llevará
buena parte de la inversión. En otros, el desarrollo será particularmente difícil, y el desafió mayor
caerá sobre la construcción del software. Y por supuesto, habrá proyectos donde las redes de
comunicaciones entre los dispositivos serán la parte central del mismo.
Michael Porter publicó en 1985 su libro “Ventaja Competitiva: Creación y sostenimiento de

un desempeño superior”. El modelo conceptual de la Cadena de Valor, planteado en dicho libro,
aportó a las empresas nuevas herramientas de gestión. Como gran resumen, plantea la idea de que
cada tarea que se realice en una empresa debe aportar al producto final más valor que el costo que
le genera dicha tarea. En base a esta cadena de valor las empresas consiguen “ventajas
competitivas”, es decir, adquieren en el mercado una posición favorable respecto de sus
competidores. Esta ventaja competitiva no es estática ni para siempre, sino que debe mantenerse
en el tiempo.
Las estrategias para crear y mantener una ventaja competitiva pueden basarse en obtener
un producto a un precio inferior a la de los competidores (reducción de costos), o bien un producto
diferenciado, es decir, un producto (o un bien o un servicio), que sea más atractivo para los
consumidores que aquel que le ofrecen sus competidores. Para cualquiera de las dos estrategias,
los sistemas informáticos son una herramienta fundamental.
16
Pero… Cuál de los tres componentes es aquel que puede generar un factor diferencial y una
ventaja competitiva. ¿Es el software?... ¿Es el hardware?... O ¿Es la red de comunicaciones?
¿Puede una empresa diferenciarse teniendo un hardware mejor o diferente que el de sus
competidores? Difícil. Hoy el equipamiento es casi un “commodity”3. Se consigue fácilmente en el
mercado y está disponible para cualquier empresa a un precio que puede pagar. Si bien es posible,
es difícil pensar que una organización pueda montar una estructura de hardware que, por algún
motivo, sea imposible de replicar por sus competidores. Es más, hoy en día es cada vez más factible
que podamos reducir enormemente los costos de infraestructura reemplazando hardware y
servidores por los servicios en la nube de Microsoft, Google o Amazon. Empresas más pequeñas,
que antes no podían competir con las grandes porque no podían montar un centro de cómputos de
envergadura, pueden hoy contratar enorme capacidad de almacenamiento y procesamiento en la
nube, simplemente pagando cuotas mensuales por los servicios que consuman.
De igual modo es también poco probable que podamos montar una red de comunicaciones
propia. Y aunque la construyamos, difícilmente logremos menores costos o servicios diferentes que
los que nuestros competidores consiguen contratando los servicios de Personal o Telefónica.
¿Y qué pasa con el software? Ahí la cosa es distinta. En efecto puedo construir un software
a medida y que agregue valor diferencial. Ese desarrollo es propio y no podrán tenerlo nuestros
competidores. Y aun cuando contratemos software ya desarrollado, SAP4, por ejemplo, las
personalizaciones y diferentes implementaciones que hagamos nos darán ventajas por sobre el
resto.
Para poner un ejemplo, tanto una empresa como sus competidores pueden acceder a los
servicios de mapas y geolocalización de Google. Pero mientras una empresa solo lo utilizan para
mostrar la ubicación de la sucursal más cercana al domicilio del cliente, otra puede mostrar en mapa
el trayecto que va realizando el delivery del producto, un servicio de valor agregado que
seguramente el comprador apreciará. Lo mismo ocurre con los bancos, muchos de ellos utilizan en
mismo software de base, pero la implementación que hacen es diferente y el modo en el que se
opera en sucursal y on-line es diferente.
En definitiva, tener un mejor software que un competidor, permitirá dar un mejor servicio,
reducir costos y/o aportarle al producto un valor agregado a la experiencia del cliente. No caben
dudas que, hoy en día, un buen software también permite generar ventajas competitivas y
alimenta la cadena de valor de la empresa.
Y claro, esto sirve por la positiva pero también por la negativa. Si el software falla, si no se
puede hacer una venta porque el sistema este caído, si es difícil de utilizar, si no puede accederse
desde dispositivos móviles, si tiene una interfaz confusa, si tiene fallas de seguridad, si queda
obsoleto, si tiene menos funcionalidad que el de los competidores, no solo no se obtendrán
3
Se denomina commodity a todo bien que es producido en masa por el hombre o incluso del cual existen enormes
cantidades disponibles en la naturaleza, y que por tanto tiene un valor o utilidad y un nivel de diferenciación o
especialización muy escaso.
4
SAP es una empresa alemana dedicada a desarrollas productos informáticos. Sus software de gestión empresarial
son líderes a nivel mundial.
17
ventajas, sino que adicionalmente habrá seguramente impacto muy malo para los negocios. Es
necesario construir software de calidad. Se necesita ingeniería de software.
7. Ingeniería de Software
Las casas no se construyen simplemente apilando ladrillos con cemento. Si un obrero quiere
levantar un edificio simplemente levantando paredes y pisos, está claro que, cuando llegue a cierta
altura, hay altas chances de que colapse por no aguantar su propio peso.
No se construyen casas de ese modo. Primero hay que hacer cálculos adecuados, dibujar
planos, armar cimientos, construir una estructura acorde de vigas y columnas, utilizar los materiales
que tengan la resistencia adecuada, entre otras decenas de consideraciones. Incluso hay procesos
establecidos que ordenan las tareas: Los vidrios, por ejemplo, es lo último que se coloca porque, de
otro modo, pueden romperse durante la obra. Los caños se pasan por las paredes antes de
revocarlas y pintarlas. Los edificios no se construyen apilando ladrillos sino siguiendo procesos de
ingeniería.
Lo mismo debería pasar con el software. No se puede construir tirando líneas de código en
una computadora. Para que el software no colapse en su primer uso, debe utilizarse lo que
genéricamente se denomina Ingeniería de Software. ¿Qué es entonces la ingeniería de Software?
Estas son algunas de las definiciones más conocidas:
“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”. [Bauer, 1972]
“Es el estudio de los principios y metodologías para desarrollo y mantenimiento de

sistemas de software”. [Zelkovitz, 1978]
“Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo

operación (funcionamiento) y mantenimiento del software: es decir, la aplicación de
ingeniería al software”. [IEEE, 1993]
“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”. [Sommerville, 2004]
“Es una disciplina que integra el proceso, los métodos, y las herramientas para el
desarrollo de software de computadora”. [Pressman, 2005]
Vale también en este considerar algunos aspectos claves, destacados por Ian Sommerville
en su libro “Ingeniería de Software”:
• 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.
18
• El proceso de software incluye todas las actividades que intervienen en el
desarrollo de software, 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 del software, ingeniería de
requerimientos y reutilización de software.
• Los ingenieros de software tienen responsabilidades con la profesión de

ingeniería y tambien 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.
8. El proceso de desarrollo del software
El proceso de desarrollo de software “es aquel en que las necesidades del usuario son
traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño
implementado en código, el código es probado, documentado y certificado para su uso operativo”.
[Jacobson 1998].
A modo general, y de un primer acercamiento (más adelante se perfeccionará este esquema)

, podemos decir que un desarrollo de software requiere cumplir, en forma encadenada, una serie
de etapas que cubren desde el primer contacto con el cliente hasta que el software queda
funcionando. Eventualmente, pueden existir nuevas versiones del software, lo que implica que este
proceso se repita. La siguiente figura muestra las etapas y cómo se van en cadenado entre sí:
19
1. Definición Inicial:
En esta etapa se define globalmente el proyecto y los resultados esperados. Se
hacen los acuerdos básicos, incluso un primer presupuesto inicial, que permiten
comenzar con el proyecto.
2. Análisis de los requerimientos y su viabilidad:

Iniciado el proyecto, se procede a recopilar, examinar y obtener todos
requerimientos del cliente. También será importante detectar restricciones. En esta
etapa debo establecer si es proyecto es viable de desarrollar.
3. Diseño general y detallado:

En base a los requerimientos obtenidos se diseña la aplicación informática que dará
respuesta a las necesidades del cliente. Será necesario plantear, primero, los
requisitos generales de la arquitectura de la aplicación y, luego, el detalle de cada
componente de la aplicación, todo esto con la precisión suficiente para que luego
pueda ser construido. Es el equivalente al plano que guía las construcciones de
edificios.
4. Codificación:
En esta etapa los componentes diseñados a nivel teórico se programan utilizando
lenguaje de programación.
5. Pruebas:
Una vez programado, será necesario verificar que el software no contenga errores,
y que cumple con los requerimientos originalmente solicitados por el usuario.
6. Implementación:
Finalmente, el software se instala en las computadoras del usuario y el sistema
comienza a funcionar. Debe además asegurarse que quienes usarán el software
reciban la capacitación necesaria para utilizarlo correctamente.
20
7. Evolución:
Una vez que el software comienza a prestar servicio, seguramente requerirá
cambios, ya sea para corregir eventualmente algún error no detectado, o para
incorporar nuevas funcionalidades.
Pero… ¿Bastan estas etapas para asegurar un producto de calidad? ¿Bastan para mejorar los
procesos futuros de desarrollo? La respuesta es que no. El responsable del proyecto de software
tendrá que realizar una serie de actividades que protejan la calidad del software. Estas tareas se
deben realizar en forma concomitante con las mencionadas anteriormente.
Roger Pressman identifica una serie 8 actividades que denomina “Sombrilla” o “Protectoras
de la calidad”. A diferencia de las etapas del proceso, estas actividades no se realizan de modo
secuencial, sino que están presentes a lo largo de todo el desarrollo. Se inician al comenzar el
proceso y funcionan como una sobrilla que protege a las etapas del proceso asegurando su calidad.
Las actividades sombrilla planteadas por Pressman son las siguientes:
• Seguimiento y control del proyecto de software: permite que el equipo de software

evalúe el progreso, comparándolo con el plan del proyecto, y que pueda tomar
cualquier acción necesaria corregir desvíos que se detecten.
• Gestión del riesgo: es necesaria una permanente evaluación de los riesgos que
puedan afectar el resultado del proyecto o la calidad del producto; así como también
establecer las acciones que deben 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 cumplir a los fines de que el producto final sea un
producto de aceptable calidad.
21
• 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 alguna corrección,
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 (incluso los componentes del software) y establece mecanismos para obtener,
desde el inicio, componentes reutilizables en futuros proyectos.
• Preparación y producción del producto del trabajo: agrupa las actividades requeridas
para crear productos del trabajo, tales como modelos, documentos, registros, formatos
y listas.
En la siguiente imagen, puede verse de modo completo el proceso de desarrollo de software,

con las etapas de desarrollo propiamente dichas, enmarcadas en un esquema de calidad, y con
diversas actividades protectoras que se realizan en forma concomitante para asegurar un software
de calidad.
22
9. Conclusiones
Entre 1985 y 1987 se produjeron una serie de accidentes con pacientes oncológicos que
recibían tratamiento con la máquina de radioterapia Therac-25. La máquina costaba un millón de
dólares. Los accidentes ocurrían cuando el haz de electrones de alta potencia era activado en lugar
del haz de baja potencia, sin la placa difusora colocada en su sitio. El software de la máquina
detectaba el error, pero no evitaba que el paciente recibiera la dosis de radiación, algo
potencialmente letal. La radiación beta que el usuario recibía era aproximadamente cien veces
mayor que la dosis esperada de radiación. Varios pacientes recibieron quemaduras y 6 de ellos
murieron.
A partir de varios casos como el mencionado, se comenzó a pensar en el software como un

producto vital para las organizaciones y las personas. Se comenzaron a buscar diferentes soluciones,
para producir software de calidad y sin errores. Por supuesto, y tal como pasa en otras disciplinas,
no fue posible encontrar una única receta. El campo de la ingeniería del software es demasiado
complejo y diverso para que una única solución resuelva todos los problemas. Pero el conjunto de
todas las prácticas que surgieron, y de las que siguen incorporándose hoy en día, son las permiten
que, gracias a la ingeniería del software, se desarrollen aplicaciones de calidad aceptable, que
protejan a organizaciones y a las personas, su salud, su seguridad, sus derechos o bienes.
10. Bibliografía
IAN SOMMERVILLE: Ingeniería de Software. 9na Edición. 2011. Pearson Education.

ROGER PRESSMAN: Ingeniería del Software. 7ta Edición. 2008. Ed. McGraw-Hill.
MICHAEL PORTER: Ventaja Competitiva. 2da Edición. Grupo Editorial Patria. 1987
SHARI LAWRENCE PFLEEGER: Software Engineering: Theory and Practice. 4th Edition. 2009
Pearson.
Universitat Politécnica de Valencia: Blog de Historia de la Informática, Museo de Informática,
https://histinf.blogs.upv.es/2010/12/28/ingenieria-del-software/
23
2
Apunte 2
Conceptos Fundamentales del Desarrollo de

Software Dirigido por un Plan
24
1. Introducción
Muchas profesiones tienen protocolos o guías para encarar su arte, su ciencia o su técnica.
Un pintor sabe que, antes de empezar su cuadro, debe preparar la tela conforme la técnica de
pintura que utilizará. Un médico, que visita a un paciente a domicilio, sabe que primero debe
tomarle la fiebre, auscultarlo, revisar su garganta y luego decidir un diagnóstico. Con este primer
diagnóstico podrá optar por realizar más estudios de laboratorio, prescribir algún medicamento o
incluso decidir la internación.
Algo similar pasa con la construcción del software: no es simplemente sentarse y empezar a
programar. Por el contrario, un proyecto de construcción de un sistema informático requiere
desarrollar una serie de tareas interrelacionadas. Deben ejecutarse con cierto orden y cumpliendo
ciertas pautas para asegurar un proyecto exitoso y un software de calidad.
Para servir de guia a quien a quien construye software, se han planteado una serie de
modelos de desarrollo, que conforman un marco teórico a seguir. Estos modelos han sido utilizados
y probados durante infinidad de desarrollos y, si bien su uso no es obligatorio, es recomendable
seguirlos para lograr un proyecto exitoso. Existen muchos modelos para elegir (incluso muchos más
de los abarcados en este libro). Seguramente alguno de ellos será el que mejor se adapte al tipo de
sistema que se construirá, al tipo de organización donde se implementará e, incluso, al contexto.
2. Desarrollo Dirigido por Plan versus Metodologías Agiles
Somerville hace referencia en su libro “Ingeniería de Software” a la posibilidad de encarar

proyectos de software basados en un plan previo (plan-driven). En realidad, el autor se refiere con
este concepto al paradigma tradicional de desarrollo de sistemas. La idea central de este paradigma
es que 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 queda funcionando.
Una de las principales premisas de este desarrollo tradicional o dirigido por un plan es que,
una vez establecido ese plan, ya no permite cambios. Contar con plan es una gran ventaja: permite
presupuestar costos y tiempos. El desarrollo se vuelve predecible, con etapas secuenciales previstas
de antemano. Los requerimientos planteados y acordados al inicio serán los que aparecerán en la
versión final.
Claro que en estas ventajas también están las principales críticas: los proyectos de software
rara vez son tan lineales, hay poca interacción con el cliente, los errores u omisiones de una etapa
se arrastran con facilidad a etapas posteriores, los requerimientos deben obtenerse al comienzo sin
posibilidad de cambio, es difícil aplicarlo en proyectos grandes o complejos.
Si bien estos condicionantes son importantes, tampoco es cierto que todas las
organizaciones se muevan en escenarios cambiantes. Por el contrario, algunas utilizas procesos que
llevan años funcionando del mismo modo y con eficacia. Para este tipo de entidades, los modelos
de desarrollo dirigidos por un plan resultan sin duda la mejor alternativa.
25
En el otro extremo, en la actualidad, muchas organizaciones se comportan de un modo
diferente. Sus procesos, y por ende sus sistemas, están permanente cambio y adaptación a un
contexto cambiante. Los sistemas están en permanente cambio y evolución. Para estos casos, los
modelos basados en un plan no son eficaces y allí es donde las actuales metodologías ágiles
representan de un modo más natural el desarrollo de software. 5
Si bien en cierto que en la actualidad muchas organizaciones prefieren utilizar metodologías

ágiles de desarrollo, también siguen existiendo múltiples escenarios donde los enfoques
tradicionales siguen siendo más efectivos. Incluso Somerville destaca que “la mayoría de los
proyectos de software incluyen y combinan prácticas del enfoque ágil y del basado en un plan”.
No es el objetivo central de este trabajo comparar una y otra metodología de construcción,

pero si es interesante analizar una serie una serie de preguntas que se hace Somerville a la hora de
optar por una u otra:
1. ¿Es importante y sobre todo posible tener una especificación y un diseño muy
detallados antes de dirigirse a la implementación? Siendo así, probablemente usted
tenga que usar un enfoque basado en un plan.
2. ¿Es práctica una estrategia de entrega incremental? ¿Le sirve al cliente utilizar un
software con funcionalidades acotadas? ¿La retroalimentación del cliente es
importante? De ser el caso, considere el uso de métodos ágiles.
3. ¿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.
4. ¿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 antes de comenzar el desarrollo. En tales circunstancias, quizá sea
mejor un enfoque basado en un plan.
5. ¿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.
6. ¿Existen problemas culturales que afecten el desarrollo del sistema? Las organizaciones
de 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.
5
El apunte “Conceptos Fundamentales del Desarrollo Ágil de Software”, amplia este tema.
26
7. ¿El sistema está sujeto a regulación externa? Si un regulador externo tiene que aprobar
el sistema (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 le
requerirá documentación detallada como parte del sistema de seguridad.
Está claro que, finalmente, para el usuario lo importante es que el software cumpla con sus
requerimientos, independientemente de con que estrategia fue desarrollado. En la práctica,
muchas compañías que afirman haber usado métodos ágiles, adoptaron algunas habilidades ágiles
y las integraron con sus procesos dirigidos por un plan.
3. Desarrollo de sistemas Dirigidos por un Plan. El enfoque clásico
La teoría de construcción de sistemas planteó, desde sus comienzos, que, para lograr el éxito
del proyecto de software, deben desarrollarse una serie de actividades sucesivas. Este primer marco
teórico planteado es conocido como modelo lineal, modelo clásico, o secuencial. Como su nombre
lo sugiere, las etapas se encadenan. Una vez concluida una etapa, se pasa a la siguiente:
Este modelo presenta algunas variantes en cuanto su concepción. Algunos autores incluyen
otras etapas, como la de relevamiento o la de mantenimiento (más adelante en el libro se
desarrollará este tema) o las nombran de modo diferente (por ejemplo “implementación” o
“implantación” en lugar de “puesta en marcha”). Sin embargo, la esencia es similar en todos: Un
modelo de etapas secuenciales las cuales deben ser desarrolladas una tras otra hasta arribar al
producto final ya instalado. Solo cuando se finaliza una etapa puede pasarse a la etapa siguiente.
Queda fuera de alcance de este trabajo el análisis exhaustivo de cada una de estas etapas.
Sin embargo, es necesaria una breve descripción de cada una de ellas.
27
Etapa Descripción
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
Análisis
determinadas reglas y convenciones) refleje todos los requerimientos de los
usuarios. También deben detectarse y contemplar las restricciones a tener en
cuenta.
En esta etapa se diseña una solución informática a los problemas encontrados,
contemplando los requerimientos obtenidos en la fase anterior y respetando las
Diseño
restricciones. Generan la documentación, con el suficiente detalle técnico
necesario, para que los programadores puedan construir el código.
Basado en las especificaciones del diseño, los programadores construyen el
Codificación
código del software, utilizando algún lenguaje de programación.
Consiste en buscar posibles errores en un sistema antes de que este comience
Prueba
a utilizarse. Los errores encontrados se reportan para su corrección.
Puesta en En esta etapa se instala el programa en las computadoras del cliente y se
marcha capacita a los usuarios para que puedan utilizar el nuevo software.
4. Una propuesta integral
Antes de avanzar con el análisis de los diferentes modelos que pueden ser utilizados para
construir software, es necesario aclarar que este modelo clásico tampoco abarca todas las etapas
existentes en un proyecto de construcción de una aplicación informática. Por ejemplo, no es cierto
que un desarrollo de software empiece directamente con la etapa de análisis. Tampoco es cierto
que solo estas cinco etapas basten para construir software de calidad. El modelo tradicional podría
mejorarse, agregando algunas etapas y reformulando otras. Si a estas etapas las complementamos
con aquellas protectoras de la calidad vistas en el apunte anterior, la siguiente figura ilustra lo que
podría ser una propuesta integral y mejorada del modelo genérico para el desarrollo de software
guiado por un plan:
28
Etapa Descripción
Es el primer contacto entre desarrollador y cliente. Se acuerdan los
Comunicación
lineamientos básicos del proyecto, se presentan en forma global los
inicial
problemas, los principales requerimientos y las restricciones existentes.
No todos los problemas pueden resolverse mediante un sistema informático o
con un desarrollo tradicional del software. Pueden aparecer también enfoques
Estudio de o propuestas alternativas. Además, las condiciones particulares del entorno,
Factibilidad del cliente, del desarrollador; y hasta el presupuesto y los tiempos disponibles,
pueden también condicionar la realización de un sistema. Es necesario
entonces estudiar la factibilidad o no de seguir adelante con el proyecto.
Es necesario planificar el proyecto de desarrollo en su totalidad. Habrá que
estimar recursos: Humanos, incluyendo la contratación y/o asignación
temporal de personal); de software (licencias, entornos de desarrollo, librerías
de software, componentes reutilizables, etc.) y de entorno (hardware,
comunicaciones, espacio de trabajo, etc.). También, y en función del tipo de
software a desarrollar, deberá definirse cuál será el modelo de desarrollo de
Plan y software que se utilizará, los tiempos que se estima llevará cada una de las
Presupuesto etapas y la forma en la que se desarrollarán cada una de las actividades del
proyecto.
Por último, en esta etapa también será necesario elaborar un primer
presupuesto económico para presentarle al cliente. Por lo general no será
posible presupuestar de antemano la totalidad del sistema, en cuyo caso podrá
hacerse un presupuesto parcial que alcance solo las próximas etapas6.
Construcción Los modelos de desarrollo de software abarcan las etapas de análisis, diseño,
de la aplicación
codificación, prueba y puesta en marcha. Cada una de estas actividades tendrá
utilizando unparticularidades y agregados según las características de cada modelo y de los
modelo sistemas a desarrollar.
Aunque no siempre esta etapa se da de manera explícita, y a veces queda en
un mero anuncio de la propuesta comercial, queda claro que el compromiso
de quien desarrolla un software es que este funcione tal como fue
Garantía especificado. Es necesario entonces contemplar una etapa en donde se
solucionen los errores que pueda tener el software. El costo de corregir los
eventuales problemas que se presenten en esta etapa debe ser también
contemplado dentro de los costos generales del proyecto.7
Ni los sistemas ni las organizaciones en las que estos funcionan son estáticos.
Una vez instalado un sistema es posible que sean necesarios cambios o
mejoras. Puede incorporarse nuevos pedidos de los clientes; agregar nuevas
Mantenimiento
funcionalidades; mejorar las existentes; corregir errores; adaptarlo a nuevas
tecnologías o a cambios del entorno.
Por supuesto, también existen casos donde esta etapa no se lleva a cabo.
6
En el apunte de “Estimación y Costeo” se analizan las particularidades de la presupuestación y la dificultad de hacerlo
con exactitud en el momento inicial.
7
En el apunte referido al Mantenimiento de Software” se describen y explican las diferencias conceptuales de la etapa
de garantía propuesta, con la de Mantenimiento, etapa con la que suele confundirse.
29
Una segunda propuesta tiene que ver con ajustar el nombre de 2 de las etapas clásicas. No
solo estos nombres, sino que además representan una mejor idea de los propósitos de la etapa:
El término ingeniería de requerimientos presenta una idea más completa de la etapa. Los
requerimientos deben ser completos. Algunos surgen de las entrevistas y el relevamiento a usuarios,
pero otros no. Quien realice el requerimiento debe construirlos obteniendo información de distintas
fuentes. Por ejemplo, se debe conocer cuál es color institucional o los logos de la compañía. Esto
hay que preguntarlo específicamente.
De igual modo, la puesta en marcha parece referir a que el sistema se pone en

funcionamiento y con esto se termina la tarea. En realidad, son muchas más cosas las que se deben
realizar en esta etapa, por ejemplo la capacitación a usuarios. El termino despliegue resulta entonces
más amplio y abarcador.
Más adelante en el libro se verán con mayor detalle y profundidad las etapas de ingeniería
de relevamiento y despliegue.
5. Distintos problemas y sistemas, distintos modelos
Contar con un plan que guíe el desarrollo de un software es sin dudas ventajoso. Pueden
estimarse los plazos, los presupuestos y que, finalmente, el sistema haga aquello para lo cual fue
diseñado. De hecho, así suelen construir las cosas, por ejemplo, los edificios. Pero claro, los sistemas
son diferentes entre sí. Y aunque sean parecidos, las organizaciones para los cuales estos sistemas
se desarrollan tienen diferente cultura y diferentes formas de implementarlos o utilizarlos. Resulta
difícil pensar que un único modo de construcción, como el modelo clásico o secuencial, pueda servir
para todos los tipos de software.
Lo primero que debe mencionarse es que existen varios factores que pueden afectar
complicar la construcción de un sistema y, con esto, desviarlo de sus estimaciones iniciales. Entre
estos factores podemos mencionar:
30
• El tamaño del software a desarrollar:
Aun cuando la funcionalidad o la complejidad técnica de un software sean parecidas, no

es lo mismo construir un software chico que uno grande. Tampoco es lo mismo hacerlo
para una pequeña empresa que para una de mayor tamaño.
Un software más grande presupone más líneas de código, más usuarios, más
requerimientos para relevar, una mayor cantidad de recursos asignados, un mayor
despliegue en la implementación, una mayor capacitación, más horas de prueba, más
documentación, etc.
Por otro lado, los sistemas más pequeños, en general, tienen asignado un menor
presupuesto. En estos casos el desarrollo tendrá que ser lo más sencillo posible.
En resumen: Es más difícil desarrollar un software de gran tamaño que uno pequeño. Es
más difícil mantener controlado un proyecto grande que otro más chico.
• La complejidad para obtener requerimientos8:
Los sistemas buscan resolver problemas organizacionales. Y para esto es necesario

conocer cuáles son estos problemas y cuáles son los requerimientos que tienen los
diferentes usuarios e involucrados. Tambien debe tenerse en cuenta eventuales
restricciones para resolverlos. Sin embargo, estos requerimientos no siempre son fáciles
de obtener.
Muchas veces 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
tener dificultades en comprender los términos propios de la organización. Los procesos
más complejos agregan dificultades adicionales.
Tampoco puede asegurarse que lo que el analista entendió es exactamente lo que el

usuario le quiso explicar. No es fácil, por ejemplo, describir verbalmente el
comportamiento deseado una pantalla con múltiples botones.
También pueden ocultarse cosas, a veces por una simple omisión, otras veces
deliberadamente. No debe olvidarse que el usuario puede asumir diversas actitudes
frente a la instalación de un nuevo software. A veces puede incluso no querer
implementarlo, por temor a ser desplazado, o para conservar cierto poder dentro de la
organización.
Incluso debe considerarse que los usuarios no siempre tienen el tiempo suficiente para
dedicarle a los analistas; además de reunirse con los analistas, tienen que realizar sus
8
Este tema es abordado con mayor profundidad en apunte “Claves de un Relevamiento Exitoso”
31
tareas habituales. Incluso, existe la posibilidad de que estos requerimientos no puedan
ser explicitados al inicio o que cambien conforme va avanzando el proyecto.
Es importante entonces asegurar que los requerimientos sean bien comprendidos y que
coincidan con las necesidades reales de la organización.
• La complejidad técnica:
Realizar un software también implica desafíos técnicos, a veces mayores a los habituales
Muchas veces debe desarrollarse software para un nuevo sistema operativo; o con
nuevos lenguajes de programación; o vinculados con dispositivos de hardware especial
(equipos portables, celulares, máquinas industriales, etc.)
Incluso hay casos en los cuales el cliente fija determinados requerimientos tecnológicos
que pueden resultar desafíos adicionales para el desarrollador, que quizá no tiene la
suficiente experiencia en esa tecnología.
Las cuestiones técnicas representan entonces un factor de complejidad adicional que

debe ser tenido en cuenta.
• El tiempo disponible:
Se supone que una de las cosas que se estiman y presupuestan al realizar un software es
cuánto tiempo se tardará en el desarrollo.
Sin embargo, muchas veces las organizaciones requieren tener disponible el software
para una fecha específica (por ejemplo, para el lanzamiento de un nuevo producto, el
cambio de período fiscal, la necesidad adelantarse a la competencia, la apertura de un
nuevo local, etc.) En estos casos los plazos de desarrollos son parte del requerimiento e
imponen importantes restricciones al proyecto.
• El riesgo:
Todo nuevo proyecto es un desafío e implica riesgos. De hecho, las situaciones descriptas
anteriormente implican diferentes grados de riesgos, que pueden alterar los planes y los
resultados previstos.
Pero existen también otras 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.
La lista de posibles riesgos es larga, pero como ejemplo puede mencionarse: pérdida de
apoyo político, cambios de personal, cambios en el presupuesto, cambios en la
legislación, cambios en el mercado, lanzamiento de nuevo hardware, aparición de nuevo
software o de un nuevo sistema operativo, cambios en sistemas de la competencia,
ventas o fusiones de la empresa…
32
En resumen: Existen entonces diversos problemas para tener en cuenta a la hora de
desarrollar software. No existe un modelo de desarrollo que pueda resolver eficazmente todos los
temas planteados. Se analizarán, entonces, no uno sino varios modelos de desarrollo que podrán
utilizarse conforme el escenario y los problemas que deban enfrentarse.
Resulta apropiado aclarar que, así como se destacaron las posibles limitaciones de tiempo,
seguramente al leer esta lista pueda pensarse también en el costo como un factor limitante. O mejor
dicho en el presupuesto que el cliente tiene disponible. Por supuesto que es necesario desarrollar
software que el cliente pueda pagar, pero esto no debe tomarse como un condicionante a la hora
de elegir un modelo u otro. En efecto y como se verá a continuación, hay modelos que insumen más
recursos que otros y por ende son más costosos. Pero hay que tener en cuenta que hay otros
factores para determinar el costo total de un sistema. Quizá un modelo a priori más caro termine
generando ahorros. Por ejemplo, un modelo que permita comprender mejor los requerimientos
evita las reprogramaciones. Aun con presupuestos limitados debe elegirse el modelo más adecuado
y no necesariamente el más barato9.
6. Modelo “Lineal Secuencial” (“En Cascada” o “Ciclo de Vida”)
Ya se han comentado alguna de las desventajas y críticas que recibe el modelo lineal secuencial.
Sin embargo, para sistemas sencillos y pequeños la elección de un modelo simple no deja de ser una
muy buena idea. Este sistema contempla 5 etapas, de características muy similares a las del modelo
clásico.
9
Este tema es abordado con mayor profundidad en apunte de “Conceptos Fundamentales de la Estimación, Costeo y
Precio del Software”
33
Descripción
Etapa
Esta etapa coincide con la etapa de análisis, aunque no solo debe relevarse
usuarios y analizar la información proporcionada. El término ingeniería de
requerimientos hace referencia a una actitud activa en la búsqueda de todos los
Ingeniería de
problemas y en tratar de obtener los requerimientos de la manera más completa
requerimientos
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.
Es la primera de las actividades técnicas. En esta etapa se diseña una solución a
los problemas encontrados, contemplando los requerimientos de los usuarios.
Diseño Produce un modelo de lo que se construirá más adelante. Proporciona detalles
acerca de las estructuras de datos, las arquitecturas, las interfaces y los
componentes del software que son necesarios para programar el sistema.
Basado en las especificaciones del diseño los programadores generan el código
Codificación
utilizando un lenguaje de programación. Construyen el software propiamente
dicho.
Frecuentemente se señala a esta etapa como aquella en la cual se prueba que el
software no contenga errores. Sin embargo, no debe probarse que el software
Prueba
funcione, sino que se debe buscar que este falle. Se debe entonces atacar y
someter al programa a diversas condiciones extremas, buscando que aparezcan
errores no detectados en la etapa de la codificación.
En esta etapa, denominada también como, “implementación”, “puesta en
marcha”,” o “implantación” por algunos autores, 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 del hardware y software de los
Despliegue
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.
Una parte importante de esta etapa es la capacitación de todos los usuarios
involucrados y la adecuación de los circuitos administrativos a la nueva
operatoria basada en un sistema informático.
Ventajas Desventajas
• Es un modelo simple, sencillo y probado. Por • Los proyectos rara vez siguen el flujo secuencial.
supuesto, es mucho mejor utilizar este • Los errores de las primeras etapas se arrastran
modelo que no utilizar ninguno. con facilidad a las etapas posteriores. Muchos
• Para proyectos sencillos, es el modelo errores solo se descubren al final cuando se
menos costoso y el más rápido. entrega el sistema.
• Pueden producirse estados de bloqueos por la
secuencialidad de las etapas.
• Es difícil que el cliente especifique todos los
requerimientos al inicio
• No prevé la posibilidad de introducir cambios en
el medio del proyecto.
• El cliente no ve el proyecto hasta que el software
está terminado.
34
7. Modelo “Lineal Secuencial Iterativo o Incremental”
Puede ocurrir que, por razones de tamaño, tiempo u operativas; sea conveniente construir
y entregar el sistema en partes. De este modo puede construirse una primera versión con algunas
funcionalidades. Una vez implementada esta versión, se vuelve a emplear el modelo lineal
secuencial para producir una nueva versión más completa.
Las etapas de este modelo obviamente no difieren del modelo Lineal Secuencial ya que, en
definitiva, son sucesivas iteraciones de aquel modelo.
Es importante diferenciar este modelo de la división modular de un sistema. En cada

iteración se entrega un sistema completo y operable, no módulos sueltos. El cliente puede usar el
sistema en entornos productivos, aun cuando a este no tenga completas todas sus funcionalidades.
Tampoco debe confundirse con Desarrollo Ágil. En este modelo los componentes de la
primera versión están todos planeados y definidos al comienzo. Las sucesivas versiones también
siguen igual premisa, se planifica al comienzo cuáles van a ser el contenido completo de la nueva
versión. En desarrollo ágil, las pequeñas mejoras se van incorporando en forma periódica
(habitualmente cada 2 o 3 semanas). No existe una planificación inicial sino, conforme van surgiendo
requerimientos, estos se priorizan y se van desarrollando.
Como ejemplo puede mencionarse un sistema para un comercio minorista. Una primera
versión podría contener solamente funciones para emitir las facturas y controlar la caja. Una
segunda vuelta podría permitir registrar clientes y manejar la cuenta corriente de los mismos. Un
tercer incremento habilitaría la posibilidad de registrar las compras y los proveedores y finalmente
una última versión podría permitir un control de stock automatizado.
35
• Las entregas parciales reducen la • Sigue siendo un esquema secuencial,
complejidad del proyecto y mejoran las aunque esto sea menos grave que en el
estimaciones. modelo anterior.
• El usuario recibe rápidamente una primera • Los errores de las primeras etapas se siguen
versión con sus primeras necesidades ya arrastran con facilidad a las siguientes.
cubiertas. • Pueden producirse estados de bloqueos por
• Requiere menos personal concurrente y la secuencialidad de las etapas, aunque
los recursos se asignan mejor en el tiempo. menores porque se supone que las etapas
• Las implementaciones parciales son más son más acotadas.
sencillas que una implementación total.
8. Modelo de “Prototipos”
Ya se mencionó la dificultad existente para obtener requerimientos y para asegurar que los
analistas entendieron lo mismo que los usuarios quisieron explicar. También la existencia de
procesos técnicos complejos sobre los que se tienen dudas si se pueden realizar.
Es habitual que, al construir una casa, los arquitectos construyan maquetas y diseños
simulados para que el cliente pueda tener una mejor idea de cómo será su hogar. De igual modo,
los ingenieros de software pueden construir un prototipo de lo que será el producto final. Este
prototipo es una versión acotada del software, construida solamente a los fines de poder interactuar
con el usuario y poder tener una mejor visión de 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 solo aquellas funciones más representativas.
El desarrollador también podrá usar el prototipo para probar algún algoritmo determinado
o alguna funcionalidad compleja del software. Por ejemplo, si se construye un software para
interactuar y controlar algún dispositivo móvil, podría desarrollarse un prototipo para comprobar
que en efecto puede accederse al dispositivo y que se pueden realizar las operaciones necesarias
para controlarlo.
Lo habitual es que un prototipo sea un software simple, tambien puede usarse diseño de
pantallas o imágenes gráficas del producto como tal. No se busca que el cliente pueda utilizar
funcionalmente el prototipo, solo que pueda comprender y visualizar cómo funcionará la aplicación
final.
El prototipo, incluso, puede tener varias versiones, cambios y ajustes. Podría trabajarse
sobre el prototipo hasta que se finalmente acuerdan los requerimientos. También puede refinarse
cuantas veces sea necesario hasta que efectivamente se logran resolverlos temas técnicos. Recién
cuando se logra el acuerdo final sobre el prototipo se avanza en la construcción del software.
Es importante destacar que, 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.
36
Las etapas del modelo de prototipos son similares a las del modelo lineal secuencial aunque,
en este caso, no se busca la construcción de un producto final del software, sino solamente de una
versión de prueba.
Etapa Descripción
Relevamiento Esta etapa se realiza un relevamiento general y luego de relevan con más
Rápido detalle aquellas opciones que serán incluidas en el prototipo. Este
relevamiento no se hace de un modo tan exhaustivo ya que no tiene como
objetivo obtener todos los requerimientos, sino que, por el contrario, es
una herramienta para mejorar ayudar a obtenerlos
Diseño del Se diseña el prototipo, detallando el modo en el que se presentará y cuál
prototipo será el alcance de cada una de las opciones de este.
Generación del Se construye el prototipo. Puede utilizarse el mismo lenguaje de
prototipo 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.
Prueba Si el prototipo es un software operable, el mismo deberá ser probado para
buscar posibles errores.
Despliegue y No se entrega el prototipo al cliente, sino que el desarrollador lo ejecuta y
retroalimentación analiza con él. A partir de este análisis podría modificarse el prototipo,
construirse uno nuevo o, si ya quedó todo claro para ambos, comenzar con
el desarrollo de la aplicación final.
37
• Permite una mejor definición y comprensión • Si es un software, el cliente puede tentarse de
de los requerimientos iniciales. utilizar el prototipo. Se debe tener en claro
• Permite un testeo de aquellas funciones que el prototipo es construido a los solos
técnicamente complejas. efectos de mejorar el entendimiento entre
• Reduce la incertidumbre porque el cliente ve usuario y desarrollador. No es un producto
un modelo real de lo que será el futuro que pueda utilizarse bajo ningún punto de
sistema. vista como una primera versión operativa.
• El desarrollador puede tentarse de ajustar el
prototipo y entregarlo como producto final,
sin cumplir con ninguna pauta de calidad o
seguridad en el desarrollo.
• Algunas de las funcionalidades presentes en el
prototipo podrían no ser tenidas en cuenta en
la versión final, o quizá no sean posibles de
construir en el entorno real de desarrollo.
9. Modelo en “Espiral”
Ya se ha destacado que, en escenarios riesgosos, no todos los proyectos que se inician

terminan en un software que se implementa en forma exitosa. Boehm (1988) propuso un marco del
proceso de software dirigido por el riesgo. Utilizó para representarlo gráficamente espira donde,
cada ciclo, representa una fase de desarrollo10.
Se analiza en este apunte una versión resumida del Modelo en Espiral, presentada en libro
“Ingeniería de Software” de Roger Pressman, y que resulta una buena elección situaciones de riesgo
e incertidumbre. El gráfico del modelo es el siguiente:
10
Puede consultarse punto 2.3.3 del libro “Ingeniería de Software” de Ian Sommerville Ed. 9, para una profundización
del “Modelo en espiral de Boehm”
38
Las primeras de estas iteraciones de la 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. 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.
Etapa Descripción
Se relevan los requerimientos y necesidades generales de la organización.
Ingeniería de Luego se presta especial atención a las funcionalidades que serán entregadas
requerimientos en la primera etapa. Se buscan determinar cuáles son los posibles riesgos del
proyecto.
Es la primera de las actividades técnicas. En esta etapa se diseña una solución
a los problemas encontrados, contemplando las necesidades de los usuarios.
Diseño Produce un modelo de lo que se construirá más adelante. Proporciona detalles
acerca de las estructuras de datos, las arquitecturas, las interfaces y los
componentes del software que son necesarios para programar el sistema.
Es la etapa distintiva del modelo. En ella se analizan los riesgos que pueden
Análisis de afectar la continuidad del proyecto y se evalúa la conveniencia o no de
riesgo11 continuar. A diferencia de otros modelos, esta etapa actúa como vía de escape.
El desarrollo puede abortarse para no gastar recursos en proyectos inviables
Basado en las especificaciones del diseño, los programadores generan el código
Codificación
utilizando un lenguaje de programación. Construyen el software propiamente
dicho.
Frecuentemente se señala a esta etapa como aquella en la cual se prueba que
el software no contenga errores. Sin embargo, no debe probarse que el
Prueba
software funcione, sino que se debe buscar que este falle. Se debe entonces
atacar y someter al programa a diversas condiciones extremas, buscando que
aparezcan errores no detectados en la etapa de la codificación.
instalación de servidores y redes; la configuración del hardware y software de
Despliegue
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.
11
No debe confundirse esta etapa con la Gestión de Riesgos que se realiza para proteger la calidad del sistema. En este
caso son riesgos que, de producirse, no tiene sentido continuar con desarrollo del sistema. Por ejemplo, un resultado
adverso en las elecciones o la venta de la compañía.
39
• Las entregas sucesivas y el análisis de riesgo • No es simple medir los riesgos, mucho menos
lo vuelven un modelo apto para desarrollos cuando de ellos depende o no la continuidad
en entornos riesgosos y con mucha del proyecto. Si el análisis no es preciso,
incertidumbre. podrían abortarse proyectos finalmente viables
• Como otros modelos incrementales, puede o, por el contrario, continuar aun cuando el
utilizarse durante todo el ciclo de vida útil de riesgo finalmente se presente.
un sistema, produciendo sucesivas versiones • No siempre el cliente entiende que, a pesar de
mejoradas del producto inicial. sus etapas y mejoras sucesivas, es un modelo
controlado y que tiene con un final
previamente planificado.
• Puede resultar más caro que otros modelos ya
que realizar un análisis de riesgos implica
asumir costos, aunque también puede permitir
ahorros si se tomas las medidas correctivas
para mitigar el impacto del riesgo detectado.
10. Modelo de “Desarrollo Rápido de Aplicaciones”
Los actuales entornos avanzados de desarrollo de aplicaciones proveen a los desarrolladores

de poderosas herramientas que permiten generar código con gran rapidez y exactitud. El desarrollo
visual; la generación automatizada de código en múltiples lenguajes; los asistentes; los
componentes reusables o predefinidos; las herramientas colaborativas y las herramientas de prueba
automatizada, entre otras, permiten generar aplicaciones robustas en espacios cortos de tiempo.
La utilización de estas herramientas da entonces origen a un modelo de desarrollo rápido de

aplicaciones también conocido como RAD, por su sigla en inglés (Rapid Application Development).
El propio nombre del modelo hace referencia la posibilidad de generar aplicaciones con mayor
velocidad que los desarrollos tradicionales12.
Para agilizar los tiempos de desarrollo el software se divide en partes, para que puedan ser
desarrolladas por varios equipos que trabajan en forma concurrente. Esta división, más la
reutilización de componentes y las herramientas RAD permiten construir piezas de software
completo y de calidad en tiempos que van de 30 a 90 días. La permanente comunicación con el
cliente y entre los equipos de trabajo se vuelve imprescindible para el éxito final.
12
Nuevamente no debe confundirse con desarrollos ágiles. También en este caso la planificación ocurre en el momento
inicial. Incluso se puede pensar en un desarrollo rápido de una única versión de una aplicación, sin que esta tenga
incrementos, cambios, ni mejoras posteriores.
40
Etapa Descripción
Se relevan los requerimientos y necesidades de la organización. Se prevé la
Ingeniería de
división del sistema para que sea desarrollado por los distintos equipos
requerimientos
simultáneos.
Se diseña en función de las herramientas RAD y usando los asistentes de esta.
Diseño Se analizan los componentes que pueden ser reutilizados y aquellos que será
necesario programar.
Se utiliza la herramienta RAD para volcar en ella las características que tendrá
Codificación cada uno de los componentes del sistema. El código se genera mediante un
proceso semiautomático, pudiendo incluso utilizarse más de un lenguaje y/o
generar para más de un entorno operativo.
Además de la prueba tradicional, se utilizan las herramientas de prueba
Prueba automatizadas provistas en la propia herramienta RAD para reducir los
tiempos de la etapa.
instalación de servidores y redes; la configuración del hardware y software de
Despliegue
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.
• Los tiempos de desarrollo se acortan • El cliente debe también comprometerse con los
significativamente. plazos cortos de desarrollo y esto implica asignar
• También se reducen los tiempos de mayor personal al proyecto y con una mayor
prueba y los errores no detectados. carga horaria.
41
• Pueden construirse sistemas portables o • No todos los proyectos pueden dividirse, ni son
de fácil migración entre diferentes aptos de ser desarrollados con herramientas
entornos y sistemas operativos. RAD
• El código generado en forma automática suele
tener menor performance y consumir más
recursos.
• Se complica su implementación en proyectos
grandes porque requiere mucho personal en
forma concurrente.
11. Otros modelos
Si bien los modelos descriptos anteriormente son los más utilizados en desarrollos
vinculados a la administración y a las ciencias económicas, desde luego no agotan la totalidad de los
modelos existentes. El análisis y desarrollo de otros modelos escapa a los alcances del presente
trabajo, pero cabe de todos modos hacer una rápida mención de alguno de ellos, destacando
algunas de sus características principales:
• Desarrollo basado en componentes: Este modelo centra su desarrollo en la

reutilización de software y en el ensamble de componentes existentes. Si bien la
reutilización no es exclusiva de este modelo, puede utilizarse un marco de trabajo
especialmente orientado a trabajar reutilizando múltiples componentes preexistentes.
Muchas empresas de desarrollo utilizan este modelo para software comercial: Poseen
una aplicación parcialmente desarrollada, con las opciones genéricas ya programadas y
la posibilidad de ajustar, mediante parametrización, los requerimientos específicos del
cliente. Las ventajas de este tipo de desarrollo son13:
• Implementación rápida de un sistema fiable.

• Es posible analizar el software antes de implementarlo y ver si es adecuado para
las necesidades de la organización.
• Ahorro de costos.
• Tiempos de desarrollo más cortos y con menos riesgo.
• Se facilita la actualización, ya que el desarrollador suele actualizar las opciones
generales para todos sus clientes.
• Posibilidad de utilizar software como servicios. (Software en la nube)
• Métodos formales: Este modelo intenta hallar modelos matemáticos formales para
asegurar un desarrollo de software libre de errores. Aun cuando difícilmente puedan
encontrarse modelos matemáticos para todo tipo de software, puede ser interesante
considerarse esta formalización cuando se requiera software con alto grado de precisión,
por ejemplo, el desarrollado para el diagnóstico médico o para el manejo de vehículos
autónomos, aviones o grandes maquinarias. No es un modelo utilizado para el desarrollo
de software comercial.
13
Puede consultarse punto 16.6 del libro “Ingeniería de Software” de Ian Sommerville Ed. 9, Reutilización de productos
COTS, para una mayor profundización de este tema
42
12. Elección de un modelo adecuado
Ya se ha mencionado que no existe un mejor modelo para todo tipo de desarrollos y por
ende tampoco la posibilidad de hacer una recomendación certera sobre qué modelo conviene
utilizar. El proyecto y sus características; así como también el tipo de cliente, la experiencia y la
forma de trabajo del equipo de desarrollo; pueden inclinar la elección hacia un modelo u otro.
Tampoco estos modelos deben ser tomados como caminos obligatorios a seguir. Un
proyecto puede requerir que el desarrollo se realice tomando características de más de un modelo.
Por ejemplo, podría realizarse un prototipo y luego utilizar una herramienta RAD. O realizar un
análisis de riesgo en alguna de las iteraciones del modelo secuencial incremental. Incluso puede
utilizarse alguno de los modelos basados por un plan para construir la primera versión, y luego
continuar con metodologías agiles para la etapa de evolución.
Incluso es factible que el desarrollador experimentado o la empresa de desarrollo armen su

propio modelo, con las características que mejor se adapten a su forma de trabajar, al tipo de
sistemas que realicen o al tipo de clientes para los cuales desarrollen.
De cualquier manera, es posible dar algunas recomendaciones genéricas, comparando los

problemas habituales a los cuales se enfrentan los desarrollos, con las características propias de
cada modelo:
Problema para resolver Modelos recomendados

• Por su simplicidad, el modelo lineal secuencial presenta
ventajas para sistemas de pequeño tamaño.
• En el otro extremo, para proyectos de gran tamaño, la división
y la construcción por etapas suele ser una buena estrategia. En
El tamaño
este sentido, los modelos “evolutivos”, es decir aquellos que
permiten construir versiones sucesivas e incrementales del
software, parecen una buena elección para enfrentar este tipo
de proyectos.
• La elaboración de un prototipo ayuda en la comprensión de
requerimientos.
Complejidad de los
• Los modelos evolutivos, ya que evitan la necesidad de que
requerimientos
todos los requerimientos deban ser explicitados al comienzo
del relevamiento.
• Puede utilizarse un prototipo para probar aquellas funciones
técnicamente más complejas.
Complejidad técnica
• El modelo en espiral permite contemplar y monitorear riesgos
técnicos conforme se avance con el desarrollo.
• El modelo de desarrollo rápido de aplicaciones permite reducir
Tiempos disponibles
los tiempos de generación de aplicaciones.
• El modelo en espiral contempla situaciones de riesgo y la
Entornos riesgosos
evaluación de impacto sobre el sistema.
43
13. Limitaciones
Si bien a lo largo del apunte se han mencionados diferentes modelos que se adecúan a
diversas situaciones, existen escenarios, particularmente aquellos sujetos a cambios continuos, en
los cuáles estos modelos se vuelven ineficaces. Entre las limitaciones de estos modelos podemos
mencionar:
• Todos los requerimientos deben plantearse de antemano y no permiten incorporar

cambios, ni aquellos producidos por la organización ni aquellos surgidos por el contexto.
• 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, aun en aquellos modelos evolutivos, 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, aunque definitivamente es un punto favorable para aquellas que deben
cumplir con normativa externa, certificaciones, o que exijan tener documentados todos
sus procesos y sus aplicaciones informáticas.
14. Bibliografía
IAN SOMMERVILLE: “Ingeniería de Software”. 9ta Edición. 2011. Pearson Education.

ROGER PRESSMAN: “Ingeniería del Software”. 7ta Edición. 2010. Ed. McGraw-Hill.
44
3
Apunte 3
Conceptos Fundamentales del

Desarrollo Ágil de Software
45
1. Introducción
Buena parte de las organizaciones operan actualmente en entornos que cambian

constantemente. Sus procesos deben ser flexibles y adaptarse con rapidez a un contexto que ofrece
constantemente nuevos desafíos y oportunidades. Las mejoras y cambios en la producción de
bienes y/o servicios deben ser frecuentes, lo mismo que en la comercialización. Está claro que el
desarrollo de software debe acompañar estos procesos cambiantes. En estos contextos, por
ejemplo, es una utopía pensar en una planificación inicial que se mantenga estable durante los
meses, o incluso años, que puede abarcar un proceso de desarrollo. Se vuelve necesario pensar en
nuevos modelos para generar proyectos de software que sean exitosos en este tipo de escenarios.
Los modelos de desarrollo ágil surgen como respuesta a estos desafíos, permitiendo producir
rápidamente software útil, de calidad y en periodos cortos de tiempo. En estos modelos, el software
no se desarrolla como una sola unidad, sino como una serie de incrementos que agregan
sucesivamente nuevas funcionalidades a una aplicación que ya 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, análisis de requerimientos, diseño, codificación, revisión, implementación y
documentación. Desde luego estas tareas no se hacen con toda la formalidad que plantean los
modelos tradicionales.
Los requerimientos del cliente se van recopilando y puestos en espera, asignándoles

prioridades. Una iteración no necesariamente debe agregar demasiada funcionalidad para justificar
lo que en los desarrollos evolutivos tradicionales sería una nueva versión, sino aquellas que puedan
programarse e implementarse en los cortos tiempos que dure el sprint. La meta es tener un
producto siempre operativo y en permanente mejora.
Al final de cada iteración el equipo vuelve a evaluar los requerimientos pendientes y decide
cuáles funcionalidades se incluirán en el siguiente sprint. Este proceso iterativo se realiza hasta que
se decide no evolucionar más el producto.
2. Modelos Tradicionales versus Ágiles
Es común escuchar que los modelos tradicionales son lentos, pesados, burocráticos mientras
que los modelos ágiles son rápidos y livianos. Los primeros representan a un pasado ineficiente
mientras los segundos plantean los enfoques del futuro.
Esta afirmación es cierta, pero solo en parte. Es verdad que los modelos tradicionales son
ineficientes en escenarios cambiantes, pero también es justo decir que no todas las organizaciones
se mueven en tales escenarios. Tampoco es cierto que todas las compañías tienen procesos internos
que tiendan a la flexibilidad. Los sistemas críticos, por ejemplo, los que manejan maquinaria o
vehículos autónomos; aquellos que requieren alta seguridad, por ejemplo los bancarios; por
46
mencionar algún ejemplo, son desarrollos que suelen requerir un análisis exhaustivo del sistema y
la entrega del sistema completo.
Podríamos entonces afirmar que ambos modelos tienen diferente utilidad y aplicación conforme
el tipo de organización, el tipo de sistema y el escenario en los que se aplique. En todo caso los
problemas pueden aparecer si se trata de usar metodologías tradicionales en escenarios cambiantes
o intentar un desarrollo ágil en una empresa con procesos formales14.A modo de resumen
podríamos analizar el siguiente cuadro:
Modelos Tradicionales Modelos Ágiles

Útiles para organizaciones que operan en Útiles para organizaciones que operan en
entornos estables y con normas y procesos entornos cambiantes, con procesos flexibles
definidos. También para software con y donde se privilegia tener un software
funcionalidades críticas o alta seguridad. 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, El sistema está en siempre en desarrollo. Se
en modelos incrementales, en sucesivas incorporan permanentemente nuevas
versiones completas). funcionalidades al que ya está funcionando.
El usuario no forma parte del equipo de El usuario participa activamente durante
desarrollo. Solo toma contacto con el sistema todo el proceso de desarrollo y puede ser
cuando lo recibe para las pruebas finales. parte del equipo de desarrollo.
El usuario de adapta al sistema El sistema de adapta al contexto
3. El “Manifiesto Ágil”
El “Manifiesto Ágil” es un documento sobre técnicas y procesos para desarrollar software. En

este documento Kent Beck y 16 desarrolladores, expertos en programación y críticos de los modelos
tradicionales, exponen una serie de cuatro valores y doce principios de la filosofía de los métodos
ágiles. Sobre estos valores y principios luego se han desarrollado diferentes modelos de desarrollo
ágil de software. Dicho documento fue firmado en febrero de 2001 en la ciudad de Utah- EEUU15.
14
Puede ampliarse esta comparación en el apunte “Conceptos Fundamentales del Desarrollo de Software Dirigido por
un Plan”. También el capítulo 3 del libro “Ingeniería de Software” 9na Ed. de Ian Sommerville tratan estos puntos con
mayor profundidad.
15
https://agilemanifesto.org/iso/es/manifesto.html
47
Valores del manifiesto Ágil
Los autores del manifiesto destacan que “Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo
hemos aprendido a valorar:”
• Individuos e interacciones sobre procesos y herramientas

Se valora el recurso humano como el principal factor de éxito. Contar con un equipo de
trabajo capacitado da mayor garantía de éxito por sobre priorizar herramientas y procesos
rigurosos. Se buscan recursos humanos que provean:
▪ Alta capacidad técnica.
▪ Compromiso con los objetivos comunes.
▪ Habilidades para el trabajo en equipo.
▪ Capacidad para tomar decisiones.
▪ Capacidad de resolver problemas.
▪ Confianza y respeto mutuo.
▪ Autogestión y organización personal.
• Software funcionando sobre documentación extensiva

Se respeta la importancia de la documentación como parte del proceso. Sin embargo, las
metodologías ágiles hacen énfasis en que se deben producir los documentos estrictamente
necesarios. Los mismos deben ser cortos y limitarse a lo fundamental.
• Colaboración con el cliente sobre negociación contractual

El cliente es parte del equipo de trabajo. Es un ingrediente más en el camino al éxito en un
proyecto de desarrollo de software. La participación del cliente debe ser constante, desde el
comienzo hasta la culminación del proyecto, y su interacción con el equipo de desarrollo, de
excelente calidad.
• Respuesta ante el cambio sobre seguir un plan

En entornos cambiantes y por la dinámica de la tecnología, un proyecto de desarrollo de
software se enfrenta a frecuentes modificaciones durante su ejecución. La planificación no
debe ser estricta, puesto que hay muchas variables en juego, sino que debe ser flexible para
poder adaptarse a las nuevas necesidades que puedan surgir.
Principios que rigen el desarrollo ágil
1. Nuestra 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 periodos de un par de semanas hasta un
par de meses, con preferencia en los períodos breves.
48
4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana en
el proyecto.
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.
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un

equipo de desarrollo es mediante 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. Los patrocinadores, desarrolladores

y usuarios deben mantener un ritmo constante de forma indefinida.
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 que se hace.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su
conducta en consecuencia.
4. Programación Extrema
La programación extrema (Extreme Programming, XP) es un método ágil muy difundido que
integra un rango de buenas prácticas de programación, como las liberaciones frecuentes del
software, el mejoramiento continuo del software y la participación extrema del cliente en el equipo
de desarrollo. 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. El nombre de XP fue
acuñado por Kent Beck en el 2000
Valores de XP
Los valores en los cuales se afianza la programación extrema son:
• Simplicidad: La simplicidad es la base de XP. Se simplifica el diseño para agilizar el desarrollo

y facilitar el entendimiento. Un diseño complejo del código, junto a sucesivas modificaciones
por parte de diferentes desarrolladores, hace que la complejidad aumente. En ciertas
ocasiones, incluso, se puede tornar necesaria la refactorización del código para hacerlo más
simple.
• Comunicación: La comunicación es fundamental, dentro del equipo de trabajo y con el

cliente. Crea un ambiente de cooperación y unidad, que ayuda a poder aplicar los demás
49
valores. Al estar el cliente integrado, su opinión sobre el estado del proyecto se conoce en
tiempo real.
• Retroalimentación: Realimentación concreta y frecuente del cliente, del equipo y de los

usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.
• Coraje: Muchas de las prácticas implican valentía. Una de ellas es programar para hoy y no
para mañana. La valentía permite a los programadores sentirse cómodos con reconstruir su
código cuando sea necesario. Otro ejemplo es saber cuándo desechar código obsoleto, sin
importar cuanto costo y esfuerzo llevó hacerlo. Valentía significa persistencia, un
programador puede encontrarse estancado en un problema complejo por mucho tiempo y
luego lo resolverá rápidamente solo si es persistente.
• Respeto: Si no hay respeto y aprecio entre el equipo, XP no se puede aplicar efectivamente.
Prácticas de XP
La programación extrema incluye una serie de prácticas las cuales reflejan los principios de
los métodos ágiles:
• Planeación del incremento: Los requerimientos se registran en tarjetas de historia (story

cards). Las historias que se van a incluir en la próxima liberación se determinan por el tiempo
disponible y la prioridad relativa.
• Liberaciones pequeñas: Al principio, se desarrolla el conjunto mínimo de funcionalidad útil

que ofrece valor para el negocio. Las liberaciones del sistema son frecuentes y agregan
incrementalmente funcionalidad a la primera liberación.
• Diseño simple: Se realiza un diseño solo suficiente para cubrir aquellos requerimientos
actuales.
• Desarrollo de la primera prueba: Las pruebas de unidad (para probar el funcionamiento del
módulo de modo aislado del resto) son frecuentes y continuas. Se aconseja escribir el código
de la prueba antes de la codificación de modo que sirva como un marco de referencia de
prueba de unidad automatizada.
• Refactorización: Se espera que todos los desarrolladores refactoricen de manera continua

el código, tan pronto como sea posible y se encuentren mejoras de éste. Lo anterior conserva
el código simple y mantenible.
• Programación en pares: Los desarrolladores trabajan en pares, y cada uno comprueba el

trabajo del otro; además, ofrecen apoyo para que se realice siempre un buen trabajo.
• Propiedad colectiva: Los desarrolladores en pares laboran en todas las áreas del sistema.
Todos los programadores se responsabilizan por el código, de modo que no se generen “islas
de experiencia”. Cualquiera puede cambiar cualquier función.
50
• Integración continua: Tan pronto como esté completa una tarea, se integra en todo el
sistema. Después de tal integración, deben probarse todas las pruebas de unidad y de
integración en el sistema.
• Ritmo sustentable: Grandes cantidades de tiempo extra no se consideran aceptables, pues

el efecto neto de este tiempo libre con frecuencia es reducir la calidad del código y la
productividad de término medio.
• Cliente en sitio: Un representante del usuario final del sistema (el cliente) tiene que disponer
de tiempo completo para formar parte del equipo XP. En un proceso de programación
extrema, el cliente es miembro del equipo de desarrollo y responsable de llevar los
requerimientos del sistema al grupo para su implementación.
Roles en XP
• Programador: Es quien escribe las pruebas unitarias y produce el código del sistema.
Debe existir una comunicación y coordinación adecuada entre los programadores y
otros miembros del equipo.
• Cliente: Encargado de escribir las historias de usuario y las pruebas funcionales para
validar su implementación. Además, es quien asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose en aportar
mayor valor al negocio. El cliente es solo uno dentro del proyecto, pero puede
corresponder a un interlocutor que está representando a varias personas que se verán
afectadas por el sistema.
• Encargado de pruebas (Tester): Ayuda al cliente a diseñar las pruebas funcionales, de

ejecutarlas y de brindar los resultados al resto del equipo.
• Encargado de seguimiento (Tracker). Es el responsable de que se cumplan las

estimaciones realizadas y de ver si los objetivos trazados en cada iteración fueron
alcanzados.
• Entrenador (Coach). Es la persona que conoce a fondo el proceso XP y el responsable

del proceso global. Debe proveer guía a todos los miembros del equipo para que el
proceso sea satisfactorio.
• Consultor. Es un miembro externo del equipo con un conocimiento específico en algún

tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
• Gestor (Big Boss). Es quien coordina el vínculo entre clientes y programadores, el que
ayuda a que las condiciones de trabajo sean las adecuadas.
51
Ciclo de desarrollo de la programación extrema
Los requerimientos de software se expresan como escenarios (llamados historias de

usuario). Los clientes trabajan estrechamente con el equipo de desarrollo para definir los
requerimientos y priorizar los mismos. Cada historia de usuario es lo suficientemente comprensible
y delimitada para que los programadores puedan implementarla en unas pocas semanas. Una vez
diseñadas las historias de usuario, el equipo de desarrollo las descompone en tareas y estima el
esfuerzo y los recursos requeridos para implementar cada una de ellas. Los programadores trabajan
en parejas y desarrollan pruebas para cada tarea antes de escribir el código. Todas las pruebas se
deben ejecutar satisfactoriamente cuando el código nuevo se integra al sistema. El cliente participa
en el desarrollo y son los responsables de definir las pruebas necesarias para la aceptación final del
software. La nueva construcción del software se acepta siempre que todas las pruebas se ejecuten
con éxito. Entonces esto se convierte en la base para la siguiente iteración del sistema.
Las historias de usuario
Queda fuera de alcance de este trabajo analizar en profundidad como es el relevamiento

basado en historias de usuario, pero si se describirá en qué consisten estas historias a modo de
poder comprender de modo general su funcionamiento.
Básicamente, una historia de usuario es un requerimiento que tiene un determinado usuario

y que lo expresa, de modo simple, desde su perspectiva. Suelen tener el siguiente formato:
COMO <rol>
QUIERO <descripción de eventos que queremos que ocurra>
PARA <descripción de funcionalidad>
Ejemplo en un banco
COMO Oficial de atención al cliente

QUIERO Presionar una tecla y acceder a los productos que el cliente tiene contratados
PARA Ofrecerle nuevos productos
Si se decide que la historia es pertinente, se la estima en cuanto al esfuerzo que demandará

realizarla y se priorizan para su realización. Cada vez que se termina un sprint se comienza a realizar
que tenga mayor prioridad de las pendientes.
52
Las historias pueden completarse con alguna descripción mayor de la funcionalidad y
también los criterios de aceptación. Por ejemplo: Primero deben mostrarse las tarjetas de débito,
luego las de crédito y por ultimo los seguros.
Ocasionalmente, alguna historia debe ser particionada en tareas más sencillas. Por ejemplo,
en el ejemplo, primero podría considerarse una historia para obtener el detalle de los productos
que posee el cliente y, en una segunda historia, ordenar estos productos y mostrarlos en pantalla.
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 de poner a prueba en XP son:
• Desarrollo de la primera prueba: En lugar de escribir algún código y luego las pruebas para
dicho código, las pruebas se elaboran antes de escribir el código. La prueba se corre a medida
que se escribe el código, con el objetivo de descubrir errores durante el desarrollo.16
• 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, que deban
implementarse en la siguiente liberación del sistema. En XP, la prueba de aceptación, como
el desarrollo, es incremental.
• Involucramiento del usuario en el desarrollo y la validación de pruebas: El cliente que

forma parte del equipo escribe pruebas conforme avanza el desarrollo. Por lo tanto, todo
código nuevo se válida para garantizar que eso sea lo que necesita. Contar con el cliente para
apoyar el desarrollo de pruebas de aceptación en ocasiones es una gran dificultad en el
proceso de pruebas XP.
• El uso de marcos de pruebas automatizadas: La automatización de las pruebas es esencial

para el desarrollo de la primera prueba. Estas se escriben como componentes ejecutables
antes de implementar la tarea. Dichos componentes de pruebas deben ser independientes,
simular el envío de la entrada a probar y verificar que el resultado cumple con la
especificación de salida. 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. Cada vez que se agregue cualquier funcionalidad al sistema, pueden correrse las pruebas
y conocerse de inmediato los problemas que introduce el nuevo código.
16
Puede consultarse el capítulo 3 del libro “ingeniería de Software” de Ian Sommerville para ver como mas detalle y
ejemplos sobre la primera prueba.
53
Programación en pares
Otra práctica innovadora que se introdujo en XP es que los programadores trabajan en pares
para desarrollar el software. Se requiere de dos programadores que participen en un esfuerzo
combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otro no
está haciendo actualmente, por ejemplo, mientras uno codifica, el otro se encarga de analizarlo para
mejorarlo.
Los roles en esta técnica son el Conductor y el Acompañante. El conductor es el que

implementa el código y el acompañante tiene como tarea observar y corregir en todo momento los
errores cometidos por el conductor, considerar soluciones alternativas y sugerir nuevos casos de
prueba. Esta constante inspección produce código y un diseño de mayor calidad.
El uso de la programación en parejas tiene algunas ventajas:
• Apoya la idea de la propiedad y responsabilidad colectivas para el sistema. El software es

propiedad del equipo como un todo y los individuos no son responsables por los problemas
con el código. 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. Las inspecciones y revisiones son muy eficientes para detectar un alto
porcentaje de errores de software.
• 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 sorprendentemente rápido.
• Múltiples desarrolladores contribuyen al diseño. Esto ayuda a crear mejores soluciones,

especialmente cuando una pareja no puede resolver un problema difícil.
• Mayor disciplina. Se concentran en lo que tienen que hacer en lugar de tomar largos
descansos.
Ventajas y desventajas de XP
Ventajas:
• 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.
54
• El código es sencillo y entendible, a pesar de la poca documentación a elaborar para el
desarrollo del sistema.
Desventajas:
• 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, lo cual, en la realidad, es muy difícil de

lograr dado que los usuarios tienen no pueden desatender sus propias tareas dentro de
la organización.
• 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 estándar.
• Requieren mayor cantidad de programadores entrenados, que suelen ser costosos y

difíciles de conseguir.
Para tener en cuenta
En la práctica, muchas compañías que adoptaron XP, no usan todas las prácticas de
programación extrema que se han mencionado. Por ejemplo, algunas compañías encuentran útil la
programación en pares; otras prefieren usar la programación y las revisiones individuales. Para
acomodar diferentes niveles de habilidad, algunos programadores no hacen refactorización en
partes del sistema que ellos no desarrollan, y pueden usarse requerimientos convencionales en vez
de historias de usuario. Sin embargo, la mayoría de las compañías que adoptan una variante XP usan
liberaciones pequeñas, desarrollo de primera prueba e integración continua.
5. Scrum
El modelo Scrum es, quizá, el modelo más aplicado entre las organizaciones que utilizan
desarrollo ágil. A diferencia de otros modelos, este 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
El proceso de Scrum se compone de tres fases. La primera es la planeación del bosquejo,

donde se establecen los objetivos generales del proyecto y el diseño de la arquitectura de software.
La segunda fase corresponde a una serie de ciclos denominados sprint, donde en cada uno se
desarrolla un incremento del sistema. Un sprint de Scrum 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
55
implementa el software. Al final de un sprint, la funcionalidad completa se entrega a los
participantes. Al finalizar, y como tercera fase, el equipo realiza una revisión del sprint donde
evalúan si hay cosas que mejorar en el próximo ciclo, y se reinicia el proceso.
Las características clave de este proceso son las siguientes:
1. Los sprints tienen longitud fija, por lo general de dos a cuatro semanas. Una vez definida la
duración ideal del sprint, en función de las características del desarrollo, la misma no debe
cambiarse ya que, en cierto modo, pasan a conformar la medida del ritmo de trabajo.
2. El punto de partida para la planeación es el Product Backlog, que es la lista de trabajo

pendiente de realizar en el proyecto. Los nuevos requerimientos se van incorporando a esta
lista. Al comenzar un sprint se revisan las tareas pendientes, se priorizan y se deciden cuál o
cuáles de ellas serán desarrolladas en ese sprint.
3. La fase de selección de tareas incluye a todo el equipo del proyecto que trabaja con el cliente,
con la finalidad de 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. Con el
objetivo de revisar el progreso y, si es necesario, volver a asignar prioridades al trabajo, se
realizan reuniones diarias breves con todos los miembros del equipo. Estas reuniones diarias
habitualmente se realizan sin sillas para que sean cortas y efectivas. Durante esta etapa, el
equipo se aísla del cliente y la organización, y todas las comunicaciones se canalizan a través
del llamado “Scrum Master”. El papel de este último es proteger al equipo de desarrollo de
distracciones externas y atender las necesidades que los miembros plantean en la reunión
diaria.
5. La forma exacta en que el trabajo se realiza puede variar y depende del problema y del
equipo.
6. Al final del sprint, el trabajo hecho se revisa y se presenta a los diferentes interesados,
continuándose con el siguiente sprint.
Roles en Scrum
Los roles de Scrum se dividen en dos categorías:
1. Roles comprometidos directamente con el proyecto: Estos roles son los que
obligatoriamente se requieren para producir el producto o del proyecto. Dichos roles son
los responsables del éxito de cada sprint y del proyecto en sí:
• Product Owner es la persona responsable de lograr el máximo valor empresarial para

el proyecto. También es responsable de la articulación de requisitos del cliente. El
Product Owner representa la voz del cliente dentro del proyecto.
56
• Equipo Scrum es el grupo o equipo de personas responsables de la comprensión de
los requisito,s especificados por el Product Owner, y de la creación de los entregables
del proyecto.
• Scrum Master es un facilitador que asegura que el equipo Scrum esté dotado de un
ambiente propicio para completar el proyecto con éxito. El Scrum Master guía, facilita
y les enseña las prácticas de Scrum a todos los involucrados en el proyecto; elimina
los impedimentos que encuentra el equipo; y asegura que se estén siguiendo los
procesos de Scrum.
2. Otros Roles involucrados con el proyecto: Son aquellos roles que, si bien son importantes,
no participan directamente del proceso Scrum. No siempre están presentes y no son
obligatorios, aunque en muchos proyectos desempeñan un papel muy importante y deben
ser tenidos en especialmente en cuenta. Como ejemplo, podemos nombrar a los
Stakeholder(s) (cliente, usuarios, accionistas).
Las ceremonias del Scrum
En base a lo anteriormente descripto cada Sprint estaría compuesto de 5 ceremonias o eventos:
1. Sprint Planning o planificación inicial, con la participación de todo el equipo de desarrollo,

es donde el Product Owner presenta la versión actualizada y priorizada del Backlog, para que
el equipo pueda estimar que tareas podrán ser incluidas en el próximo sprint. Se define
entonces que se va a hacer y cómo se realizará.
2. Daily Meeting o reuniones rápidas diarias, son encuentros breves para que cada miembro
del equipo informe que tarea realizará ese día. También informará al Scrum Master si tiene
algún impedimento para que éste pueda tratar de solucionarlo.
57
3. Sprint Review, es la reunión final al terminar el sprint, donde el product owner y el equipo
de desarrollo presentan a los stakeholders el incremento terminado, para que lo
inspeccionen y realicen las observaciones pertinentes. No se trata de una demo, sino que se
presenta el software funcionando en producción. De esta reunión pueden surgir nuevas
necesidades que pasan a actualizar el Product Backlog.
4. Sprint Retrospective. Esta reunión, que puede realizarse en conjunto con lo anterior,
consiste en reflexionar sobre el sprint que ha finalizado, identificando posibles cosas que
puedan mejorarse. Es común analizar que salió bien, que ha fallado y que cosas podrían
hacerse de un modo más eficiente.
5. Refinamiento del Product Backlog. Esta reunión adicional permite depurar el listado de
pendiente y completar, refinar o aclarar ciertas historias de usuario que pudieron quedar
pendientes durante el Sprint Planning.
El tablero Scrum
Un tablero Scrum es una parte integral de la metodología Scrum. Hace la carga de trabajo
visible y ayuda a los equipos a gestionar el desarrollo del producto de principio a fin. Es una
herramienta perfecta para monitorizar el flujo de trabajo y facilitar la sincronización diaria. El tablero
Scrum se puede dibujar en una pizarra o en un tablero de metal o corcho, o incluso se puede
organizar en una parte de la pared. Por supuesto hay soluciones informáticas que permiten hacerlo
por computadora, y compartirlo en línea con todos los miembros del equipo.
58
Cada fila del tablero Scrum es la historia de un usuario. Las historias pueden requerir una o
varias tareas para resolverla. Cada tarjeta empieza en el tablero Scrum en la columna Por hacer. A
medida que las tareas se van encarando pasan de pendiente a “en progreso”, luego a “testeo” y
finalmente se dan por “terminadas”. La persona que finaliza una tarea queda disponible para
ocuparse de la siguiente tarea pendiente.
¿Por qué utilizar Scrum?
Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto son:
1. Adaptabilidad: las entregas iterativas hacen que los proyectos sean adaptables y abiertos a
la incorporación de cambios.
2. Transparencia: por medio del Tablero de Scrum se visualiza el avance de cada Sprint y, al ser
compartido, lleva a un ambiente de trabajo abierto.
3. Retroalimentación continua: se proporciona a través de las reuniones diarias y revisiones al

finalizar cada sprint.
4. Mejora continua: los entregables se mejoran progresivamente sprint por sprint a través del
proceso de priorización del Product Backlog.
5. Entrega continua de valor: los procesos iterativos permiten la entrega continua de valor tan
frecuentemente como el cliente lo requiera.
6. Ritmo sostenible: los procesos scrum están diseñados de tal manera que las personas
involucradas pueden trabajar a un paso cómodo (ritmo sostenible) que, en teoría, se puede
continuar indefinidamente.
7. Motivación: los procesos de reuniones diarias y retrospectivas del Sprint conducen a

mayores niveles de motivación entre los empleados.
59
8. Resolución rápida de problemas: la colaboración de equipos multifuncionales lleva a la
resolución de problemas con mayor rapidez.
9. Entregables efectivos: los procesos de crear la lista de Product Backlog y revisiones

periódicas después de la creación de entregables, asegura entregas efectivas para el Cliente.
Críticas a la metodología Scrum
• El equipo puede sufrir estrés pues siempre estará de sprint en sprint, inmerso en un ritmo
muy intenso de trabajo. Es saludable introducir, cada tanto, sprint que impliquen una tarea
más relajada.
• El equipo puede estar tentando a tomar el camino más corto para sumar los puntos del
sprint, sacrificando calidad o seguridad.
• Difícil de aplicar en grandes proyectos.
• Se requiere de un experto en la metodología que monitorice 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.
Scrum, no solo para desarrollo de Software
Si bien es cierto que esta metodología nació para resolver el problema que se puedan tener
en el desarrollo de software, es necesario mencionar que no es una metodología excluyente a otro
tipo de proyectos. El marco de trabajo Scrum es aplicable a cualquier tarea cotidiana, pues permite
autogestionarnos y enfocarnos a la mejora continua.
A continuación, algunos ejemplos:
60
Planificación de bodas
Tareas del hogar
Actividades diarias en la oficina
61
6. Otras metodologías ágiles
Si bien Scrum y XP son las metodologías más utilizadas y difundidas, desde luego no son las
únicas. En todas estas metodologías los subyacen los principios del manifiesto ágil, tendiendo todas
ellas una estructura similar. Queda fuera del alcance de este apunte ahondar sobre las mismas, pero
si vale la pena al menos mencionar algunas de ellas
Metodología Crystal
Creada por Creada por Alistair Cockburn, uno de los firmantes del manifiesto ágil, se trata en
verdad de un conjunto de metodologías que proponen alternativas para diferentes tamaños de
equipos de trabajo y dificultad del proyecto, categorizándolos mediante una codificación de colores.
Esta centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y
la reducción al máximo del número de artefactos producidos. El equipo de desarrollo es un factor
clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener
políticas de trabajo en equipo definidas. Dada la vital importancia a las personas que componen el
equipo de un proyecto, sus puntos de estudio son:
• Aspecto humano del equipo

• Tamaño de un equipo (número de componentes)
• Comunicación entre los componentes
• Espacio físico de trabajo adecuado
• Políticas claras para todo el equipo.
Los valores propuestos son concordantes con los principios ágiles:
• Entrega frecuente y constante de software operativo a intervalos que pueden ser diarios,
semanales o mensuales.
• Comunicación permanente de todo el equipo de trabajo, preferentemente estando en el
mismo espacio (comunicación osmótica)
• Mejora reﬂexiva. Tomarse un pequeño tiempo (unas pocas horas cada o una vez al mes) para
pensar bien qué se está haciendo, cotejar notas, reﬂexionar, discutir.
• Hablar con los compañeros cuando algo molesta dentro del grupo.
• Focalizarse en lo que se está haciendo, teniendo claro el objetivo y contando con el tiempo
necesario para hacerlo.
• Tener fácil acceso a los usuarios y contar con desarrolladores expertos para consultas
puntuales.
62
Método de Desarrollo de Sistemas Dinámicos
(en inglés Dynamic Systems Development Method o DSDM)
Este método de desarrollo surge en Inglaterra, en los años 90, y busca hacer frente a la
problemática de desarrollar software en entornos con agendas y presupuestos apretados. Puede
considerarse como una adaptación del modelo RAD a los principios ágiles y, de hecho, promueve la
utilización de herramientas RAD.
Este framework de trabajo destaca 5 etapas, 3 de ellas previas a la construcción propiamente

dicha:
1. Estudio de viabilidad y de negocio de los proyectos. Solo aquellos que puedan

desarrollarse con un enfoque RAD pueden llevarse a cabo con esta metodología.
2. Estudio comercial o de la empresa. Se verifica que el sistema planificado pueda cumplir
con los requisitos solicitados por la organización.
3. Iteración del modelo funcional, que implica construir un prototipo del sistema
4. Diseño e iteración de la estructura, donde se construye y prueba la solución definitiva.
5. Implementación.
Los principios de esta metodología, una vez más, están en línea con aquellos enumerados en
el manifiesto ágil:
• Involucrar al cliente es la clave para llevar un proyecto eficiente y efectivo.

• El equipo del proyecto debe tener el poder para tomar decisiones que son importantes.
• DSDM se centra en la entrega frecuente de productos.
• El desarrollo es iterativo e incremental.
• Todos los cambios durante el desarrollo son reversibles.
• Las pruebas son realizadas durante todo el ciclo vital del proyecto.
• La comunicación y cooperación entre todas las partes interesadas.
7. Ventajas, dificultades y limitaciones de las metodologías ágiles
Las metodologías ágiles presentan ventajas a la hora de su utilización como también

desventajas. A continuación, enumeramos algunas:
Ventajas
• Las metodologías ágiles ofrecen una rápida respuesta a cambios de requisitos a lo largo
del desarrollo del proyecto, gracias a su proceso iterativo y a que el software está en un
proceso de cambio permanente.
• El cliente puede observar cómo va avanzando el proyecto, y por supuesto, opinar sobre
su evolución.
63
• El poder ofrecer entregables parciales permite ir atacando los objetivos más sencillos,
ganado tiempo y experiencia tiempo para atacar luego los objetivos más complejos.
• Uniendo las dos anteriores se puede deducir que, al utilizar estas metodologías, los
cambios que quiera realizar el cliente van a tener un menor impacto. Las entregas,
intervalos cortos de tiempo contienen solo una porción del producto deseado. Si el
cliente quiere cambiarlo nuevamente, solo se habrá perdido unas semanas de trabajo.
Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización
de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando
meses para que luego un mínimo cambio que quiera realizar el cliente, conlleve la
pérdida de todo ese trabajo.
• Se reducen los tiempos y costos de capacitación (el cliente participa del diseño y conoce
el producto desde su desarrollo) e implementación.
• Se involucra desde un principio y se da un rol a todos los stakeholders.
Dificultades en la aplicación de los principios
• Aunque es atractiva la idea del involucramiento del cliente en el proceso de desarrollo,

los representantes que asigna el cliente a menudo deben también seguir realizando sus
tareas dentro de la organización. Tienen sus propios tiempos y presiones y no siempre
pueden estar disposición de las necesidades del equipo de scrum.
• Quizás algunos miembros del equipo no cuenten con la personalidad adecuada para la
participación intensa característica de los métodos ágiles y, en consecuencia, no podrán
interactuar adecuadamente con los otros integrantes del equipo. Muchos
desarrolladores desarrollan hábitos de trabajo en solitario y no siempre se consigue
integrarlos eficazmente.
• Ocasionalmente, priorizar los cambios se torna muy difícil, sobre todo en sistemas donde
existen muchos participantes. Cada uno puede tener diversas prioridades a diferentes
cambios. Deben consensuarse, además, las necesidades operativas con las políticas.
• Mantener la simplicidad requiere trabajo adicional. Bajo la presión de fechas de entrega,

es posible que los miembros del equipo carezcan de tiempo para realizar las
simplificaciones deseables al sistema.
• Muchas organizaciones, especialmente las grandes compañías, pasan años cambiando

su cultura, de tal modo que los procesos se definan y continúen. Para ellas, resulta difícil
moverse hacia un modelo de trabajo donde los procesos sean informales y estén
definidos por equipos de desarrollo.
64
Limitaciones
• Falta de documentación del diseño. Por lo general la única documentación con la que se
cuenta son unos pocos comentarios en el código. Pueden producirse complicaciones con
la reusabilidad de componentes a partir de esta falta.
• También la falta de procesos rigurosos y documentación escrita puede producir

problemas si el software requiere ser certificado o auditado por equipos de contralor, los
que seguramente exigirán constancias de las tareas realizadas en el proceso de
desarrollo.
• Problemas derivados de la comunicación oral. No hace falta decir que algo que está
escrito “no se puede borrar”, en cambio, algo dicho es muy fácil de olvidar o de tener
ambigüedad. No siempre existe un entendimiento entre el usuario, que no entiende
cuestiones técnicas, y los desarrolladores que carecen de conocimiento sobre cuestiones
de negocios.
• El desarrollo no siempre tiene la misma secuencialidad ni necesidades que las prioridades

fijadas. Puede ocurrir que para poder implementar alguna solicitud sea necesario que se
programen funcionalidades extras o sea necesario implementar cosas que estaban
previstas para más adelante.
• Restricciones en cuanto a tamaño de los proyectos, para el desarrollo de software de

seguridad crítica, o para implementaciones dispersas geográficamente.
• Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no
hay documentación, o hay muy poca, para no volver a repetir los errores; lo mismo
ocurre con el diseño. La comprensión del sistema se queda en las mentes de los
desarrolladores.
• Los contratos por lo general son por tiempo insumido y no siempre fáciles de administrar
ni de controlar.
• Son difíciles las subcontrataciones y la presupuestación.
8. Casos de estudio
En alguna de las actividades de la materia Ingeniería de Software se les solicita a los alumnos
que expongan casos reales basados en su propia experiencia laboral. Resulta interesante analizar
alguno de estos casos para ver cómo se aplican las metodologías ágiles en algunas empresas de
nuestro entorno, en especial para ver cómo el aplicar la metodología en forma relajada casi siempre
terminan en fracaso.
También queda reflejado como, en ocasiones, se aplica mal la metodología o directamente

no se aplica. En ocasiones simplemente de dice que se usan metodologías ágiles porque suena
65
“moderno”, o quizá a los solos efectos de evitar alguna de las formalidades de los desarrollos
basados en un plan. En estos casos los resultados suelen ser desalentadores.
Si bien se trata de relatos parciales y en muchos casos descontextualizados, sirven como base
para ejemplificar los conceptos desarrollados en este trabajo. Con el permiso de los alumnos,
aunque preservando su identidad y el nombre de la organización al que hacen referencia, estos son
algunos de los casos que vale la pena considerar17:
Caso A: Éxito en metodología Scrum en un banco
“Debido a la creciente necesidad del equipo de analistas de datos del banco de contar con
una herramienta que cubra sus requerimientos de búsqueda de toda información contenida
en el Data Warehouse y que sea de fácil escalabilidad para la utilización en el resto de las
áreas, surge la idea de crear un equipo dedicado a la creación de un asistente virtual.
Para el desarrollo de este, se optó por una metodología ágil que permitiera la entrega de un
producto iterativo e incremental que, al disponibilizarse para su uso, aportará valor al
negocio de forma temprana. Se decidió realizar sprints con una duración de 2 semanas cada
uno y entregas productivas (releases) cada 2 sprints, poniendo a disposición el producto para
un grupo seleccionado de usuarios. Atravesando una profunda transformación, el banco
decide formar un equipo integrado por Scrum Masters, facilitando uno de ellos para este
proyecto. Además, se terminó de conformar el equipo con la contratación de un Product
Owner, un Technical Owner y un equipo de desarrollo.
Durante los primeros sprints, se desarrolló una UI sencilla conectada a los servicios
cognitivos. Esto permitió que el negocio pueda empezar a probar el asistente virtual y que se
puedan ir realizando mejoras incrementales tanto en la interfaz, así como también, en los
entrenamientos cognitivos. Además, cabe destacar que ayudó en el descubrimiento de
necesidades futuras. En los incrementales siguientes, el asistente se conectó con diferentes
servicios pasando a ser de esta manera un bot transaccional. Se agregó la analítica de datos
para poder realizar explotación de estos y, actualmente, se está trabajando con sprints de
seguridad y la incorporación de nuevas tecnologías.”
Caso B: Después de mucho tiempo y esfuerzo, se logró el objetivo.
“Este es un caso de uno de los principales banco privados de Argentina, el cual tuvo varios
problemas a la hora de hacer la transición desde el desarrollo de software con modelos
basados en un plan hacia el uso de metodologías ágiles, durante aproximadamente dos años
el banco tuvo inconvenientes con este cambio de paradigma de desarrollo, se utilizaron
muchos recursos para cambiar la estructura del departamento de sistemas, y aun así no se
17
Los alumnos tuvieron libertad para describir los casos. Si bien la actividad solicitaba que sean casos reales, no están
relatados en forma rigurosa, completa ni se basan en un análisis exhaustivo de las organizaciones a las que hacen
referencia. También pudieron agregar u omitir detalles para ajustarlos mejor a la actividad planteada. El análisis que se
hace de los mismos es exclusivamente basado en la información proporcionada por los alumnos, y pueden podría variar
en si se contara con información adicional del contexto.
66
consiguieron los resultados esperados, incluso pasaron varios scrum master por el sector sin
poder lograr cambios significativos.
Uno de los principales factores de porque se tardó mucho en cambiar el paradigma de

desarrollo de forme eficiente, fue que gran parte del sector seguía muy aferrado al viejo
modelo de desarrollo, es decir había un la falta de adaptabilidad por parte de los empleados
y de los jefes, se insistía en seguir con el modelo tradicional de cascada, el cual era utilizado
hasta ese momento, por otro lado, también influyó negativamente el no tener un plan de
proyecto para realizar este tipo de cambios, así como un plan de contingencia para evitar un
derroche de recursos innecesario, que fue lo que terminó ocurriendo.
Por último, en términos de ingeniería de software, queda en claro que, para llevar a cabo este
tipo de cambios de hacer las cosas, para imponer una nueva manera, no solo se requiere una
voluntad de adaptabilidad por parte de los individuos, sino que también se necesita un plan
que contenga al menos los principales riesgos posibles que puedan boicotear o ralentizar los
objetivos deseados.”
Caso C: Scrum en la industria automotriz.
“En este caso, hablamos de una empresa automotriz que subcontrata a empresas de IT para
los desarrollos de sistemas. Tiene en agenda muchos cambios de sistemas para optimizar los
procesos y hacer más dinámica la parte comercial. Si bien la mayoría de los sistemas antiguos
han sido desarrollados con el modelo tradicional ahora intenta hacer esos cambios usando
un desarrollo con metodologías agiles.
Esto dentro de un contexto de globalización donde la casa matriz francesa contrata, a través
de su filial argentina, a una empresa local de IT para el desarrollo ágil de un sistema usado
en Francia.
El software original utilizaba el lenguaje antiguo y era muy poco eficiente solo se conservaba
por el costo y el riesgo de cambiar el sistema, hasta que el mismo software se volvió
problemático y poco fiable. Dicho Sistema tenía como funcionalidad los pagos de primas a
concesionarios y era clave para la gerencia comercial de la empresa.
Durante la migración de COBOL/DB2 a Java/Oracle hubo cambios frecuentes y nuevos

pedidos por parte del usuario, cosa que no se hubieran podido procesar con el modelo
tradicional donde se establecen los requerimientos al inicio sin posibilidad de cambio. Se
incorporaron nuevas funcionalidades con las distintas liberaciones, se usó la metodología
SCRUM donde se establecieron la longitud de SPRINT en cuatro semanas con la lista de
trabajo (product backlog). Se hicieron pruebas en forma continua durante el desarrollo del
sistema por medio del sector de QA antes de la salida a producción y sus correspondientes
correcciones. El product owner de la empresa de IT fue clave para comunicar los
requerimientos al scrum master.
Este caso muestra el éxito de como la ingeniería de software a través del uso correcto de
metodologías ágiles, facilita los desarrollos y permite la migración de una plataforma vieja a
una plataforma nueva, brindando una herramienta para lograr un software más escalable,
funcional, eficiente, fiable y seguro.
67
A modo de conclusión, el desarrollo con metodologías ágiles del nuevo sistema de pago de
primas a concesionarios fue el puntapié que hizo que la empresa de IT ganara varias
licitaciones con esta multinacional francesa y logre afianzar su crecimiento dentro del
mercado de empresas de IT.”
Caso D: Problemas en metodología Scrum en una institución pública.
“La institución realiza los desarrollos necesarios para poder llevar a cabo las comunicaciones
y las integraciones para obtener los datos de las demás áreas de gobierno y así alimentar la
base de datos logrando que las comunicaciones sean con datos actualizados. Actualmente
desarrollan una plataforma de comunicación que centralice las diversas herramientas que se
utilizan para la comunicación dentro de lo que es gobierno como Mailing, IVR (Respuesta de
voz interactiva), audios, SMSs con los distintos proveedores contratados.
En este caso se puede ver como por la incorrecta aplicación (desde el punto de vista
conceptual) de metodologías ágiles, no se logró ningún beneficio y derivo tanto en pérdida
de tiempo como en la falta de resolución de problemas. Utilizaron una especie de Scrum ya
que lo adaptaron como les pareció útil. Por un lado, no se hacían las reuniones diarias, estas
fueron intercambiadas por reuniones semanales. En las cuales capaz se planteaba el estatus
del proyecto, pero no eran de utilidad ya que no se hablaba de los impedimentos para
avanzar con el proyecto o lo que se iba a desarrollar la semana siguiente. Con los futuros
usuarios no se hacia el relevamiento correcto de requerimientos lo que deriva en nuevas
reuniones con los mismos para poder refinar las historias de usuario que en primera instancia
estaban mal relevadas o relevadas de forma incompleta. Por otro lado, los product backlog
que se manejaban estaban mal armados, no estaban las tareas divididas en sprints como
deberían.
La funcionalidad que se debía entregar en los releases presentaba anomalías debido a que
por intentar cumplir con los sprints no se hacían las pruebas necesarias y se realizaban las
entregas como estaban. No se llegaban con los tiempos por el retrabajo ocasionado por los
errores de relevamiento y la mala organización de los tiempos donde no se les dio mucha
importancia a las contingencias.
Caso E: Pérdida de tiempo y dinero en un banco.
“El proyecto constaba del desarrollo del Homebanking, plataforma donde se prestan los
servicios bancarios a los titulares que registran una cuenta, (usuarios del banco), donde se
puede acceder a través de internet por medio de computadoras, tablets o teléfonos celulares.
El proyecto estaba organizado basado en un plan, con una combinación de metodologías
Scrum. Todas las fechas ya se encontraban planificadas, determinadas, las cuales se tenían
que cumplir al pie de la letra, (Por ejemplo, las salidas a producción).
En desarrollo los Sprints duraban 3 semanas, donde se pretendía llegar como sea a cumplir
con las historias comprometidas en cada Prueba con los usuarios.
68
El problema fue que por mucho tiempo por falta de tiempo varios equipos dejaron de testear,
hacer pruebas de software, y las incidencias que levantaban las personas de Testing no se les
prestaba demasiada atención, nunca eran prioridad, esto se sostuvo durante varios meses.
Llegó un día donde el producto que se estaba desarrollando tenía que salir a producción,
cuando se empezó a llevar a cabo el proceso para poder realizar esto, todo exploto en los
servidores, y afecto a otros módulos, debido a las fallas que se fueron acumulando y no se les
había dado la atención necesaria.
Solucionar esas incidencias, y realizar las pruebas que tendrían que haberse hecho en su
tiempo correspondiente produjo un enojo por parte de los PO, entre otras personas del banco.
Se tuvo que modificar toda planificación del proyecto el cual se atrasó bastante tiempo, lo
que a su vez hizo que se pierda una cantidad considerable de dinero.”
Como vemos en estos dos últimos casos, ninguno aplicó correctamente la metodología
Scrum sino que hicieron adaptaciones y mezclas. Toda metodología puede ser adaptada conforme
la organización y el tipo de proyecto, pero no puede ser desvirtuada al punto tal de perder su
esencia.
En el “caso D” caso en lugar de aplicar correctamente Scrum hicieron una adaptación tan
particular, que hasta las ceremonias fueron eliminadas, o en el mejor de los casos, adecuadas a
como mejor le venía a quienes llevaron adelante el proyecto.
En el “caso E” se trató de usar una metodología ágil para un proyecto rigurosamente

planificado en cuanto a sus fechas y entregables. Se supone que el modelo Scrum debe utilizarse en
aquellos casos conde hay posibilidad de cambios y donde las fechas y entregables no pueden
definirse al inicio. En proyectos tan rigurosos como este seguramente hubiera sido preferible utilizar
un modelo basado en un plan, que justamente puede establecer un proceso bien definido y ajustado
para cumplir con los tiempos pautados.
9. Comentario final
Como se ha visto, agilidad y desarrollo rápido no son sinónimo de un software construido a

la ligera, con errores y sin procesos que aseguren la calidad del producto entregado. Programar
software y entregarlo rápidamente, sin seguir ninguna regla ni metodología, no implica que se estén
siguiendo modelos ágiles. Por el contrario, implican enormes riesgos y altas chances de fracaso.
Muchos desarrolladores dicen usar metodologías ágiles porque suena a moderno y eficiente, sin
notar que, si no las aplican como corresponde, él éxito del proyecto solo depende de la buena o
mala fortuna.
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.
Lamentablemente, es frecuente encontrar organizaciones que dicen estar utilizando metodologías
ágiles cuando en realidad no están aplicando metodología alguna.
69
En estos casos debemos recordar que:
• Metodologías ágiles no implica ausencia total 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 tener necesidad de desarrollar actividades

protectoras de la calidad y una adecuada gestión del proyecto.
10. Bibliografía y sitios consultados

ROGER PRESSMAN: Ingeniería del Software, un enfoque práctico. 7ma Edición. 2010. McGraw-Hill.
CESAR A. BRIANO – GISELE AILIN BAUNALY – Desarrollo Ágil de Software
MANIFIESTO FOR AGILE SOFTWARE DEVELOPMENT http://agilemanifesto.org/
A Guide to the SCRUM BODY OF KNOWLEDGE (SBOKTM Guide). SCRUMstudy, 2013 Edition.
CEREMONIAS SCRUM https://www2.deloitte.com/es/es/pages/technology/articles/ceremonias-
scrum.html
70
4
Apunte 4
Ingeniería de Requerimientos
Claves para un desarrollo exitoso
71
1. Introducción
Cuando de estudian las etapas del ciclo de vida del software, es común pensar en la etapa
de análisis como aquella en la cual se hace un relevamiento a los diferentes usuarios de la
organización para poder determinar de los requerimientos del sistema que se va a desarrollar.
Habitualmente se estudian cuestiones metodológicas de esta etapa, por ejemplo, el armado

eficaz de entrevistas o la generación de casos de uso.
Sin embargo, habitualmente, se pasan por alto algunas cuestiones fundamentales. La

principal es que, por múltiples motivos, los usuarios no siempre están en condiciones darnos
información precisa. O no quieren hacerlo. O quieren, pero no saben cómo expresar correctamente
sus necesidades. Muchas veces, el relevamiento a usuarios se vuelve ineficaz.
Los enfoques actuales de ingeniería de software ya no hablan de “Análisis” para referirse a

esta etapa, sino que prefieren referirla como “Ingeniería de Requerimientos”. Y esto no es
solamente un cambio de nombre. Implica una diferencia de actitud: No basta esperar a que los
requisitos se nos presenten, sino que hay que construirlos. Debemos cambiar de una actitud pasiva
donde soloregistro lo que el usuario me cuenta, a una actitud proactiva donde construyo los
requerimientos y los valido.
Pero aun cuando tomemos la etapa con esta concepción, seguimos encontrando serias
diferencias ente lo que el usuario desea obtener y lo que finamente recibe. En este apunte se buscan
mostrar algunas claves para producir relevamientos exitosos y contribuir a la construcción eficaz de
requerimientos.
2. Los resultados no siempre son exitosos
En numerosas ocasiones, resultado final del software entregado no siempre es el que la

organización esperaba. Ni siquiera es el que el usuario imaginó al momento de formular sus
requerimientos.
Por diversos factores, hay una brecha grande entre realidad y expectativas, que se traduce,
como mínimo, en una primera mala impresión. Comienza una búsqueda de responsabilidades y
excusas. El usuario acusa al desarrollador de no haber hecho lo que le pidió. El analista se defiende
y culpa al usuario de no haber explicado correctamente lo que quería. El programador aclara que,
como no recibió los detalles necesarios, usó su criterio para definirá algunas funcionalidades. El líder
del proyecto indica que se cumplió con lo pautado y firmado y que, eventualmente, es
responsabilidad del cliente haber aceptado el diseño. Todos quieren despegarse del fracaso. La
siguiente imagen meme, viral entre informáticos, que ralamente describen un escenario que, si bien
puede resultar exagerado, no es tan diferente del que muchas veces ocurre en la realidad.
72
¿Quién o quiénes son los culpables de esta situación? Primero hay que indicar que suele
haber múltiples causas, y que en las organizaciones las cosas no son blancas ni negras. Sin embargo,
más allá de las excusas, más allá de que hay siempre hay definiciones poco claras, visiones
diferentes, dificultades reales y una enorme lista de etcéteras, la principal responsabilidad en este
caso cae en el profesional interviniente. El usuario sabe hacer su trabajo, seguramente sabe usar
sistemas, y hasta puede tener claro que cosas el sistema actual no le resuelve. Pero no
necesariamente sabe hacer especificaciones para desarrollar un software. Por el contrario, el
profesional de informática es quien estudia y conoce sobre las buenas prácticas de esta etapa, como
hacer un análisis lo más completo posible, y que este sirva como punto de partida para un desarrollo
exitoso.
Para comprender mejor el punto, hagamos un paralelismo con la medicina. Si un paciente

oculta algún síntoma o no lo expresa correctamente… ¿de quién es la responsabilidad si se le aplica
un tratamiento inadecuado? El médico es quien sabe que no basta lo que el enfermo le diga.
Seguramente le tomará la temperatura, lo auscultará y le mandará a hacer algún análisis más
profundo. Él es el profesional y el que sabe que antes de prescribir un diagnóstico debe tener toda
la información necesaria para hacerlo. No puede ampararse diciendo que el paciente lo le dijo
tambien le dolía una pierna.
3. Requerimientos contrapuestos
A lo anterior, hay que sumarle otro problema frecuente: ¿Qué pasa cuando dos usuarios o
dos áreas de la organización tiene visiones opuestas sobre cómo debe hacerse una tarea? ¿Qué pasa
si frente a una misma situación, dos áreas responden de manera diferente? ¿Qué pasa si sobre una
misma operación, las dos áreas tienen necesidades distintas?
73
Lo primero que hay que decir es que muchas veces los sistemas sirven para poner orden en
las organizaciones. Evitan ambigüedades. Evitan que cada uno opere como mejor le parezca. No
permite que ante una misma problemática se tomen dos caminos de solución diferente.
Pero claro, al relevar hay que detectar estas ambigüedades y resolverlas. No se puede tomar
como válido lo que solamente una persona dijo, aun cuando sea el jefe. Hay que relevar a otros
usuarios, a otras áreas y ver que todos coincidan. Hay que revisar los circuitos administrativos y las
normas para asegurarse que se cumplen. Y finalmente, si se detectan inconsistencias, hay que reunir
a las partes y resolver cual será el camino que se tomará en cada ocasión.
Una de las situaciones que frecuentemente tiene problemas es decidir qué datos se
registrarán de una operación. Hay algunos que no le sirven al usuario que los carga, pero que serán
necesarios más adelante. Pero, a veces, no se tiene acceso a esos datos en un primer momento o
demoran la carga o aumenta el trabajo de quien debe ingresarlos. Será necesario consensuar que
datos se incluirán en una pantalla, cuál de ellos podrían eliminarse porque no tienen un uso
posterior, y tambien cuáles podrían quedar pendientes de carga para una segunda instancia.
Actualmente, se puede acceder automáticamente a datos almacenados en sistemas de terceros
(Afip, Renaper, Correos, etc), mediante el uso de APIs18, y de ese modo se evita tener que ingresarlos
manualmente.
Un ejemplo de esto es el despacho de nafta en las estaciones de servicio. El playero querrá

un sistema lo más simple posible: Seleccionar el surtidor, verificar el importe, pasar la tarjeta, cobrar
y continúa despachando. La estación de servicio tiene otros requerimientos. Seguramente querrá
identificar al cliente; si necesita ticket con IVA discriminado tendrá que tener la información
impositiva; si es cuenta corriente posiblemente necesitará la patente el auto. Adicionalmente,
puede haber otros requerimientos de la petrolera, por ejemplo, tarjetas de puntos o descuentos. La
pantalla de carga ya no tendrá los datos mínimos que el playero indicó que necesitaba. Será
necesario diseñar un sistema que contemple las necesidades de la empresa, pero que no recargue
innecesariamente la tarea de quien despacha el combustible, en especial en los casos en que alguien
abona en efectivo, sin puntos ni descuentos.
4. Tres conceptos clave sobre relevamiento
1) La adecuada comprensión de requerimientos es fundamental, ya que en ellos se basa la

solución informática a desarrollar. Aunque a priori puede parecer una tarea relativamente
simple, existen números factores que la convierten en una de las tareas más difíciles de la
ingeniería de software.
2) Existe la tentación de empezar a construir aun cuando el problema no ha sido

completamente analizado y resuelto, acaso con la esperanza de que las cosas se aclararán
al programarlas. Sin embargo, difícilmente las cosas mejoren. Por el contrario, es factible
18
La API (application programming interface) permiten que dos piezas de software se comuniquen entre sí. Usando una
API se pueden obtener datos de un servidor externo, sin que esto requiera necesariamente acceder a los sistemas u
otros datos que operan dicho servidor. Por ejemplo, mediante una API se puede obtener acceso al mapa de Google de
una ubicación determinada e insertarlo en mi página web, de modo gratuito y sin necesidad de un desarrollo complejo.
74
que aparezcan más dudas y problemas, y que aumenten considerablemente los riesgos de
tener que rehacer nuevamente el código (con el consecuente incremento en los costos
monetarios y en los tiempos de desarrollo).
También es cierto que la formalización que debe emplearse al codificar software en un
lenguaje de computación puede contribuir, en algunos casos puntuales, a resolver
ambigüedades del lenguaje natural. Sin embargo, no puede usarse a la construcción de como
herramienta para mejorar sistemáticamente los relevamientos.
3) Las tareas de esta etapa deben adaptarse a las necesidades específicas del proyecto. Los
sistemas son diferentes, los usuarios también y por lo tanto pueden variar las estrategias
utilizadas. A veces, se elige un enfoque abreviado; otras, se lleva a cabo con mayor
rigurosidad. En ocasiones deben buscarse fuentes alternativas que corroboren o
perfeccionen lo expresado por los usuarios, como pueden ser normativas o manuales de
procedimiento.
5. El proceso de obtención de requerimientos
Precisamente el objetivo de este apunte es analizar la problemática de esta etapa, más allá
del habitual alcance de la bibliografía que, muchas veces, se limita a describir cómo es proceso de
relevamiento a los diferentes usuarios interesados. A modo de resumen y entendimiento general
del tema, vale analizar en que consiste formalmente el proceso, utilizando para ello el libro
“Ingeniería de Software” de Ian Somerville. Las actividades del proceso son:
1. Descubrimiento de requerimientos: Éste es el proceso de interactuar con los participantes

del sistema para descubrir sus requerimientos. Existen numerosas técnicas complementarias
que pueden usarse para el descubrimiento de requerimientos, como por ejemplo
entrevistas, cuestionarios, descripción de escenarios o casos de uso.
75
2. Clasificación y organización de requerimientos: Esta actividad toma la compilación no
estructurada de requerimientos, agrupa requerimientos relacionados y los organiza en
grupos coherentes. En la práctica, la ingeniería de requerimientos y el diseño arquitectónico
no son actividades separadas completamente.
3. Priorización y negociación de requerimientos: Inevitablemente, cuando intervienen

diversos participantes, los requerimientos entrarán en conflicto. Esta actividad se preocupa
por priorizar los requerimientos, así como por encontrar y resolver conflictos de
requerimientos mediante la negociación. Por lo general, los participantes tienen que
reunirse para resolver las diferencias y estar de acuerdo con el compromiso de los
requerimientos.
4. Especificación de requerimientos: Los requerimientos se documentan y se formalizan en

documentos de requerimientos. Estos documentos deben ser validados, aprobados y
quedan listos para la siguiente etapa.
Por supuesto, y como queda de manifiesto en el gráfico ilustrativo del proceso, esta es una etapa
cíclica, donde los se van trabajando y refinando hasta lograr el suficiente nivel de comprensión y
detalle para poder continuar con las próximas etapas de construcción
6. Las situaciones habituales que dificultan el relevamiento
Como ya se insinuó anteriormente, no todos los requerimientos aparecen fácilmente en una

entrevista o en cuestionarios que se les reparten a los usuarios. Por el contrario, existe una serie de
situaciones que dificultan la tarea. Entre ellos destacamos:
a. Los usuarios 19 no tienen claro lo que realmente necesitan o no saben expresarlo.
b. Los usuarios, por diversos motivos, omiten requisitos u ocultan información, aun
sabiendo de qué misma clave en el desarrollo de del sistema.
c. Los usuarios tienen temor que el nuevo sistema reemplace su trabajo o les haga
perder poder relativo dentro de la organización. Los sistemas socializan y hace publica
información que antes manejaba una sola persona.
d. Los usuarios no se involucran en la elaboración de requerimientos cuando estos

formales o escritos, por temor a que esta información se haga pública o llegue a sus
jefes. Ocasionalmente, pueden modifican lo expresado verbalmente cuando deben
formalizarlo.
19
A los efectos del presente apunte, el término usuarios debe considerarse en un sentido amplio, es decir que no
solo se refiere a las personas que efectivamente utilizarán el sistema, sino también a todos aquellos interesados de
algún modo en el sistema. El término en ingles Stakeholder podría ser más apropiado en este caso.
76
e. Los usuarios insisten en nuevos requisitos después de que el relevamiento ha
finalizado. A veces realmente aparecen cosas nuevas, otras simplemente, las
omitieron u olvidaron de expresar en su momento.
f. Los usuarios no comprenden los problemas técnicos ni entienden el proceso del

análisis o desarrollo de software. Por supuesto no tienen por qué entenderlo.
g. Tanto los usuarios como los analistas usan terminología ambigua o que no coinciden
con el sentido que tiene en un determinado contexto. Manejan un vocabulario propio
de su tarea o profesión, que no siempre es comprendido por el otro.
h. Muchas veces, los relevamientos son parciales, conforme la facilidad o no de obtener

datos. No se documentan los temas conforme su complejidad, sino en base a que tan
fácil resulta relevar y obtener requisitos. Algunas áreas, donde los usuarios resultan
más predispuestos, son relevadas “a fondo”, mientras de otras, apenas se consiguen
unos pocos comentarios.
i. Se intenta de “encajar” los requerimientos del sistema nuevo dentro de modelos ya

existentes o en desarrollos anteriores. Se busca convencer al usuario de que utilice un
esquema previamente desarrollado, aunque dicho esquema no sea el mejor para este
caso.
j. Las ideas o los pedidos de los usuarios no siempre pueden ser llevadas a la práctica
con la tecnología existente (o al menos dentro de los costos y plazos del proyecto).
k. Las ideas de los diseñadores no siempre son validadas por los usuarios. Muchas veces
buscan la solución más simple desde el punto de vista técnico y no desde las reales
necesidades del usuario.
l. No es fácil encontrar los usuarios claves, es decir aquellos que realmente puedan
proporcionar información de calidad respecto del software que se busca desarrollar.
Frecuentemente es la propia organización quien suele indicarnos a quien relevar,
aunque estos usuarios no sean los que mejor conozcan las necesidades del proyecto.
7. Otros problemas habitualmente no considerados
A los inconvenientes mencionados anteriormente debemos agregar una serie de temas

subyacentes, que habitualmente no son considerados al describir la etapa, pero que sin duda la
afectan significativamente y, por lo tanto, es importante tenerlos en cuenta:
• Ocasionalmente, la propia organización desconoce realmente cuáles son sus problemas,

las causas de ellos y/o sus necesidades reales. Nos contratan para desarrollar un sistema
de un determinado tipo, cuando sus verdaderos problemas son otros. En extremo,
pueden aparecer problemas de procesos o de relaciones de poder, que no se resuelven
con un sistema informático.
77
• Cuando surgen nuevos requerimientos durante el desarrollo, la organización presiona
para que sean incluidos en sistema que se está desarrollando, a veces respetando precios
acordados y plazos de entrega. En paralelo, los desarrolladores buscarán dejarlos de lado
y apegarse exclusivamente a lo acordado inicialmente. Cualquiera de los dos escenarios
es problemático.
• Eu ocasiones, Los jefes del área son los que toman a su cargo la tarea de pensar en un
nuevo sistema y también suelen ser ellos los que definen los requerimientos. Estas
definiciones no siempre reflejan el verdadero modo que se hacen los empleados.
• Muchas veces se presenta documentación y procesos formales, buscando que sean

volcados en la nueva solución informática. Esos procesos pueden estar desactualizados
o, incluso, las tareas pueden realizarse con circuitos informales que terminan siendo la
forma real en la que opera la organización (y la que debería replicar el sistema).
• Los jefes, aunque no lo digan abiertamente, pueden no querer implementar el nuevo

sistema, en especial cuando les viene impuesto por otras áreas de la organización o les
restringe su poder.
• Si los programadores tienen dudas, estas no son elevadas nuevamente a los usuarios
correspondientes para que las respondan. Por el contrario, suelen son contestadas por
los analistas. Esta respuesta no siempre coincide con las necesidades reales.
• No se tiene en cuenta que los usuarios son personas. Reaccionan de modo muy diferente
ante situaciones en las que se ven analizados. Pueden sentir que se está evaluando el
modo en el que realizan su trabajo y, por lo tanto, modificar sus respuestas. Incluso
reaccionan de manera diferente en formales donde están sus jefes, en entrevistas
individuales o en encuentros informales entre pares.
8. Escenarios hostiles
Los problemas mencionados anteriormente tienen puntos extremos que, en ocasiones,

terminan transformando el escenario en un ambiente hostil. En este tipo de escenarios el
relevamiento tradicional a usuarios se vuelve ineficaz, muy difícil o incluso imposible. Algunos
ejemplos de escenarios hostiles son:
• El sistema viene impuesto “desde arriba”. El área o los usuarios están en contra de su
implementación y harán cuanto esté a su alcance para que el relevamiento, y su posterior
puesta en marcha, fracase.
• El área interna de sistemas se opone a la instalación de un software ajeno. Aun cuando

ellos no tengan capacidad operativa para desarrollarlo, la idea de tener gente de
informática externa no siempre es bienvenido. Pueden aparecer requisitos y trabas
técnicas que seguramente harán más complejo el desarrollo.
78
• Pueden existir intereses contrarios entre dos o más áreas de la organización,
habitualmente entre aquella que se beneficie con la nueva implementación versus
aquella que tendrá más carga de trabajo o pierda el control sobre sus tareas.
• Tambien puede haber intereses políticos y/o económicos opuestos. Por ejemplo, cuando
se selecciona a un proveedor de software diferente del que propuso un jefe para el
desarrollo.
• Por tratarse de un sistema nuevo, afectar a un nuevo negocio y/o involucrar nueva
tecnología, no se tienen usuarios para relevar.
En estos casos puede no ser viable relevar a usuarios ya será cuestionable cuanto ellos digan.
Es necesario plantear estrategias de relevamiento “no ortodoxas”, buscando fuentes alternativas
para obtener requerimientos. Los documentos comerciales, el marco normativo legal, el sistema y
los informes que se utilicen actualmente, los manuales de procedimiento, la descripción de procesos
y el conocimiento de terceros expertos pueden ser, entre otros, fuentes de información que
reemplacen a las entrevistas con los usuarios.
También puede ser eficaz detectar y mantener reuniones informales con aquellos usuarios
que sabemos están a favor de nuestro trabajo, de modo de validar con ellos los datos relevados.
Incluso puede negociarse con ellos la posibilidad de incorporar funcionalidades que ellos necesiten,
además de las impuestas.
Resulta importante testear con frecuencia si quienes nos han contratado para desarrollar el
software mantienen el poder y el control de la organización. Muchas veces ese poder es la única
herramienta que tenemos para imponer el nuevo sistema. La utilización de modelo en espiral, con
análisis de riesgo suele ser útil en estos casos.
9. Algunos mitos sobre el relevamiento
Es interesante observar una serie de cuestiones que habitualmente se dan como definiciones
para esta etapa pero que finalmente no resultan ser del todo exactas en escenarios reales:
• La primera etapa de un desarrollo de sistemas es el relevamiento. En esta etapa se

busca detectar los problemas y las necesidades de una organización o un área
determinada.
Previo al relevamiento existen otras etapas donde los responsables de la organización y

los desarrolladores acuerdan el marco general del trabajo. Deben acordarse el alcance
del nuevo sistema y acordar presupuestos en tiempo y dinero, que obviamente serán
generales y sujetos a revisión, pero que servirán al menos para permitir cobrar el trabajo
79
que deba realizarse en esta etapa, aun cuando después por algún motivo no se continúe
con el desarrollo del sistema20.
• El relevamiento debe centrarse en los usuarios claves que, habitualmente, son los jefes
o los que más conocen la operatoria actual de la empresa.
De más está aclarar que no en todos los casos el jefe es el que mejor conoce la operatoria
del área. En alguna ocasión pueda que además debamos apoyarnos en algún operario
calificado o en personal con mucha antigüedad.
Pero… es necesario también intentar reconocer la actitud del usuario respecto del
proyecto. A veces, es preferible enfocarse y priorizarse aquellos usuarios que mejor
pueden expresar sus conocimientos, en aquellos que pueden reconocer y transmitir
mejor sus necesidades y en quienes tienen interés positivo en que el nuevo sistema de
desarrolle.
En el otro extremo, deben detectarse los “usuarios tóxicos” es decir aquellos que
aparentan brindar la mejor y más amplia información, y hasta parecen que apoyan
fervientemente nuestra tarea, pero, en realidad e internamente y por algún motivo, solo
buscan el fracaso del proyecto.
• Las entrevistas deben seguir los procedimientos formales que tenga la organización.
Deben armarse previamente utilizando cuestionarios preestablecidos, para que de este
modo se obtengan respuestas más concretas y certeras.
La formalidad es buena. Da un marco de seriedad y, en efecto, permite focalizar los temas

sobre los que se quiere una respuesta. Sin embargo, no todas las personas reaccionan
del mismo modo ante los cuestionarios y las entrevistas formales.
Además, las organizaciones tienen diferente nivel de formalidad en sus procesos de

evaluación. En algunas puede ser habitual que los empleados sean evaluados y contesten
cuestionarios, mientras que en otras esto nunca ocurre. En este último caso quizá
debamos buscar otros mecanismos.
Muchas veces la utilización de métodos más informales, “descontracturados” o lúdicos

permiten una mejor predisposición del usuario y, consecuentemente, una mejor calidad
de la información recibida. Además, permiten que el usuario se exprese libremente y
surjan temas no previstos originalmente.
Hay que tener en cuenta que la participación de la alta dirección en los relevamientos es
importante porque en cierto modo marcan la importancia que tiene el proyecto para la
organización. Sin embargo, no todos los empleados se sienten cómodos hablando frente
a sus superiores. Es bueno encontrar momentos y espacios seguros donde puedan
20
Puede consultarse el apunte sobre “Estimación, Costeo y Precio del Software” para profundizar sobre el proceso de
presupuestación
80
expresarse libremente sobre aquellas cosas que creen que están bien y aquellas que
creen que deberían ser modificadas con el nuevo desarrollo.
• Cuanto más profundo es el relevamiento, mejor se entiende el problema y menos

cambios futuros aparecen. Cuanto más tiempo se invierte en esta etapa, más calidad
tendrá el diseño posterior y menos probabilidades habrá de rehacer código.
Cantidad no es sinónimo de calidad. Entrevistar a más cantidad de usuarios no nos

asegurará mejor comprensión del problema. Siempre habrá alguna opinión más por
considerar, algún usuario más para escuchar, pero llega el punto en que su aporte es
marginal, no aparecen nuevas necesidades. Es más, en los extremos corremos el riesgo
de quedarnos relevando “eternamente”.
El tipo y el tamaño del sistema, la experiencia del analista y el tipo de usuarios, acortan
o alargan los tiempos de relevamiento.
Es posible construir sistemas exitosos con relevamientos a usuarios muy breves o incluso
nulos.
En ciertos modelos el relevamiento es la única etapa en la cual se permiten los cambios

y, por lo tanto, resulta un riesgo cerrar esta etapa. Pero hay que entender que los
cambios pueden ocurrir en cualquier momento, incluso provenientes del entorno o de
nueva normativa. Los mismos no pueden ser evitados ni limitados alargando esta etapa.
• Los programadores no deben participar del relevamiento.
En términos puros, el relevamiento se realiza para lograr un diseño que luego pueda ser
codificado por cualquier programador, aun cuando este no tenga contacto alguno con
los usuarios.
Sin embargo, la participación del programador en alguna parte del relevamiento puede
ser muy beneficiosa para que este comprenda mejor el problema.
Además, desde su experiencia técnica, puede tener dudas específicas o incluso aportar y
proponer soluciones innovadoras, que quizá no pueden ser visualizadas ni por el analista
ni por el usuario.
Nuevamente la generación de prototipos es una forma de que usuarios, analistas y

programadores trabajen en conjunto algún tema. El prototipo además ayuda a que las
partes tengan un entendimiento común del problema que están resolviendo, aun cuando
el vocabulario y las terminologías que usen sean diferentes.
81
10. Un enfoque alternativo
En este punto, cabe presentar un enfoque alternativo que, complementando las tareas
tradicionales, ayuda a mitigar muchos de los problemas enunciados previamente. Este enfoque se
basa en 3 conceptos clave:
a. ¡Cuidado! Hay personas del otro lado.
En el relevamiento se interactúa con gente. No pueden separarse los intereses

personales de los laborales. Tampoco las relaciones internas y de poder que ocurren en
la organización.
Debe tenerse en cuenta a quién se va a relevar, cuáles son sus intereses, sus problemas,
cuál es su posición en el área y en la organización. Todo esto modificará su perspectiva y
por lo tanto la información que nos brinde. No será igual los datos que podamos obtener
de alguien que está contento con su trabajo y con la compañía donde trabajan, que de
un usuario que no tiene buena relación con el equipo o que esta buscando cambiar de
trabajo.
Tambien debe analizarse cuáles son los procedimientos y costumbres habituales de la

organización en los casos en los que necesite la opinión de sus empleados. Si el usuario
está acostumbrado a participar de un determinado tipo de reuniones y/o entrevistas, es
razonable utilizar estos mecanismos. Pero, si la organización utiliza procesos informales,
emplear técnicas a las que el usuario no está acostumbrado, pueden generar
incomodidades y respuestas no de todo completas.
El reemplazo de métodos intimidantes por otros que generen una relación más relajada
y de confianza, puede generar una mejor calidad de resultados. Los registros por escrito
ayudan a recopilar mejor la información, pero también generan cierta resistencia. Los
usuarios no se expresan de igual modo si cada cosa que dicen queda textualmente
registrada.
La utilización de dispositivos portátiles para el registro de las entrevistas tiene ventajas

innegables. Sin embargo, proporcionan barreras adicionales: el entrevistador escribe
detrás de una pantalla y el entrevistado no tiene chances de ver que está pasando.
Preguntarle al entrevistado si le molesta, indicar sobre qué cosas se tomará registro o
permitir que vea la pantalla, pueden ser prácticas que ayuden a que el usuario se sienta
más cómodo y, por lo tanto, proporcione mejores datos.
Tanto si se utilizan métodos manuales como dispositivo electrónico, es una buena

estrategia consensuar lo que quedará finamente quedará escrito. De hecho, el usuario
debería finarlo. Algunas cosas que manifieste “en confianza” quizá no deban quedar
registradas, sino mantenida como información “off the record”21.
21
Esta expresión, en periodismo, se refiere a la información que se ha obtenido de fuentes confidenciales o
extraoficiales, y que no debe ser publicada por el medio. Sirven al periodista para obtener otra información o para seguir
investigando otras fuentes.
82
Una buena práctica para ganar confianza es negociar necesidades reales con necesidades
impuestas. Dentro de nuestras posibilidades, deben contemplarse las necesidades
particulares de los usuarios, aun cuando estas no tengan que ver con el sistema
propiamente dicho (ej. Conseguir un mejor equipamiento, o acceso a algún sitio
restringido)
En los casos más extremos, como en escenarios hostiles, el relevamiento podría reducirse
al mínimo, tendiendo principalmente a generar algún punto de interés común,
recurriendo después a fuentes alternativas para obtener requerimientos.
b. Ingeniería de requerimientos versus relevamiento.
El término relevamiento suele entenderse como el de recopilar información, conforme

nos la proveen las personas a quieres relevamos. Sin embargo, y por lo explicado
anteriormente, no podemos confiar que los usuarios nos van a proporcionar los datos en
forma completa. Los requerimientos deben ser buscados y no esperar a que aparezcan.
El analista debe adoptar una actitud activa, tratando de encontrar la mejor manera de
obtener y definir los requisitos. El término “ingeniería de requerimientos” se ajusta más
a describir una etapa donde los mismos deben ser construidos a partir de la información
que obtengamos.
Pueden prepararse de antemano hipótesis de trabajo y definiciones a obtener, conforme

la experiencia e información previa y el tipo de sistema que se busque desarrollar. Las
entrevistas con los usuarios no solo buscarán nos cuenten como es su trabajo y sus
necesidades, sino que buscarán obtener definiciones específicas sobre los cuales se
necesitan precisiones.
Para ejemplificar lo dicho puede pensarse que en un sistema de cobranzas es

imprescindible conocer cómo se conforma la cuenta corriente. Básicamente hay dos
alternativas: “Por Factura” o “Por Saldo”. En la primera cada factura debe ser cancelada
individualmente la su totalidad, mediante uno o varios pagos. En la segunda todas las
facturas generadas generan un saldo deudor que el cliente va cancelando. Puede pagar
cualquier cifra que desee, incluso generando saldo a favor. El analista deberá tener en
claro que debe obtener una definición sobre cual método es el utilizado para la cuenta
corriente a la hora de relevar el proceso. Resuelto esto, muchas de las cosas que el
usuario nos diga ya son parte de un proceso ya conocido, y del que sabemos cómo
funciona. Por el contrario, si olvidamos preguntar sobre esta modalidad o el usuario no
nos lo indica, no podremos continuar. Incluso puede ocurrir que, por los procesos
manuales, hoy trabaje con imputación por factura, porque resulta más sencillo controlar
manualmente y reclamar los comprobantes impagos, pero que a partir del nuevo sistema
se opte por trabajar sobre saldo, un mecanismo más ágil y flexible.
También deben considerarse los aportes que pueda hacer el profesional interviniente,
según sus saberes y experiencias, y la adopción de mejores prácticas para los procesos.
El nuevo sistema no necesariamente debe contemplar la operatoria tal cual se lleva a
cabo en una organización, sino que puede aprovecharse este momento para evaluar
83
nuevas alternativas y nuevos modos de realizar alguna tarea. De hecho, no es algo que
se dé por azar o como valor agregado, sino que muchas veces se contratan consultoras
que, además del sistema, se ocupan de mejorar circuitos y procesos y cobran un valor
adicional por tal servicio.
El resultado final del relevamiento debe ser presentado formalmente. Debe ser validado
y firmado por los distintos involucrados. De ser necesario, podrán negociarse plazos y
diferencias con los acuerdos iniciales.
c. Aprovechemos el primer encuentro.
Durante esta etapa se tiene el primer contacto con los futuros usuarios y con él área
donde más adelante se implementará el sistema. Esta primera impresión es entonces
decisiva para lo que ocurrirá después.
En esquemas de desarrollo basados en un plan es posible que, nuestro segundo

encuentro, sea ya en la etapa de implementación del sistema ya terminado. Es necesario
entonces aprovechar al máximo esta primera reunión para recaudar la mayor
información que podamos, a los efectos de aprovecharla en la construcción y que la
experiencia de uso del sistema lo más orientada al usuario posible.
Debe tenerse en cuenta que en todo encuentro existe una comunicación bidireccional.
El usuario también está analizando al analista y formándose una primera idea de cómo
será su situación laboral a partir de la implementación de un nuevo sistema. Se
establecerán lazos de confianza o de rechazo y se formarán conductas más o menos
favorables para el resto del proyecto. Será importante que el usuario perciba que el
nuevo sistema lo ayudará con su trabajo cotidiano y que nuestra intención es ayudarlo y
ajustar el sistema lo más posible para que eso ocurra.
Eventualmente, puede ser conveniente plantear algunas reuniones de avance donde se

vaya informando al usuario de lo que está pasando en las etapas en las que no participa.
Por supuesto siempre está el riesgo de que en estas reuniones aparezcan cambios o
nuevos requisitos, pero hay que comprender que la necesidad del cambio perdurará, la
contemplemos o no.
Cuanta más información se tenga del usuario, de sus expectativas, de la cultura se la

organización, de su área y entorno, mejor puede lograrse una implementación exitosa.
Incluso hay que prestar atención a cada área en particular, tratando de identificar
aquellas que podrían ser más problemáticas a la hora de implementar el nuevo del
sistema, detectando si es necesario realizar algún trabajo previo al despliegue.
Para ejemplificar, podemos utilizar algo aparentemente tan ajeno al desarrollo de

sistemas como puede ser el equipo de futbol del cual es hincha un determinado usuario.
Si en nuestro primer encuentro notamos que el usuario tiene en su escritorio un escudo
y la bandera de un club determinado, podemos utilizar esa información para presentar
84
luego una pantalla con los colores de su equipo. La predisposición sobre el nuevo sistema
no será la misma que si le presentamos una interfaz con los colores de su adversario. De
igual modo sería un error tratar de implementar un sistema utilizando en la pantalla los
colores que utiliza habitualmente la empresa competidora; o los de un grupo político
opositor.
El concepto de experiencia de usuario es primordial hoy en día. Se define como el

conjunto de factores y elementos relativos a la interacción del usuario con un entorno o
dispositivo concretos, dando como resultado una percepción positiva o negativa de dicho
servicio, producto o dispositivo. Para que esa experiencia sea satisfactoria es necesario
conocer al usuario más allá de a lo que a sus tareas se refieren.
10. Relevamiento y Metodologías Agiles
En el desarrollo ágil de software, la obtención de los requerimientos de usuario por supuesto

existe. Sin embargo, tiene características muy diferentes. Para empezar, no se pretende que todos
los requerimientos se hagan al principio. Por el contrario, se van expresando pequeños pedidos,
habitualmente el formato de historias de usuario. Estas historias se priorizan y se van programando
e integrando directamente en el software, que está siempre funcionando y en permanente cambio.
El usuario es parte activa del equipo de desarrollo.
Las metodologías ágiles quedan exentas de buena parte de la problemática de la etapa, en

especial de todos los problemas vinculados a la definición de requisitos en forma completa al inicio
del proceso. Pero, alguno de temas planteados, también se presentan en desarrollo ágil, y algunas
de las recomendaciones también pueden utilizarse.
Los usuarios siguen siendo personas y la formalización de su trabajo en historias, también es

algo nuevo para ellos. Las relaciones de poder y de dominio de la información cambian, cualquiera
sea la metodología por utilizar. Los usuarios claves son importantes en ambos casos. Los escenarios
hostiles también se presentan aun el desarrollo ágil.
Para el usuario, la participación en el equipo de desarrollo supone por lo general una carga
de trabajo adicional a sus tareas habituales. Como rara vez deja de hacer su trabajo, es importante
asegurarse o bien que reciba algún tipo de recompensa (bono salarial, horas extras, días libes) o, en
su defecto, que comprenda que los beneficios que tendrá con el nuevo sistema justifiquen el tiempo
invertido.
En resumen… este trabajo aborda fundamentalmente la problemática del desarrollo

tradicional, donde la obtención de requisitos es una tarea grande y que debe ser completada al
inicio, pero también puede servir conceptualmente y como como referencia para quienes utilicen
metodologías ágiles.
85
11. Conclusiones
Utilizar las herramientas adecuadas para lograr que el usuario nos exprese sus necesidades es
solamente un comienzo. Muchos son los factores que intervienen y muchas son las cosas que deben
tenerse en cuenta para lograr una eficaz obtención de requerimientos. Lograr que los mismos
respondan a necesidades reales, que estén completos, y que permitan desarrollar un software de
calidad, es una tarea que va más allá de estudiar los componentes de la etapa.
Conocer algunos de los problemas frecuentes que ocurren durante el análisis y tratar de
evitarlos, son el primer paso para poder aplicar diferentes estrategias para lograr un relevamiento
exitoso.
12. Bibliografía
86
5
Apunte 5

Diseño de Software
87
1. Notas preliminares
El Diseño es aquella etapa del ciclo de vida del desarrollo de software, en la cual se platea la
solución informática a las necesidades que los analistas relevaron y que describieron el “Documento
de Requerimientos de Software”. Se analizan dichos requerimientos para producir una descripción
detallada de la estructura y funcionamiento, de modo que los programadores puedan construirlo.
La salida es un conjunto de modelos y artefactos que registran las principales decisiones adoptadas.
Con el paso del tiempo, a medida que los sistemas fueron evolucionando y empezaron
incluso a trascender los límites de la organización, las necesidades de diseño fueron aumentando.
Ya no solo basta “traducir” el relevamiento a “instrucciones detalladas” que el programador pudiera
entender, sino que comienza a ser necesario definir muchas más cosas. Por ejemplo, cuál será la
arquitectura en la cual estará montado el sistema, que servidores utilizará, donde estará alojada la
base de datos y como se accederá a ella, como será la seguridad; entre varios otros temas. Los
puntos vinculados a los diagramas y metodologías de diseño y a bases de datos exceden el alcance
de este apunte.
2. Repaso
Ya se ha dicho en apuntes anteriores que en la etapa de diseño precisamente se diseña, valga

la redundancia, una solución informática a los problemas encontrados; obviamente contemplando
las necesidades de los usuarios. Generan la documentación con el suficiente detalle técnico para
que los programadores puedan construir el código a partir de ella.
Como también se mencionó anteriormente, el resultado final de la Ingeniería de

Requerimientos (Análisis) es un documento usualmente denominado “Documento de
Requerimientos de Software” donde se plantea que es lo que se necesita que el sistema haga. Este
documento, que debe estar validado y firmado tanto por los analistas como por los usuarios
intervinientes en el proceso de relevamiento, debería contener:
• Los servicios que se ofrecerán al usuario, incluyendo la explicación detallada de los

mismos.
• Panorama de alto nivel de la arquitectura del sistema.
• Requerimientos funcionales y no funcionales, ambos con detalle.
• Modelos y gráficos que ayuden al entendimiento.
• Plan de actualización del sistema.
• Glosario de términos.
• Apéndices con información de interés, por ejemplo, información relacionada a algún

hardware específico que deba utilizarse, como puede ser un lector de códigos o una
impresora particular.
88
A partir de este documento los diseñadores comienzan a trabajar en qué acciones deberá
realizar el sistema para ir dando cumplimiento de todos y cada uno de los requerimientos
planteados, dentro de las restricciones y sin omitir exigencias no funcionales22 planteadas.
3. La etapa de diseño – Una mirada rápida
¿Qué es el diseño de software?
El diseño es lo que casi todo ingeniero o arquitecto de software quiere hacer. Es el lugar en
el que las reglas de la creatividad se unen para formular un sistema que satisfaga los
requerimientos de los usuarios, las necesidades del negocio y las consideraciones técnicas.
El diseño crea una representación o modelo del software, pero, a diferencia del documento
de requerimientos (que se centra en describir los datos que se necesitan, la función y el
comportamiento), el modelo de diseño proporciona detalles técnicos sobre cómo debe
funcionar el software, en su arquitectura, sus estructuras de datos, interfaces y demás
componentes que se necesiten para implementar el sistema.
Se puede establecer un paralelismo entre el diseño y el plano de la casa. El plano les

proporciona a los constructores toda la información necesaria para poder edificar la casa.
Sabrán por donde pasar los caños, donde estarán las ventanas, para que lado deben abrir las
puertas.
¿Cómo podemos definirlo formalmente?
Es el proceso de aplicar distintas técnicas y principios arquitectónicos, con el propósito de

definir un dispositivo, proceso o artefacto23, con los suficientes detalles como para permitir
su realización física.
El producto final del diseño es un documento (o varios) estandarizado y con el detalle técnico
necesario, para que un programador pueda construir la solución informática, aunque no
haya tenido participación en las etapas previas 24.
22
El concepto de exigencias no funcionales hace referencia a aquellos pedidos de la organización que, aun cuando no
tengan que ver directamente con el funcionamiento de software, deben ser contemplados en la construcción. Por
ejemplo, que el fondo de pantalla tenga un determinado color, o que el tiempo de capacitación sea menor de 4 horas,
o que el sistema deba contar con una ayuda en línea, o permitir operar con 10 usuarios concurrentes.
23
Artefacto es un objeto construido con algún tipo de ingenio y técnica para un desempeño específico. En este caso un
diagrama o modelo que ayuda a describir cómo debe funcionar el software que se irá a construir.
24
Idealmente, cualquier programador debería poder desarrollar un software basándose solamente en las
instrucciones que recibe en el diseño. En la realidad, esto no siempre es posible. No solo porque dichas instrucciones
rara vez tengan el suficiente detalle, sino porque la propia complejidad de un desarrollo hace que los programadores
deban tener una comprensión mucho más amplia que la del módulo que les toca codificar.
89
¿Quién lo hace?
Siguiendo con el ejemplo de las casas, para dibujar un plano se requieren conocimientos
técnicos específicos. Hay que respetar escalas y convenciones para que los constructores lo
puedan interpretar.
Para el diseño de software necesario conocer determinadas metodologías y notaciones

estándares. Decimos que esta es la primera de las actividades que requiere tener
conocimientos técnicos específicos: Se modela la solución utilizando un lenguaje estándar
(por ejemplo, UML – Lenguaje Unificado de Modelado) que permita especificar las cosas sin
ambigüedades y que pueda ser comprendido por cualquier programador.
Además, se requiere conocer las diversas arquitecturas que pueden utilizarse para construir
software. Por lo tanto, el diseño debe ser realizado por quien tenga conocimientos de
ingeniería de software y de los estándares que se usan para modelar el sistema.
¿Cuáles son los pasos?
El diseño representa al software de varias maneras. En primer lugar, debe representarse la

arquitectura general del sistema o producto. Después se modelan las interfaces que
conectan al software con los usuarios finales, con otros sistemas y dispositivos, y con sus
propios componentes constitutivos. Por último, se diseñan cada uno los componentes
individuales que tendrá el software.
¿Cuál es el producto final?
El trabajo principal que se produce durante el diseño del software es un modelo de diseño
que agrupa los artefactos y representaciones arquitectónicas, las interfaces, el detalle de
cada componente y las instrucciones de despliegue (instalación y puesta en marcha del
software). Para la construcción de ese modelo deben seguirse estándares técnicos
específicos, de modo que cualquier programador sepa interpretarlo.
¿Cómo se asegura la calidad del diseño?
Al finalizar esta etapa es necesario realizar una auditoria o revisión técnica. Debe asegurarse
que el diseño contempla acabadamente los requerimientos del usuario, que no tiene errores
o inconsistencias, que no existen mejores alternativas, y que se respetan las restricciones.
También será necesario auditar que se han contemplado los patrones que la organización
aprobó como estándares y que se puede implementar en los plazos y los costos
comprometidos. Solo después que esta auditoría aprueba el diseño estará listo para ser
entregado a los programadores.
90
4. El proceso del diseño
El diseño se ubica en el área técnica de la ingeniería de software y se aplica sin importar el

modelo del proceso que se utilice. El diseño del software comienza una vez que se han analizado y
modelado los requerimientos.
El diseño es crucial para el éxito de la ingeniería de software. A principios de la década de

1990, Mitch Kapor, creador de Lotus 1-2-3, publicó en Dr. Dobbs Journal un “manifiesto del diseño
de software”. Decía lo siguiente:
“Vitruvio, romano crítico de arquitectura, afirmaba que los edificios bien diseñados eran
aquellos que tenían resistencia, funcionalidad y belleza. Lo mismo se aplica al buen software.
Resistencia: un programa no debe tener ningún error que impida su funcionamiento.
Funcionalidad: un programa debe se apropiado para los fines que persigue. Belleza: la
experiencia de usar el programa debe ser placentera. Éstos son los comienzos de una teoría
del diseño de software.”
Aun con todo el tiempo trascurrido, esta afirmación sigue hoy vigente y esas son
características que todos buscamos en cualquier software o app.
El proceso del diseño puede comprenderse con el siguiente esquema:
91
Las salidas del diseño son entonces:
• Arquitectura del sistema: Es el “plano general” del software. Refleja que módulos tendrá
el sistema y cómo se relacionan entre sí. También se definirán dónde estarán
almacenados cada uno de los componentes, teniendo en cuenta que, en sistemas muy
grandes, es posible distribuirlos, permitiendo que alguno de ellos cumpla funciones
específicas, mejorando la performance y la seguridad del sistema.
En la construcción de casas existen determinados patrones de diseño arquitectónicos

que se utilizan en determinados escenarios. En el polo norte las casas se construyen de
hielo, con un formato particular que conocemos como iIglú; en los bosques, aparecen las
cabañas de troncos como arquitectura dominante y en las grandes ciudades apilamos
una casa arriba de otra en lo que llamamos edificio. De igual modo, también existen
determinados formatos estándares que los arquitectos pueden elegir para desarrollar su
software.
Estos formatos arquitectónicos estándares se denominan patrones y resultan ser una

solución rápida y efectiva a un problema común diseño. Esta solución ya se ha probado
como válida, resolviendo problemas similares en ocasiones anteriores. En el anexo 1 se
muestran ejemplos de algunos de los patrones frecuentemente utilizados
• Especificación de la base de datos: En base a que información deberá procesar el

software, deberá establecerse qué datos manejará, donde se almacenarán y que
atributos tiene cada uno de ellos (Por ejemplo, APELLIDO será un campo de texto de 35
caracteres y no podrá estar vacío; PRECIO será un campo numérico que solo acepte
valores positivos, y CUIT será un campo de texto con el formato NN-NNNNNNNN-N)
También se definirán las relaciones entre ellos (cuando se ingrese un país, este deberá
previamente existir en la tabla de países). Incluso es posible establecerse condiciones
especiales para algún dato (por ejemplo, el cálculo de dígito verificador), o condiciones
especiales de actualización o de eliminación (por ejemplo, no debe permitir eliminar
clientes que tengan saldos en las cuentas corrientes).
Con esta especificación el arquitecto de datos (o quien tenga a su cargo esa función)
podrá construir la base de datos con todas sus tablas, campos, atributos y relaciones.
• Especificación de la interfaz: describe como se comunicará el software consigo mismo,

con los sistemas que operan con él y con dispositivos especiales (lectores de huella
digital, lector de cheques, posnet, etc.). Y obviamente, también definen como serán las
pantallas y la interrelación con las personas que lo operen. Lo dicho anteriormente
respecto de patrones también es aplicable en este punto.
La interfaz gráfica requiere una especial atención. No solo será el modo con el que los
usuarios operan el sistema, sino que será la imagen que moldee su primera percepción
sobre nuestro software. Una interfaz mal diseñada, confusa, con colores inadecuados
dará una la idea, quizá errónea, de que el software es complejo, viejo, o difícil de operar.
Seguramente predispondrá negativamente a los usuarios.
92
Debemos buscar diseños de interfaz que permitan la mejor experiencia de uso,
contemplando los diferentes tamaños y características de pantalla de los dispositivos con
los que se acceda. No es lo mismo diseñar una pantalla de carga para un sistema que
vaya a ser operado con mouse, teclado y un monitor de 15 pulgadas, que otro que será
utilizado desde la pantalla chica y táctil de un celular.
Los desarrolladores de sistemas operativos (Microsoft, Google, Apple) proveen patrones

de diseño que permiten a los desarrolladores generar interfases comunes con el
ecosistema. En el anexo 2 tendrán como ejemplo las guías de diseño de los
mencionados proveedores.
• Especificación de componentes: Es el Plano “detallado”. Describe qué tareas realizará

cada uno de los componentes que forman parte del software, cómo se organiza
internamente, cómo se relaciona con la base de datos, y cómo con los demás
componentes del sistema y el contexto.
Por ejemplo, si estamos programando un listado de operaciones mensuales para calcular

el IVA, tendremos que especificar que columnas tendrá, de que archivo se sacarán los
datos de cada columna, que operaciones habrá que hacer con esos datos, como se
calcularán los totales y e incluso, que módulo externo se ejecutará para comprobar que
la impresora esté en línea.
También hay que definir cuestiones externas como por ejemplo en que menú estará
colgado; que permisos se requerirán para su uso; si se puede ejecutar en modo
concurrente con otros módulos del sistema; si por una cuestión de performance debe
quedar en ejecutándose en segundo plano, y si puede o no ser accedido por otros
módulos que precisen sus servicios. Hasta pensando en la reutilización, debe indicarse
que partes del componente deben ser programados como rutinas separadas.
En resumen… el programador que reciba esta especificación deberá contar con todo el
detalle necesario (como ya se dijo reiteradamente, expresado de un modo
estandarizado) para poder desarrollar el componente sin necesidad de requerir ninguna
información adicional, sin que existan ambigüedades ni cosas que queden a su criterio.
Tal como se ha dicho al comienzo del apunte, para cada una de estas cosas hay que utilizar
diagramas y una terminología estándar, de modo que pueda ser comprendida por cualquier
desarrollador, independientemente de que hayan tenido o no contacto previo con los usuarios o
diseñadores. Nuevamente corresponde aclarar que el estudio detallado de estos diagramas
pertenece a las materias como “Metodología de sistemas de Información” y “Sistema de datos”
5. El “arquitecto de software”
YA hemos comentado que o, a medida que los sistemas fueron evolucionando y empezaron
incluso a trascender los límites de la organización, las necesidades de diseño fueron aumentando.
93
En desarrollos más grandes será necesario contar con una persona con conocimientos
mucho más amplio y específicos, que colabore con equipo de desarrollo en la definición de la
infraestructura sobre la que funcionará el nuevo sistema.
Según la CESSI, la cámara de la industria argentina del software, el arquitecto de software

“es el responsable de definir la arquitectura de los sistemas tomando las decisiones de diseño de
alto nivel y estableciendo los estándares técnicos, incluyendo plataformas, herramientas y
estándares de programación, teniendo en cuenta los requisitos funcionales, no funcionales y las
necesidades del negocio. En cooperación con el Líder de Proyecto, participa en la toma de decisiones
adecuadas para lograr una arquitectura del sistema que garantice un mejor desempeño, flexibilidad,
mantenibilidad, robustez, reúso o las cualidades que se pretendan de la aplicación”.
Entre las actividades que realiza un arquitecto de software:
• Negociar con el propietario de la aplicación y el líder de proyecto para tomar las decisiones
de diseño de alto nivel que correspondan.
• Seleccionar el software: Seleccionar la tecnología a utilizar en conjunto con el líder de

proyecto; y definir y revisar estándares y normas aplicables al diseño y construcción,
brindando coaching técnico al equipo de desarrollo.
• Diseñar la arquitectura: Conducir la construcción del modelo de arquitectura/diseño,

subdividiendo aplicaciones complejas en partes o componentes menores, más fáciles de
manejar.
• Realizar un seguimiento del proceso de desarrollo para asegurarse que sus instrucciones se
implementen en forma adecuada; y registrar los cambios de arquitectura que se produzcan.
• Asegurar la calidad: Medir la performance de la aplicación y conducir pruebas en relación

con la performance, seguridad, etc.
• Facilitador: Colabora con otras áreas como seguridad informática, base de datos,
operaciones, el equipo de mantenimiento, etc.
• Liderazgo Técnico: Capacidad para asumir la dirección técnica y asegurar todos los aspectos
de la arquitectura con responsabilidad y autoridad. Poder realizar coaching y mentoring25
sobre problemas técnicos, ayudando a la evolución profesional del equipo de
programadores.
• En conjunto con el líder de pruebas, definir las pruebas de los requisitos no funcionales y de
integración que se realizaran y efectuar un seguimiento de las mismas.
25
El Coaching es el proceso por el cual se acompaña a un individuo a que cumpla sus objetivos o adquiera
determinadas habilidades. El Mentoring significa que una persona experimentada, o con mayor conocimiento, ayuda a
otra con menos experiencia.
94
6. Diseño de la Interfaz de usuario
La interfaz de usuario representa un componente fundamental de los sistemas actuales. En

los sistemas actuales la interfaz de usuario representa un componente fundamental. A la hora del
diseño, resulta decisivo poder presentar al usuario una interfaz clara, funcional y, en especial,
cómoda de usar en diferentes dispositivos y con diferentes tamaños de pantalla. Un adecuado
diseño hará más fácil de operar un sistema y que se minimicen los errores de carga. Además, como
se ha dicho, servirá para vencer la resistencia inicial respecto de la nueva aplicación y moldeará una
percepción positiva (o negativa) sobre qué tan amigable o complicado será el nuevo sistema que
habrá de utilizar.
La interfaz de usuario es lo que determina cómo será la experiencia del usuario, es decir,
como se sentirá el usuario utilizando el sistema. No existe una receta común para todas las
interfaces, ni tampoco para todos los usuarios. Habrá que estudiar el hardware utilizado, la tarea
desarrollada y hasta el entorno de trabajo. No será lo mismo un sistema que corre sobre un desktop
de una oficina, del que corre en un tótem informativo de un shopping center, en una estación de
servicio o en la caja de un banco. Tampoco será lo mismo los sistemas que corran directamente en
un navegador web, donde existen algunas limitaciones y particulares propias de los estándares de
internet. Los diferentes tamaños de monitores y la comodidad que tiene el usuario para utilizar un
teclado físico o mouse harán también que se piensen en interfases diferentes.
Incluso en ocasiones se suele emular entornos que el usuario ya conoce, para poder de ese
modo achicar la curva de aprendizaje y vencer la resistencia al cambio. A continuación, dos pantallas
muy similares, la primera es una interfaz Windows, la segunda Linux.
Ben Shneiderman, en su libro “Designing the User Interface: Strategies for Effective Human-
Computer Interaction” describe ocho reglas de oro que pueden seguirse a la hora de construir una
buena interfaz de usuario:
1. Luchar por la consistencia:

Utilizar los mismos patrones de diseño y las mismas secuencias de acciones, para responder
a situaciones similares: el uso de un mismo del color, misma tipografía y misma la
terminología en las diferentes pantallas, comandos y menús. Por ejemplo, un botón con una
“X” debe cerrar una ventana en cualquiera de los lugares en ellos que se utilice. Una tilde
verde se utilizará siempre para mostrar confirmación o validez y se usará siempre el mismo
y para lo mismo. La combinación CTRL + P permitirá siempre imprimir la pantalla.
95
2. Buscar la usabilidad universal:
Reconocer las necesidades de los diferentes tipos de usuarios. Agregar funcionalidades para
novatos (ayudas) y expertos (atajos, comandos ocultos para saltar pasos, etc.)
3. Entregar información de feedback:

Es necesario mantener a los usuarios informados de lo que está ocurriendo en cada etapa
de su proceso. Esta retroalimentación debe ser significativa, relevante, clara y adaptada al
contexto. Si el proceso tiene varias pantallas, en la segunda debe mostrarse cierta
información, por ejemplo, el nombre del cliente con el que se está operando. Esto permite
que si el usuario es interrumpido (por ejemplo, recibiendo un mensaje de texto), cuando
vuelva a prestar atención a la pantalla recuerde los datos más importantes que cargo
anteriormente.
4. Diseñar diálogos de cierre:

Agrupa las secuencias de acciones y proporciona información de cierre antes de continuar
con el siguiente paso, por ejemplo, muestra un resumen de la operación de compra, antes
de que el usuario la confirme.
5. Prevenir errores:
Una buena interfaz debe estar diseñada para evitar errores tanto como sea posible. No se le
debe permitir al usuario ingrese datos inválidos (precios negativos o email sin “@”). Pero
también se debe ser claro en el mensaje que se muestre ante el error y como solucionarlo.
Por ejemplo, al no confirmar una operación no debería simplemente indicar que hay “datos
inválidos” sino indicar que “El mail no tiene un formato valido”, que “El precio no puede ser
negativo”, o que “la contraseña requiere números y letras”.
6. Permitir la fácil reversión de acciones:

Posibilitar que, en la mediad de lo posible, las acciones puedan ser canceladas, en forma
parcial o completa antes de la confirmación final (tecla ESC, por ejemplo).
7. Darle el control al usuario:

Proporcionar herramientas para que el usuario sienta que controla la interfaz y no al revés.
Minimizar acciones innecesarias. Permitir la interacción flexible (mouse o teclado, según
prefiera). Permitir que, eventualmente, pueda cambiar el color de la pantalla; controlar el
tamaño del texto; la ubicación de ciertos los objetos de la interfaz, como la barra de menú;
o, incluso, ocultar botones que no utilice.
8. Reducir la memoria de corto plazo:

Mostrar información relevante de pantallas anteriores. Proporcionar contenido
preestablecido (mostrar la fecha del día, traer el nombre cuando se ingresa el código de
cliente, calcular las cosas que pueden calcularse). Simular el mundo real (si se carga
información de una factura esta debe cargarse en el orden que se cargaría en una factura
manual). Presentar información en forma jerárquica y progresiva (comenzar primero
pidiendo el país, después las provincias y por ultimo las localidades. Incluso las localidades
podrán solo aparecer aquellas que sean de la provincia indicada)
96
7. El valor económico del diseño
Salvo raras excepciones, en un equipo de fórmula 1 la persona con mayor salario es el piloto.
El segundo, es el diseñador. Se sabe que, si el auto tiene un diseño de excelencia, gana milésimas
de segundo en cada curva, no desgasta menos los neumáticos, es más rápido, maniobrable o tiene
mayor potencia en un sobrepaso.
En el mundo de la moda pasa lo mismo. Es común que cuando las actrices famosas desfilan
por la alfombra roja, se destaque en las fotos quién fue el que diseño su vestido. Se pagan fortunas
a grandes diseñadores, y no tanto a quienes que cosen en vestido.
No pasa tal cosa en la industria del software, pero el concepto es el mismo: la forma en que
se comporta un sistema, el modo original en el que resuelve un problema, la experiencia de usuario,
la estética… todo esto depende de un buen diseño. En las tiendas de aplicaciones hay decenas de
software que realizan las mismas tareas. Sin embargo, no todos son iguales. Hay algunos que
resuelven el mismo problema de un mejor modo que el otro, simplemente porque fueron mejor
diseñados.
El diseño tiene, entonces, un valor económico por separado del resto del sistema. Es posible
contratar a un diseñador experto, pagarle por su trabajo, quedarnos con su diseño y luego entregar
ese diseño a cualquier programador que lo realicen físicamente.
Pero, además, es recién al final de esta etapa, cuando el plano está construido, que se tiene
la real dimensión del proyecto y, por ende, recién en este momento se podrá estimar, cuantos
recursos se necesitarán en las próximas etapas y cuánto tiempo llevará el desarrollo. Al terminar el
diseño sabré que tipo de base de datos voy a necesitar, cuantos programas de ABM (altas bajas y
modificación de datos), qué tan complejas serán las pantallas, qué procesos de cálculo habrá que
realizar, y cuántos listados tendrá el sistema. La real dimensión del proyecto se conoce en este
momento. Recién entonces se podrá estimar cuantos recursos se necesitarán en las próximas
etapas y cuánto tiempo y dinero llevará el desarrollo26.
8. Bibliografía
IAN SOMMERVILLE: “Ingeniería de Software”. 9na edición. 2011. Pearson Education.

ROGER PRESSMAN: “Ingeniería del Software”. 7ta edición. 2008. Ed. McGraw-Hill.
LAUDON Y LAUDON: “Sistemas de Información Gerencial”. 14 edición. 2016. Pearson Education
BEN SHNEIDERMAN: “Designing the User Interface: Strategies for Effective Human-Computer
Interaction”, Sixth Edition. 2016 Pearson
CESSI: Perfiles ocupacionales de la industria IT: https://www.cessi.org.ar/perfilesit/
26
Podrá profundizarse este tema con el apunte “Conceptos Fundamentales de la Estimación, Costeo y Precio del
Software”
97
ANEXO 1 – Patrones Arquitectónicos
Patrón de diseño en Capas
Los componentes del sistema se separan en capas. Cada capa presta servicios a la capa
superior. Un modelo estándar es utilizar 4 capas.
La ventaja de este modelo es que podemos cambiar cualquiera de las capas sin modificar el
resto. Podríamos por ejemplo cambiar de base de datos, sin que el sistema sufra otros cambios. O,
en un homebanking, sería factible actualizar la interfaz de usuario sin afectar ni la lógica del negocio
ni la seguridad integrada.
Patrón de Arquitectura Cliente Servidor
La arquitectura cliente-servidor es un modelo de diseño de software, en el que las tareas se

reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes de
dichos servicios, llamados clientes. Cuando un cliente realiza peticiones es el servidor, quien le da
respuesta. Si bien la idea se puede aplicar a programas que se ejecutan sobre una sola computadora,
es más ventajosa en un sistema multiusuario, distribuido a través de una red de computadoras. En
una arquitectura cliente-servidor, la funcionalidad del sistema se organiza en servicios, y cada
servicio lo entrega un servidor independiente. Los clientes son usuarios de dichos servicios y para
utilizarlos ingresan a los servidores.
98
Patrón de Arquitectura de Repositorio
Todos los datos en un sistema se gestionan en un repositorio central, accesible a todos los
componentes del sistema. Los componentes no interactúan directamente, sino tan soloa través del
repositorio. Este patrón se usa, generalmente, en sistemas que operan grandes volúmenes de datos.
Para abordar este tema con mayor profundidad puede consultar

Capítulo 6
99
ANEXO 2 – Patrones de diseño
En el presente anexo se presentan, a modo de ejemplo, los patrones de diseño que Google,
Microsoft y Apple ponen a disposición de los desarrolladores. Estos patrones no son obligatorios,
pero buscan que todo el ecosistema de aplicaciones tenga lineamientos comunes. Los usuarios
terminan acostumbrándose y adaptándose a ese diseño y preferirán aplicaciones que lo respeten,
salvo, claro está, en aquellas que requieran por algún motivo un diseño justificadamente diferente.
De este modo podremos observar cómo aplicaciones Android tienen características

similares. Incluso las por Microsoft se comportan de un modo similar a las de Google, y viceversa
con aplicaciones de Google en Windows.
Otro ejemplo para mencionar son las aplicaciones de Office. No importa si usamos Word,
Excel o Power Point, todos tienen menús similares, las opciones se llaman igual y funcionan del
mismo modo (abrir es abrir, para todos los programas), los iconos son los mismos, los botones y los
atajos de teclado también cumplen la misma función no importa lo que aplicación se use.
Material Design by Google – Vigente desde Android Loolipop 2014
Este patrón define desde la escala de colores a utilizar, hasta la distribución de los diferentes
elementos de la pantalla.
Color palette
This color palette comprises primary and accent colors that can be used for illustration or to
develop your brand colors. They’ve been designed to work harmoniously with each other. The
color palette starts with primary colors and fills in the spectrum to create a complete and usable
palette for Android, Web, and iOS. Google suggests using the 500 colors as the primary colors in
your app and the other colors as accents colors.
100
101
En este ejemplo vemos como dos aplicaciones de calendario, desarrolladas por dos empresas
diferentes, parecen idénticas en su funcionalidad. Solo cambian en el color
Gmail y Calendario de Google Outlook y Calendario de Microsoft
102
Material Design 2 by Google – Vigente desde mediados del 2018
Cambian, entre otras cosas, el patrón de color (colores más vivos y con menos matices) y la ubicación
de menús y los botones para hacer más fácil de usar las aplicaciones.
103
Mas información: https://material.io/guidelines/
Fluent Desing by Microsoft – Patrones para Windows 10 a partir del 2018

Diseño y disposición de las pantallas de aplicación, por ejemplo, de las ventanas del Sistema
Operativo
104
Mas información: https://material.io/guidelines/
X
Mas información: https://www.microsoft.com/design/fluent/
105
Human Interface Guidelines – Patrones de diseño de Apple
106
107
108
Mas información: https://developer.apple.com/design/
109
6
Apunte 6
Conceptos Fundamentales de la
Codificación de Software
110
1. Introducción
Habitualmente la bibliografía de Ingeniería de Software suele pasar por alto la etapa de

codificación. Seguramente entendiendo que es una actividad técnica que contempla una
problemática específica y, por lo tanto, que es abarcada por toda otra gran rama de la literatura:
aquella que se dedica específicamente a la problemática de la codificación y a la enseñanza de algún
lenguaje de programación.
De hecho, esta división también ocurre en la Licenciatura en Sistemas: en la materia

“Ingeniería de Software” se pasa por alto este tema, ya que hay 2 materias específicas que abordan
esta problemática: “Teoría de los Lenguajes y Algoritmos” y “Construcción de Aplicaciones
Informáticas”.
La idea de este apunte es conocer, no en profundidad sino a título meramente informativo,

en que consiste la etapa de Codificación, pensando especialmente en aquellos estudiantes que no
cuentan con conocimiento previo en programación, ni han cursado las materias anteriormente
mencionadas.
2. La etapa de codificación de software
¿Qué es la codificación de software?
Es la etapa donde se interpretan los requerimientos que los diseñadores expresaron al

detallar la arquitectura del sistema, la especificación de la base de datos, la especificación
de la interfaz y la especificación de los componentes y, a partir de ellos, desarrollar los
algoritmos y los programas que se ejecutarán la computadora. En esta etapa se programa y
construye el software propiamente dicho.
¿Quién la hace?
Esta tarea es desarrollada por programadores o desarrolladores. Deben tener habilidades

para interpretar los diagramas que componen el diseño y para codificarlo en algún lenguaje
de computación.
¿Cuáles son los pasos?
Reciben e interpretan los diagramas del diseño, elaboran algoritmos y diagramas que le
ayudan a resolver el paso a paso de lo que necesitan realizar, codifican el programa usando
algún lenguaje, lo documentan, lo ejecutan en la computadora y, por último verifican, que
funcione sin errores.
¿Cuál es el producto final?
Uno o varios programas ejecutables, bases de datos, archivos de documentación, archivos

adicionales que se requieran para el funcionamiento del programa (librerías externas,
111
imágenes, videos, et.), más toda aquella documentación e instrucciones de instalación; para
que el sistema pueda ser ejecutado en el entorno operativo del cliente.
¿Cómo se asegura que el programa no tenga errores?
Una vez que el software fue programado, y antes de que sea liberado para su uso, pasa a
una etapa de prueba o testeo. En esta etapa el programa es forzado a correr en condiciones
extremas de funcionamiento, buscando que aparezcan errores. Este testeo no reemplaza,
sino que complementa, la prueba inicial que hace el programador. Las empresas que hacen
desarrollos grandes suelen contar con un sector de testeo independiente (también llamado
de aseguramiento de la calidad) que cuenta con especialistas para realizar esta tarea.
3. ¿Qué tareas realiza un programador?
La primera y más obvia: programar
Para esto tendrá que aprender como programar en un lenguaje de computación, operar con
diferentes tipos de archivos y bases de datos, conocer de redes y de información distribuida,
interactuar con uno o varios dispositivos, incluyendo tiendas de aplicaciones y sitios para
poner código a disposición de quien lo necesite usar.
Si bien los programadores suelen especializarse en algún lenguaje especifico, generalmente

poseen habilidades y conocimientos para utilizar más de uno. Esto presenta una ventaja a
adicional: la posibilidad de construir algún módulo o rutina específica utilizando un leguaje
que sea más apropiado para dicha tarea.
Por otro lado, últimamente han ido tomando mayor relevancia nuevas herramientas que
permiten tanto a los desarrolladores, como analistas e, incluso a usuarios finales, programar
sus propias aplicaciones a través de interfaces gráficas. Este “movimiento” de no-code (sin
código) o low-code (poco código) promete aumentar significativamente el universo de
personas que pueden automatizar nuevos flujos de datos. Incluso desarrollar componentes
o aplicaciones completas. Esto, por un lado, puede generar una gran aceleración en el
proceso de transformación digital global y el desarrollo de nuevas soluciones. Sin embargo,
como contracara de esta “democratización” de la programación, se observan grandes riesgos
en torno a las distintas temáticas abordadas en esta materia, particularmente respecto de
las consideraciones de seguridad y rendimiento que todo software debe tener.
Comprender los requerimientos
Salvo excepciones o desarrollos muy chicos, el programador no es quien realiza

directamente la recolección de requisitos que plantean los usuarios.
Como ya se explicó, los analistas recopilan los requerimientos. Luego los diseñadores son
quienes plantean conceptualmente la solución informática, utilizando diferentes técnicas,
112
diagramas y documentos, que contienen el detalle de lo que se deberá programar. En cierto
modo, es el equivalente al plano del sistema.
Y así como el constructor debe saber leer un plano para comprender que debe construir, un
programador debe poder interpretar esos documentos para entender que es lo que tiene
que programar.
Documentar
El código que genera debe estar adecuadamente documentado. La documentación no solo

sirve por si alguien más debe modificar el programa en el futuro, sino para él mismo, para
cuando necesite corregir algún error, mejorar algún proceso o reutilizar el código en algún
otro desarrollo.
Respetar estándares y utilizar patrones
La programación de software tiene mucho de arte, de impronta personal. Casi con seguridad,
dos programadores que construyen el mismo software lo harán de modo diferente.
En una empresa o en un desarrollo colaborativo esto debe minimizarse. Los sistemas deben
responder a determinados estándares e integrarse con otras aplicaciones que estén
funcionado. La utilización de patrones no solo garantiza un desarrollo homogéneo, sino que
también mejorará la calidad del código, ya que permite utilizar prácticas ya probadas.
Testear
No existe el programa perfecto. Es casi imposible que un código recién programado funcione
sin ningún error y, por esto, es necesario que el programador haga la primera prueba. Pero
testear no es comprobar que el programa funcione sino forzarlo y llevarlo a situaciones
extremas para que falle.
Esto, que parece una obviedad, no lo es tal. Quien pasó horas tratando de desarrollar un
código buscará que su producto ande bien, y lo testeará con este objetivo. Debe entender
que el éxito de probar software es encontrar errores y no asegurar que el programa funcione.
El programador debe tener claro que las fallas que no encuentre, las encontrará el equipo
de testeo o, peor aún, el usuario.
Mantener el software existente
El software evoluciona en el tiempo. Aparecen errores que hay que corregir y nuevas
funcionalidades que son necesarias agregar. Entonces, una de las tareas que debe
desempeñar un programador es la de mantener actualizados sus propios programas.
Eventualmente, también deberá ocuparse de algún otro software de la compañía, aunque
no haya sido quien lo construyó. Como se dijo, la documentación del propio código, la
adopción de patrones ya definidos, la reutilización de componentes y emplear un estilo de
programación simple y claro, facilitarán esta tarea.
113
Llevar un adecuado control de versiones
Es frecuente que un de un mismo programa exista más de una versión. Además de la que
está en funcionamiento, puede estar trabajando en nuevas versiones que se lanzarán
próximamente, o incluso tener varias en simultáneo, para ser utilizadas en diferentes
sistemas operativos, idiomas o por diferentes clientes.
También es habitual que el desarrollador que tenga más de un espacio de trabajo (la
computadora de la oficina y en su casa, por ejemplo). Si bien hoy en día es simple sincronizar
dispositivos, debe prestar especial cuidado en que no se pisen archivos.
A la hora de entregar un programa para que sea puesto en funcionamiento, es necesario que
se asegure que el mismo contiene los componentes adecuados y actualizados que
corresponden a la versión que esté disponibilizando.
Por supuesto la organización también tendrá que establecer protocolos de trabajo para
asegurar una eficaz gestión del versionado27.
Resguardar su trabajo
Además de poseer copias de resguardo personales, debe asegurarse que todo su código se
encuentra resguardado y almacenado en los espacios corporativos que estén protegidos por
las copias de respaldo de la organización.
Comunicarse
Si bien el desarrollo de código es una tarea que, por lo general, se realiza en forma individual,
el programador debe tener contacto fluido con otros programadores del equipo y también
con testadores, que le van a reportar los errores que deberá corregir. Por otra parte, por más
que existan documentos formales, el diálogo con analistas y diseñadores, no está prohibido.
Si bien hemos dicho que un programador podría trabajar en forma autónoma solamente
interpretando el diseño, lo cierto es que en ocasiones su experiencia en cómo se resuelven
los problemas técnicos es muy valiosa. Puede sugerir mejores formas de hacer algo,
proponer funciones que técnicamente son sencillas y no se les han ocurrido a los
diseñadores, o también indicar que ciertas cosas que se han pedido tienen restricciones
técnicas que impiden ser construidas, al menos en el tiempo y costo presupuestado.
Por supuesto también tendrá que comunicarse con el líder de proyecto para informarle
grados de avance y potenciales problemas que afecten la calendarización del proyecto (es
decir el tiempo de entrega prometido)
Por último, si bien el programador y el usuario suelen estar en puntos opuestos y hablar en
términos diferentes, muchas veces la explicación directa del programador de cómo puede
27
Podrá consultarse apunte de “Despliegue del Software” para un mayor detalle sobre el versionado de Software.
114
operar determinada parte de la aplicación suele ser oportuna. También escuchar de primera
mano algún requerimiento puede ayudar a que entre ambos encuentren un modo diferente
y novedoso de resolver algún problema.
Acudir a fuentes fiables de información
Internet es el repositorio de código más grande que jamás se ha construido. Los

programadores pueden buscar sitios confiables donde hallar soluciones y mejoras para sus
programas. Puede ingresar a foros de consulta entre pares, leer consejos de expertos,
compartir su código para que la comunidad de programadores lo mejore (así funcionan gran
parte de los desarrollos de software libre), buscar y utilizar código de terceros ya hecho y de
libre disponibilidad. Incluso pueden adaptar y usar componentes de experiencia completa
de terceros (por ejemplo, un carrito de compras o un botón de pago), que luego personaliza
para usarlo en su sitio web.
Obviamente, cada componente disponible cuenta con sus respectivas condiciones de uso. Es
importante no plagiar ni vulnerar derechos de autor y contar siempre con todas las licencias
y los derechos de todo lo que se integre al final.
Cualquiera sea el caso, siempre debe validar que origen sea fiable y reconocido. El código
descargado deber ser testeado para asegurar que no tienen rutinas ocultas, código
malicioso, o que envía datos a terceros. Esto es especialmente importante cuando se utilicen
componentes sobre los que no se tiene acceso al código fuente.
Tender a la excelencia
Debe siempre buscar resolver los problemas con la mejor técnica posible, optimizando los
recursos y tiempo de procesamiento. No debe temer a refactorizar parte de su propio código
cuando encuentre mejores maneras de resolver algún algoritmo, o para mantenerlo
actualizado conforme la industria produzca mejoras que favorezcan su desarrollo.
Tener pasión
Programar es un desafío. Es maravilloso cuando uno ejecuta un programa que acaba de

codificar y este hace lo que se previó sin problemas. La satisfacción de haber dominado a la
máquina y de la tarea cumplida es única, e incomparable con ninguna otra.
Pero no siempre las cosas salen como se esperaba. Los algoritmos a veces no cumplen con
lo que se diseñó. Aparecen errores inexplicables o cosas que aparentan no tener solución.
Es allí cuando las horas pasan y la noche llega. Los programadores suelen ser apasionado por
lo que hacen y acostumbrarse a grandes desafíos, a veces sin horarios ni feriados.
Esto pone en aprietos a las organizaciones que no suelen estar preparadas para gente que a
veces necesita quedarse toda la noche trabajando, o que no puede cortar arbitrariamente a
las 5 de la tarde. Jefes y colegas también deben acostumbrarse a recibir consultas fuera de
115
sus horarios laborales. Hay programas críticos que deben estar monitoreados las 24 horas
los 365 días del año y entonces aparece la necesidad de guardias activas y pasivas.
El teletrabajo es una realidad. Pueden trabajar desde cualquier lugar del mundo y para
cualquier persona que los contrate, no importa donde estén.
Muchas veces es necesario prever relaciones laborales diferentes a otras miembros de la

compañía.
Respetar la ética
Los programadores tienen acceso casi ilimitado a la información de la empresa. Son ellos
mismos los que programan las restricciones de seguridad y las rutinas de codificación de
archivos. Algunos, incluso, tienen claves maestras que le permiten acceso ilimitado a
cualquier parte de los sistemas. Se espera entonces que actúen éticamente y respetando no
solo nomas legales, sino las políticas específicas sobre privacidad, resguardo siempre
información a la que tenga acceso.
Capacitarse continuamente
Las computadoras evolucionan, los lenguajes también. Cada vez hay mayor capacidad para
desarrollar aplicaciones y el programador debe aprovecharlas. Para ello es necesario que se
mantenga actualizado y que se capacite en forma constante.
4. EL proceso de la programación
Al comenzar, si todo se ha hecho aplicando los

Comprender el problema procesos de la ingeniería del software, el
programador recibe un diseño con el suficiente
detalle para poder comprender el problema que
debe resolver.
En programador deberá entonces plantear los

Plantear la lógica algoritmos que le permitirán resolver el problema.
Usualmente utiliza diagramas o seudocódigo, que
le permiten pensar primero “en papel” y
conceptualmente, como será el programa por
codificar.
116
Una vez que el problema está resuelto
Codificar el programa conceptualmente, lo codificará utilizando algún
lenguaje de computación.
Los programadores utilizan lenguajes cercanos al

Traducir el programa a natural (ingles) para programar. Estos programas
deben ser traducidos al lenguaje de 0 y 1 que es el
lenguaje máquina único que entiende la computadora. Esta tarea se
realiza de modo automático vía el entorno de
desarrollo.
Para terminar, debe probar que el programa no

tenga errores y que resuelva el problema
Probar el programa planteado. Una vez probado, el sistema está listo
para pasar a la etapa de testeo, para que el
software vuelva a ser probado, esta vez mediante
un equipo independiente.
5. La elección del lenguaje de programación
Una pregunta obvia que se desprende al analizar las tareas de programación es ¿Qué
lenguaje de programación se debe utilizar? y, atado a esta, ¿Quién elige dicho lenguaje?
La respuesta también parece obvia: El responsable técnico del proyecto debe elegir aquel
lenguaje que mejor se adapte al desarrollo, conforme las características que este debe poseer. Por
ejemplo, si el desarrollo fuera una App para celular, seguramente se utilizaría un lenguaje diferente
al que elegiríamos si necesitamos programar un sistema de conexión remota a una base de datos o
una aplicación que corra sobre una computadora de escritorio sin conexión a internet.
Sin embargo, esta respuesta obvia no siempre es correcta, o no siempre puede elegirse de
tal modo. Los proyectos pequeños, o las empresas de desarrollo más chicas, suelen contar con un
grupo reducido de programadores y, por lo general, estos se especializan en uno o dos lenguajes,
pero no en todos. Ya no se puede elegir el mejor, sino el que los programadores conozcan.
De igual modo, las organizaciones más grandes fijan sus propios estándares. Estos indican,
entre otras cosas, que lenguajes y que bases de datos deben utilizarse. Nuevamente, quien realice
un proyecto para esa organización, tendrá una elección condicionada. Por supuesto, esto es válido
siempre y cuando sea un desarrollo interno, o un desarrollo sobre el cuál la empresa adquiere
también los programas fuentes y la posibilidad de modificarlos. En los desarrollos del tipo “llave en
mano”, donde se recibe un sistema listo para usar, en realidad no importa en que lenguaje fue
117
desarrollado, sí que cumpla con otros estándares, por ejemplo, que funcione en determinados
servidores, con determinada base de datos, o que comparta información con otras aplicaciones de
la compañía.
En sistemas grandes, con módulos de diversas funcionalidades, es posible que no exista un

único lenguaje que sea “el mejor” para todos los usos. Y en este caso quizá sea necesario combinar
más de uno dentro del mismo sistema. Por ejemplo, podría utilizar un lenguaje para programar la
interfaz web, y otro distinto para interactuar con algún dispositivo que deba controlar, como ser un
lector de huellas digitales.
Los desarrollos previos y el contenido reutilizable también condicionan la elección. Si resulta

que ya tengo un 60% de los módulos ya construidos, seguramente va a ser mejor idea programar lo
que falta con el mismo lenguaje de desarrollo.
El hardware también influye. En las arquitecturas x86 (refiere genéricamente a las PCs y
servidores) hay una gran cantidad de lenguajes disponibles para elegir. Pero solo algunos de ellos
pueden ser utilizados también en arquitecturas ARM (celulares o Raspberry). Y si la organización
tiene algún mainframe (bancos, por ejemplo) el catálogo disponible queda reducido, a veces, a una
única opción.
Al igual que el hardware, los sistemas operativos también imponen sus condicionamientos.
Hay lenguajes e IDEs 28 que solo están disponibles para Linux, Android, o para Apple, como también
los hay multiplataforma, como por el ejemplo Microsoft Visual Studio.
Y al mencionar a Visual Studio también hay que hablar del licenciamiento. Este IDE, al igual
que otros, no son totalmente gratuitos. Proveen algunas funcionalidades básicas sin costo, pero
otras más avanzadas que requieren contar con una licencia. Si una organización tiene licenciado
algún entorno, seguramente tratará de que todas aplicaciones se desarrollen utilizándolo, junto con
los lenguajes que provee.
Es interesante mencionar que, por lo general, un mismo programa realizado en el mismo

lenguaje, puede comportarse de modo diferente en un sistema operativo que en otro. Incluso un
mismo código puede funcionar también forma distinta, conforme que IDE se utilice. Esto es porque,
ocasionalmente, las librerías adicionales que el programa consume pueden tener variaciones. La
programación multiplataforma requiere entonces o bien cambiar el código para cada una de ella, o
bien utilizar alguna plataforma de desarrollo que, ante un código genérico, prepara
automáticamente las versiones para cada una de las plataformas a utilizar. Eclipse, Genexus o el
propio Visual Studio son algunos ejemplos. Otra alternativa es que el software no se ejecute
directamente, sino utilizando una máquina virtual. De este modo, cualquier dispositivo que ejecute
dicha máquina virtual estará en condiciones de correr el programa. Así, por ejemplo, funcionan las
aplicaciones JAVA y su Java Virtual Machine.
28
IDE: Entorno de Desarrollo Integrado. Es una aplicación informática que provee al desarrollador de software de una
serie servicios que facilitan su tarea de programar. Habitualmente cuentan con un editor de un editor de código fuente,
optimizado para uno o varios lenguajes, herramientas de construcción automáticas y depuradores de código. Algunos
también proveen asistentes y patrones predefinidos para facilitar y automatizar determinadas tareas, como la
construcción de pantallas y listados.
118
Atado a esto, los lenguajes de programación y las IDEs también evolucionan en el tiempo.
Van apareciendo nuevas versiones que agregan funcionalidades y los hacen cada vez más potentes.
Por lo general, no hay compatibilidad de código, en especial hacia atrás. Con el tiempo, algunos
lenguajes se vuelven obsoletos y aparecen otros mejor preparados para los nuevos desafíos. Es decir
que también existen condicionantes por ese camino: No solo hay que elegir el lenguaje, sino que
versión y que IDE se utilizará.
En resumen… claramente la elección del lenguaje es una decisión principalmente técnica. El

responsable técnico, seguramente con la colaboración los programadores, será quién deberá decidir
cuál es el mejor lenguaje para desarrollar un determinado sistema. Pero esta decisión no será libre
ni exclusivamente basada en las ventajas o desventajas que un lenguaje tiene para en nuevo
desarrollo, sino condicionada por múltiples factores e imposiciones.
6. Referencias
Centro de Formación de Alto Rendimiento en programación y Tecnología. https://keepcoding.io/
119
7
Apunte 7
Conceptos Fundamentales de las

Pruebas de Software
120
1. Introducción
La prueba o testeo es, sin dudas, una herramienta clave para asegurar la calidad del software.
Probar todos y cada uno de los componentes de un sistema, tratando de encontrar errores y
defectos, es una tarea compleja pero muy necesaria. Practicante no hay antecedentes históricos de
un sistema que se haya programado de modo perfecto y sin errores y, por lo tanto, encontrar
problemas y solucionarlos antes que lleguen a la versión operativa es absolutamente
imprescindible.
Como en el resto de las etapas, también en esta surgen particularidades para tener en
cuenta. Y una de las más importantes es cambiar la concepción inicial de la etapa: No se prueba que
un sistema funcione, sino que se lo fuerza a fallar. La premisa es simple: un programa puede
funcionar correctamente en su uso habitual, pero puede fallar ni bien se lo exige o cuando se
ingresan datos erróneos. Bajo este paradigma, el presente apunte busca resaltar algunos aspectos
para tener en cuenta al momento de probar software, más allá de la aplicación de los distintos tipos
de pruebas y técnicas, que los encargados del testeo utilizan en el proceso.
2. Buscar que falle, no probar que funcione

Usualmente, la etapa de prueba de software es definida como aquella en la cual se
comprueba que el software no tiene errores, que cumple con los requisitos del cliente y, por lo
tanto, puede ser liberado y puesto en operación. Esta definición tiene mucho de cierto, pero no es
del todo apropiada.
El trabajo de la persona que testea software no es probar que el software ande bien sino,
por el contrario, buscar que falle. Y esto no es solo un juego de palabras: Una cosa es probar algo a
ver si funciona y otra diferente es exigirlo hasta que aparezca un error.
Una de las figuras más influyentes de la generación fundadora de la ciencia de la

computación, Edsger Dijkstra enunció allá por 1972: “Las pruebas pueden mostrar solola presencia
de errores, mas no su ausencia”. El concepto, que se mantiene intacto hasta nuestros días, es claro:
La prueba busca errores.
El programador, desde luego, trata de producir código sin errores. Su éxito es entregar
aplicaciones sin fallas. El tester29, por el contrario, asume la premisa de que el software tiene
errores, sin importar que tan bien haya sido programado. Su tarea es encontrarlos antes que lleguen
al usuario final. El éxito en su tarea es encontrar la mayor cantidad de errores posibles, en el menor
tiempo y con el menor costo. Para esto, literalmente ataca al programa desde varios flancos y con
diversas estrategias, para forzarlo a fallar. El mejor tester es aquel que más errores encuentra, no
aquel que determina que el software funciona.
El mejor ejemplo son las pruebas a las que se someten los automóviles antes de salir al
mercado. Para probar el vehículo no se lo conduce por una carretera recién asfaltada a una
29
La palabra “Tester” o “Testeador” no forman parte de lenguaje castellano, aunque se utilizan cotidianamente con
varios usos. En este apunte hace referencia a la persona encargada de llevar a cabo las pruebas y testeos del software.
121
velocidad controlada y sin maniobras bruscas. No se busca ver que tan cómodo y placentero es
conducir en condiciones normales, sino que, lo que se quiere es determinar, cómo responde ante
situaciones extremas. Se lo prueba en terrenos irregulares, se lo exige en subidas imposibles, se
comprueba como frena en lluvia o nieve, se mide que los vidrios no estallen con el mínimo impacto.
En las pruebas se busca exigir al máximo el auto para ver hasta donde aguanta. En test de choque
(crash test) literalmente se destruye el vehículo para encontrar componentes defectuosos o fallas
de diseño. El auto queda destruido casi por completo al finalizar la prueba. Pero esta destrucción
aporta muchísima información a los ingenieros sobre cuáles fueron sus límites, asegurando que esos
valores superan largamente un uso normal del vehículo.
Lo mismo pasa con un electrodoméstico… Las puertas de las heladeras se someten a pruebas
de apertura abriéndola miles de veces, hasta que se rompan. Si supera holgadamente lo que sería
un uso cotidiano, entonces el mecanismo es apto. El éxito de la prueba no es que la puerta abra
bien sino lograr que falle. Recién cuando esto se logre se podrá determinar si es necesario usar otros
componentes o fortalecer el diseño.
Por supuesto… ni el auto probado ni la heladera con la puerta rota se entregan al público.
Simplemente sirven como modelo conceptual para la producción de otro producto similar, bajo las
mismas condiciones de diseño y con los mismos componentes que los testeados. La heladera que
compramos no pasó por los exigentes testeos anteriormente mencionados, pero se ha construido
igual que aquella cuya puerta soportó varios miles de aperturas.
Con el software tenemos una ventaja: El producto “destruido” puede ser corregido y
entregado al cliente, que recibe la misma copia funcional que la que se testeo (o eventualmente
una copia exacta).
3. La calidad y las pruebas

Las pruebas son un elemento crítico para asegurar la calidad de software (software quality
assurance o, simplemente QA), pero no son sinónimos. La calidad es un proceso mucho más amplio,
que involucra a todas las actividades del proceso de desarrollo. Incluso la etapa de pruebas debe
ser sometida a pruebas, vale el juego de palabras, a auditorías y a controles de calidad.
Al finalizar la etapa de testeos debería quedar demostrado que el software es confiable y

seguro para ser operado. Pero para que esto ocurra se requieren varias cosas:
• Antes de comenzar cada tipo de prueba, se debe definir en que consiste la misma; en
que entorno se realizará; que juego de datos se utilizaran y cuáles son las condiciones
esperables para darla por finalizada y superada.
• Se deben realizar testeos y auditorias para verificar que en efecto se han realizado todas
y cada una de las pruebas pautadas, cumpliendo con las definiciones de cada caso.
• Cada prueba debe tener un responsable, que firme y avale los testeos realizados.
• Debe documentarse todo el proceso de prueba y aprobación y poner estos resultados a

disposición del usuario, ya que este que no tendrá la capacidad de realizar todas y cada
122
una de las pruebas, sino que deberá confiar en estas certificaciones. En ocasiones,
organismos de contralor controlan estos registros.
4. La prueba es la única actividad optativa en el proceso de desarrollo
¡El título de esta sección es peligroso, temerario, alocado, pero lamentablemente cierto!
Un software no puede prescindir de un análisis y diseño. Sin ellos no se sabría que construir.
Mucho menos de la codificación, sin ella directamente no existiría el software. La puesta en marcha
también es obligatoria si es que se quiere usar el sistema. Pero verdaderamente un software podría
entregarse sin prueba, o con menos de la necesaria, acaso confiando en la suerte o en la excelencia
de la programación.
¿Por qué alguien seria ten irresponsable para entregar software sin probar? ¿Por qué
utilizaríamos software que, sabemos, es altamente probable que falle? Si bien no parecería haber
una respuesta lógica, los números gobiernan al mundo y, por lo tanto, existe una: Hay razones de
costo que ponen en peligro la etapa.
Para eso, se juntan tres componentes explosivos: 1) Cuando mejor y más exhaustiva es la
prueba, más costosa es. 2) En este momento del proyecto, el software ya está programado y podría
usarse, aun con errores. 3) La etapa de pruebas ocurre justo antes de entregar el software. Si
combinamos estos 3 componentes con una gestión deficiente del proyecto, la bomba explota.
¿Pero cómo ocurre la explosión? Es posible imaginar un proyecto que presente problemas
de costo y de tiempos. No es extraño que las primeras etapas de un desarrollo, en especial la
codificación, lleven mucho más tiempo y dinero que el previsto originalmente. Llegar a la etapa de
pruebas con el presupuesto agotado y con los plazos de entrega próximos a vencer es algo que,
lamentablemente, ocurre con más frecuencia de lo que debería.
En este contexto aparece una decisión difícil: Gasto el poco tiempo y dinero que me queda
en probar exhaustivamente el software o, otra posibilidad, lo entrego así como esta y, en todo caso,
pateo el problema para más adelante. Incluso hasta tengo la posibilidad de negociar algún contrato
de mantenimiento para financiar la corrección de errores. La tentación es alta, hay que admitirlo.
Aun cuando no se llegue a extremos de eliminarla, a veces se reduce a su mínima expresión.

Ya no se buscan errores, sino que sólo se prueba que el software “más o menos” funcione y que
cumpla con las condiciones mínimas para entregarse: básicamente que no se “cuelgue” ni bien el
usuario ingresa.
Esta imagen grafica como la ejecución real del proyecto de software se va corriendo respecto
de las fechas pautadas originalmente. Los tiempos disponibles para la prueba, la “única actividad
optativa”, se reducen al mínimo.
123
Es en este punto donde la ética y la responsabilidad profesional debe entrar en juego.
Sabemos que entregar software defectuoso pone en riesgo de modo directo la salud, la seguridad,
los derechos, los bienes o la formación de los habitantes. La calidad del software no es negociable,
la prueba tampoco. No por dejar de probar desaparecen mágicamente los errores. Solo es cuestión
esperar a que alguien los encuentre y ver el daño que produzcan cuando aparezcan. Quizá, en
común acuerdo con el cliente, se puedan acortar algunos procesos. Incluso puden ir implementando
algunos módulos del software mientras se terminan de probar otros. Lo mejor, claro está, es que
todos tomen conciencia de que el software no está en condiciones de operar hasta que no ha sido
completamente testeado.
5. El equipo de pruebas
Casi siempre se suele hablar de que la prueba la debe realizar un equipo independiente.
Parece lógico… la prueba consiste en “destruir” el software para encontrar fallas. El programador,
que acaba de crear, con esfuerzo, una pieza de software. No parecería ser lógico pedirle que ataque
seriamente a su propia obra para obligarla a fallar. Es razonable pensar que el desarrollador buscará
su éxito y testeará la aplicación para demostrar que anda y que está bien programada, no para
buscar que falle. Difícilmente vaya a fondo para probarse a sí mismo cuantos errores cometió.
Contar con un equipo de pruebas independiente parece lógico.
No solamente se habla de independiente, sino de que el equipo debe ser externo al proyecto
y no depender del líder de este. Suena razonable. Si quien testea tiene compromiso directo con el
cronograma y con el presupuesto, se correrá el riesgo de que la prueba se ajuste al mismo para, por
ejemplo, cumplir con los plazos de entrega.
La realidad, una vez más, no es tan simple. Armar un equipo de pruebas independiente es
costoso. En los proyectos más chicos esto prácticamente es imposible y las tareas de prueba quedan
relegadas a los desarrolladores y quizá alguna persona del equipo que conozca los requerimientos
del usuario.
Los equipos externos muchas veces también son una quimera. Para que una organización
pueda mantener un equipo de testers, deben tener un flujo de varios proyectos de desarrollo
124
concurrentes que son testeados permanentemente por la unidad. Solo así pueden justificarse los
costos. Sería difícil armar un equipo externo, utilizarlo en el momento de la prueba, y luego
desactivarlo.
Queda una reflexión más: ¿Que tan bueno es que la prueba la realice sólo un equipo
externo? ¿Puede un equipo que no conoce cómo se desarrolló el software probar eficazmente el
software y encontrar todos los posibles errores? La respuesta es, definitivamente, no.
Si quienes desarrollaron el software no ayudan ni orientan a los testers, la prueba podría ser
más difícil de lo esperado. Por ejemplo, se podrían malgastar recursos en probar módulos que,
internamente, utilizan el mismo código (si funciona una para uno, funciona para el resto). Las
funciones o cálculos más complejos podrían ser testeadas con menos rigurosidad, simplemente por
no saber que son partes especialmente críticas o complejas. Incluso se podrían pasar por alto
determinados acuerdos que se dan durante el desarrollo, incluso con la aprobación del cliente, para
que determinadas cosas funcionen de un determinado modo. Mas adelante veremos que
simplemente no es posible testear todos los caminos del software, por lo que la guia y ayuda de los
programadores, incluso para confeccionar los casos de prueba, se vuelve decisiva.
6. Los casos de prueba

Es frecuente que, en empresas de desarrollo con áreas de testeo profesionales y separada
de las de programación, una vez programado el software, este quede a disposición de la mencionada
área. Esta realiza las pruebas conforme lo estipulado y o bien vuelve al área de desarrollo para
corregir los errores encontrados, o dispongan la puesta en producción. Por supuesto que este
software que se recibe ya tiene una primera tanda de testeos, que es la que realiza el área de
desarrollo para asegurarse que el software mínimamente funciona.
La pregunta que surge, entonces, es si el equipo de testeo cuenta con todas las herramientas
necesarias para “atacar a fondo” al sistema. ¿Conoce cuáles son las reglas del negocio? ¿Conoce los
requerimientos del usuario? ¿Conoce cuáles son los valores límites? ¿Puede probar funcionalidades
vinculadas, por ejemplo, con el rendimiento?
Vayamos a un ejemplo. Supongamos un sistema de reservas de mesa de un restaurante. Se

necesita que el sistema permita las reservas dentro de un rango de fechas determinada (por
ejemplo, para los siguientes 15 días) y en un horario específico, que es cuando el restaurante toma
reservas. Hasta aquí, la prueba es sencilla. Basta con seleccionar algunos valores que caigan dentro
de los parámetros de fecha y hora y probar que la reserva se confirme. Por supuesto también hay
que elegir valores fuera de rango y validar el rechazo. Pero que ocurre si, dentro de los 15 días, caen
fechas especiales, por ejemplo, feriados, donde los horarios se modifican. ¿Puede el tester tener en
cuenta esto y validarlo? Probablemente sí, pero para ello debiera conocer el negocio y los
requerimientos, a los fines de armar una prueba específica que involucre un día feriado.
Y acá es donde cobran importancia los casos de prueba. Wikipedia los define como “un
conjunto de condiciones o variables bajo las cuales se determinará si una aplicación, un sistema de
software o una característica o comportamiento de estos resulta o no aceptable.”
125
Es decir que, cuando dispone que el software vaya a ser testeado, este debe ir acompañado
de una serie de indicaciones sobre diferentes escenarios que deben ser probados y cuáles son las
condiciones de aceptabilidad de cada caso. Volviendo al ejemplo, se deberá testear un rango de
fechas que contenga al menos un feriado, verificando que los horarios de la víspera son los que rigen
para un día sábado, y los horarios del día feriado serán los del día domingo. Recibida esta instrucción,
quien realiza el testeo sabe que tiene que verificar esta condición.
Otro ejemplo que complemente lo dicho puede vincularse al sistema de inscripciones de una
facultad. Cuando hay algún cambio de plan, o de correlatividades, estos cambios a veces afectan a
un grupo especifico de alumnos (los de una determinada carrera o los que ingresaron a partir de tal
fecha). En este caso es necesario que los casos que se incluyen en la prueba sean alumnos del grupo
especifico. El resto del sistema se supone, no sufrió modificaciones y por lo tanto no requiere un
nuevo testeo. Obviamente de esto último hay que estar seguro.
También se pueden incluir sets de datos puntuales a probar, por ejemplo, testear solamente
los documentos superiores a 90 millones, o los cuits comenzados en 30. Incluso pueden existir
instrucciones específicas, como podría ser que la pantalla de carga de datos del usuario deba ser
testeada tanto en equipos de escritorio como móviles. O que este módulo debe ser probado en tal
horario, de modo de validarlo en los momentos de máxima carga del servidor.
En resumen, el “ataque” al sistema no debe hacerse en forma azarosa o simplemente

confiando en la pericia de quien testea, sino que se deben armar una prueba y un ser de datos que
contemple la mayor cantidad de casos reales posibles, y cuáles son los resultados que se esperan
de cada una de ellas.
Y por supuesto, las pruebas son un componente más del proceso de aseguramiento de la calidad
de software, y por lo tanto debemos asegurarnos de que se hicieron correctamente. Son necesarios
controles y auditorias sobre el proceso de prueba, de modo de validar que todas las pruebas
previstas se han realizado, y que los resultados son los esperados.
7. Los tipos de prueba

Como se sabe, el software se va construyendo por partes. Incluso partes que se programan
por separado, a veces por distintos equipos, y luego se integran. Esto dispara dos conceptos. 1) No
es necesario esperar a tener el software terminado para comenzar a probarlo y 2) No se puede
utilizar la misma estrategia para probar una sección de código que acaba de programarse y que, por
ejemplo, todavía no tiene, una interfaz de usuario, que cuando se prueba la aplicación ya terminada.
A veces se requiere construir algún modulo especial para probar otros.
Es por eso que existen varios tipos de prueba. Algunas son pensadas para que las realice el
programador, ni bien termina de codificar un módulo. Otras, por ejemplo, están destinadas al
equipo de testeo. Excede el propósito de este trabajo explicar cómo funciona cada una de las
pruebas que se le realizan al software, pero si resumir los tipos de prueba que menciona Ian
Somerville en su libro “Ingeniería de Software”, a modo de tener una visión general del tema:
126
• Pruebas de desarrollo:
Se realizan en la misma etapa de codificación, habitualmente por el programador cuando
acaba su desarrollo. Buscan encontrar errores en diferentes módulos de la aplicación, en su
integración con otros módulos y en su funcionamiento dentro de un sistema.
Dentro de estas pruebas encontramos:
o Pruebas de Unidad: Se ponen a prueba unidades de programa, módulos o clases de

objetos individuales. En este momento se prueban:
▪ Todas las operaciones asociadas con el módulo y todos los caminos lógicos
que tiene. Una instrucción que pregunte si el “precio > 0” dispara 3 caminos
lógicos: Qué pasa si el precio es negativo, qué pasa si es mayor que cero y que
pasa si es cero. Hay que probar que ocurre en cada caso. Generalmente es
necesario tener acceso al código o a las especificaciones para determinar las
rutas a probar.
▪ Los mensajes de alerta de error que tiene el sistema para prevenir fallas. Para
eso es necesario elegir entradas que fuercen al sistema a activar todas las
validaciones, de modo de ver que advertencias se generan en cada caso (Por
ejemplo, números muy grandes o email sin @). Por supuesto más grave es el
caso de que un error no sea controlado y que el sistema falle y deje de
funcionar (por ejemplo, ante una división por cero)
▪ Como responde el módulo ante resultados de cálculo demasiado largos o

pequeño, o que den números negativos o cero. Tambien es necesario
comprobar los redondeos, ya que 2 números con podrían parecer ser iguales,
pero operar como distintos si se comprueban varios decimales (5.14 y 5.14
son iguales a 2 decimales, pero la comparación aritmética tratarlos como
distintos si fueran 5.14283 y 5.14284)
▪ Que los diferentes ciclos se ejecuten la cantidad exacta de veces y que todos
tengan una salida (es decir que el sistema no entre en un loop infinito)
o Pruebas de componentes: Las unidades individuales ya probadas se integran para

crear componentes compuestos, enfocándose en probar las interfases entre ellos. En
este caso se busca:
▪ Probar el correcto pase de parámetros entre dos módulos, sus tipos de datos
y qué pasa si falta un parámetro o tiene valor nulo.
▪ Verificar el correcto encapsulamiento de datos, es decir que módulos

externos no pueda acceder ni modificar los datos internos.
▪ Controlar los tiempos de actualización en sistemas multitarea, para asegurar

el acceso a la información más actualizada. Por ejemplo, si se actualiza un
precio o se carga un nuevo cliente, estos cambios deben estar
inmediatamente reflejados y disponibles en el módulo de facturación.
127
▪ Verificar los mensajes de error y recuperación cuando un componente no está
disponible (Si un módulo no puede ser accedido por algún motivo, por
ejemplo, porque puede estar siendo utilizado por otro módulo, el sistema no
debe “colgarse” sino decir que intente más tarde)
o Pruebas del sistema: Algunos o todos los componentes del software se integran y el
sistema se prueba como un todo, probando la interacción general. En este caso será
necesario:
▪ Verificar la integración de nuevos componentes que acaban de desarrollar (o

se adquieran de terceros) con los demás componentes que ya existan en él
sistema.
▪ Probar la integración de componentes desarrollados por equipos de trabajo

distintos.
▪ Controlar que todos los accesos del menú estén disponibles y que todas las
funcionalidades del sistema sean accesibles.
• Pruebas de versión:
En estas pruebas ya se testea el sistema completo, comprobando que responda a los
requerimientos del usuario y al rendimiento esperado.
o Pruebas basadas en requerimientos: Para cada requerimiento del usuario se diseña

una prueba específica para probarlo y asegurar que este requerimiento se cumpla.
o Pruebas de escenario: En el caso que los requerimientos se hayan expresado como

escenarios o casos de uso, las pruebas se basan en las descripciones que contiene
aquel escenario, por lo general, probando varios requisitos a la vez.
o Pruebas de rendimiento: Deben diseñarse pruebas para forzar el sistema y garantizar

que procese la carga pretendida. Las pruebas de esfuerzo son particularmente
relevantes para los sistemas más grandes, con múltiples usuarios y que puedan
saturar la red o los servidores.
• Pruebas de usuario:
servirán para que este apruebe el software para su liberación y puesta en marcha:
o Pruebas alfa: Los usuarios del software trabajan con el equipo de diseño para probar
el software en el entorno del desarrollador.
128
o Pruebas beta: Una versión del software se pone a disposición de los usuarios, para
que, en su propio entorno, puedan experimentar y descubrir problemas 30
o Pruebas de aceptación: Los clientes prueban un sistema para decidir si está o no listo
para ser liberado al entorno de operación. Deben definirse de antemano en el
contrato cuales son los criterios de aceptación y negociarse como se continua a partir
del resultado. Este tipo de pruebas son especialmente utilizadas en modelos ágiles
de desarrollo.
Es importante refrescar el concepto de que la prueba busca encontrar errores. Y este

concepto lo deben tener también los programadores y los usuarios que participen de la etapa de
pruebas. El usuario no se debe limitar a probar que el sistema funciona para un uso normal, sino
que debe forzar al mismo con operaciones extremas y no tan habituales, asegurando que el
software responderá aun en dichos escenarios.
8. ¿Caja blanca o caja negra?

Muchos autores dividen las pruebas en aquellas que son de caja blanca, mirando el código,
o caja negra, operando el sistema. Lo primero que vale decir es que dicha división no es precisa: La
mayoría de las pruebas de software pueden combinar ambas estrategias.
Las pruebas de caja blanca analizan el código para probar procedimientos y caminos lógicos:
• Buscan recorrer todos los caminos lógicos al menos una vez.

• Controlan las estructuras de decisión, tanto el verdadero como el falso.
• Revisar el funcionamiento y la salida de bucles.
• Analizan estructura de datos.
Las pruebas de caja negra, por el contrario, se realizan operando el sistema, utilizando la
interfaz del usuario:
• Buscan funciones erróneas o faltantes.

• Detectan errores en la interfaz, por ejemplo, campos cortados o colores poco visibles.
• Aseguran que la base de datos o componentes externos sean accesibles.
• Revisan el comportamiento y rendimiento.
Como se ve, ambas estrategias se orientan a buscar diferentes problemas. Hay cosas que de
detectarán solo con caja negra y otras que no aparecen salvo que uno mire el código. Si en una
pantalla falta un botón para imprimir, es algo que difícilmente se note si no se visualiza esa pantalla
(caja negra). Encontrar una rutina que haga algo que no debe, por ejemplo, desviar centavos de una
operación a una cuenta particular, es algo casi imposible de detectar si no se inspecciona el código.
30
Es habitual encontrar en internet versiones Beta de un software. Estas versiones son justamente aquellas
destinadas a los usuarios que harán de testers. No deben ser nunca utilizados como versiones finales ya pueden tener
errores o funciones no terminadas.
129
Ambas estrategias son, entonces, necesarias y complementarias. Un sistema, obviamente,
no puede ser probado si no se lo ejecuta. Pero, también, hay que desconfiar de aquellas aplicaciones
que solo han sido testeados sin revisar en ningún momento el código fuente que dio origen al
sistema.
9. ¿Cuándo termina la prueba?
Podríamos encontrarnos con un software que responda al siguiente diagrama… con

decisiones que disparan diferentes acciones dentro de un ciclo que se repite 20 veces.
Aunque a simple vista no lo parezca, al ejecutar este módulo la computadora puede optar
por 1.000.000.000.000.000 de posibles caminos. Aun si recorriéramos con ayuda de un computador
un cada camino en un segundo, nos llevaría 3000 años probarlos todos. Esto nos lleva a afirmar que
es humanamente imposible probar todas las opciones de recorrido que puede tener un software. Y
entonces aparece un dilema entre seguir buscando errores y entregar el sistema:
Si…
Es imposible probar todas y cada una de las posibilidades lógicas
de un software…
El éxito de la prueba es encontrar errores, pero esto no garantiza
que se encuentren todos ello…
Es riesgoso, incluso mortal, encontrar software que contenga
errores…
Entonces…
¿Cuándo estamos en condiciones de terminar la etapa de pruebas
y entregar el software?
130
En visión extremista, nunca. Siempre tenemos la chande de seguir probando hasta que
aparezca el próximo error. Pero claro… el peor software es el no entregado, ya nos priva de todos
los beneficios de usarlo.
Por supuesto que dependerá mucho del tipo de software que se está construyendo. No da
lo mismo un software para manejar vehículos autónomos, un sistema bancario o el software para
registrar las ventas de un pequeño negocio. El impacto de un error encontrado a tiempo no será el
mismo en un caso que otro.
Algunos de los criterios, aunque no los únicos, que podemos considerar para decidir
entregar el sistema son:
• Cuando ya no sea razonable buscando errores. Todas las pruebas deben tener criterios de
finalización, porque la búsqueda puede ser eterna.
• Cuando el costo de encontrar el próximo error sea mayor que el beneficio de encontrarlo.
Por supuesto el costo en vidas siempre es infinito. Pero, en si un sistema de facturación debo
esperar 5 días y gastar miles de pesos para tener chance de encontrar el próximo error que,
si aparece, tendría un impacto de centavos, entonces no tiene sentido buscarlo.
• Cuando el beneficio de lanzar un sistema, aun con algún posible error, sea mayor que el
perjuicio de no hacerlo. Por ejemplo, si necesitamos abrir un negocio en un día determinado,
es peor seguir buscando fallas que abrir el negocio.
• Cuando el sistema por entregar sea mejor o tenga menos problemas y errores que la
aplicación que hoy está usándose.
Si bien los criterios de aceptación de cada caso son definidos de antemano y acordados con
todas las partes interesadas, usuario incluido, también hay que considerar la posibilidad de variar
criterios en función de cómo avance el testeo. Por ejemplo, podría ocurrir que en las primeras
pruebas se detecten más errores que los previstos y esto nos lleve a reformular o profundizar la
etapa.
10. La depuración o debugging

La depuración del software es una de las consecuencias del proceso de prueba: Los errores
detectados deben corregirse. Durante la depuración debe localizarse el origen del error, corregirlo,
volver a probar el software y ponerlo nuevamente a disposición de los usuarios.
Esta es una tarea compleja. Puede pasar que el reporte del error sea confuso o incompleto,
o que no describa adecuadamente la situación en la que se produce. A veces, el problema aparece
en el equipo del usuario, pero es difícil de reproducir en el entorno de desarrollo. Otras veces, el
origen de este está en otro módulo diferente. Incluso puede originarse en causas externas como el
hardware o el sistema operativo. En ocasiones el error puede intermitente o aparecer solo ante
algunos eventos puntuales, como puede ser un micro corte de red.
131
Existen algunas técnicas que ayudan a la depuración:
1. Fuerza bruta: La corrección se da por prueba y error. Se prueban casos y soluciones

reiteradamente hasta que se encuentra la correcta. Por supuesto es una técnica que no es
eficiente, pero, ocasionalmente, la única que funciona.
2. Vuelta atrás: Se detienen el programa en algún punto y desde allí se comienza a desandar
manualmente el camino, hasta encontrar al error. En determinados puntos del sistema esto
es complejo porque los caminos a recorrer pueden ser múltiples.
3. Eliminación de causas: Se van eliminando del código posibles causas de error, buscando de
este modo aislarlo. Por ejemplo, un cálculo complejo se puede dividir y eliminar
temporalmente partes de este, hasta encontrar aquella que cause el error.
Los IDE, entornos integrados de desarrollo, proveen a los programadores de múltiples

herramientas que facilitan la detección y corrección de errores. Entre ellas podemos mencionar:
• Correctores automáticos de código que señalan, por ejemplo, con códigos de colores,
estructuras incompletas, paréntesis faltantes, funciones inexistentes, errores de sintaxis,
etc. (algo similar al corrector ortográfico de Word)
• Puntos de break: permiten detener la ejecución de un programa en un punto exacto, por

ejemplo, justo cuando de aprieta un botón, pero antes de que se ejecute el código asociado.
En ese momento el programador puede ver el valor que en ese momento tienen las variables
del sistema.
• Ejecución paso a paso (Trace). Atado a lo anterior, una vez detenido el programa en un
punto, el mismo puede continuar línea a línea en forma manual. De este modo el
programador puede avanzar e ir chequeando cómo se comporta el sistema desde el último
punto seguro.
En líneas generales, el proceso de depuración termina siendo un nuevo mini proceso de

desarrollo que pasa por etapas similares que el desarrollo original:
Una vez reportado el error debe localizarse, diseñar una solucion, codificarla y, una vez
construida la nueva versión, será momento de una la prrueba antes de volver a poner el software
en funcionamiento. Al hacerlo es importante considerar que otros módulos del sistema podrían ser
modificados a partir de las nuevos cambios.
132
11. Consideración final
Dentro de un programa, hay funciones que se repiten. Por ejemplo, la validación del número
de CUIT podría estar presente en 4 ó 5 pantallas de carga. Si bien las buenas prácticas de
programación señalan que en estos casos debe construirse un módulo reutilizable que se invoque
cada vez que necesite, esto no siempre pasa. Hay veces que no se requieren exactamente las
mismas funcionalidades y termina siendo frecuente que algunas líneas de código copien y se usen
como base en algún otro lado.
Esto abre dos escenarios. Si el error detectado está en un módulo reutilizable, la solución
aplicada a ese módulo obviamente corrige los problemas en cualquier lado donde se utilice. Si en
cambio el problema está en una parte del código que fue copiada y utilizada en otra parte del
sistema, en este caso el error podría replicarse. Es por eso que, cuando encontramos un error,
deberíamos hacernos las siguientes preguntas: ¿Se repite la causa del error en otra parte del
sistema? ¿Qué error podría presentarse con la corrección?
Finalmente, y buscando siempre la mejora continua de los procesos, también nos

deberíamos preguntar si el error no podría haberse prevenido, y si hubo alguna circunstancia que
llevó a cometerlo y a no detectarlo, de modo de evitarse a futuro.
133
12. Bibliografía
134
8
Apunte 8

Despliegue de Software
135
1. Introducción
El primer objetivo a la hora de desarrollar software es tener un programa testeado y listo

para poder operar. Sin embargo, lejos de ser el final, este es solo un primer logro. A continuación,
este software debe ser desplegado; es decir, debe ser puesto en operación real. Y este no es un
tema menor Se debe considerar un nuevo entorno de hardware (el de la empresa); la capacitación
de los usuarios que deban operarlo; los datos anteriores que requieran migrarse; la interacción con
otros sistemas de la organización; e incluso con la resistencia al cambio de los involucrados.
Aunque parezca natural que un software que se utilice, la verdad es que hay muchos casos
donde esto no sucede. Hay desarrollos excelentes que fallan por el modo en el que son
implementados. Otros que son geniales pero los usuarios no quieren usarlo porque son complejos
o les generan mucho mas trabajo que la operatoria manual. Incluso hay casos donde se demora
tanto en construir que, para cuando esta listo, ya no tiene sentido usarlo o la competencia saco uno
mejor (o Google lo incorpora a su plataforma como servicio gratuito). Todas estas cosas hay que
preverlas de antemano, en especial trabajar cobre la resistencia al cambio y a tener que aprender
una nueva herramienta.
El “Pase a Producción” como muchas organizaciones lo denominan, implica atender muchas

más cosas que la de simplemente que mover el software del entorno de desarrollo al productivo.
Este apunte busca reflexionar sobre alguna de ellas.
2. Construir la versión final
Lo que genéricamente se denomina software listo para entregar es, en realidad, un conjunto
de cosas. Entre ellas encontramos:
• El o los programas ejecutables propiamente dichos.
• Los archivos auxiliares que el sistema utilice: librerías internas y externas, imágenes, videos,
archivos de idiomas, plantillas, etc.
• La base de datos, con tablas que pueden contener datos precargados (ej. tabla de países o
provincias o tabla de parámetros), y otras vacías que almacenarán los datos del sistema. En
caso de que la base de datos deba montarse sobre un gestor de base de datos ya operativo,
habrá que dar todas las indicaciones y detalles para que el administrador de la base de datos
pueda hacerlo.
• Los archivos de configuración que sirvan para personalizar el sistema.
• El detalle de requerimientos técnicos de hardware, tanto del servidor como de las

estaciones de trabajo y redes, incluyendo las versiones de sistema operativo y todo aquel
software que debe estar instalado. En caso de ser necesario, deberá detallarse también las
actualizaciones y los parches de seguridad que se necesitan.
• Los manuales técnicos, que indiquen cómo instalar el software y la base de datos y los
permisos que deban asignarse.
136
• Los manuales e instrucciones de uso para quienes deban operar el sistema. En nuestros días,
lo usual es que estos manuales sean digitales y estén embebidos en el sistema (F1: Ayuda) o
estén disponibles en línea, lo que permite que puedan ser actualizados ante los cambios que
tenga el software.
• Las certificaciones y aprobaciones que correspondan. (Ej. certificación de la FAA para

software de aviones).
• Copia de los demás documentos que se originaron durante el proceso de desarrollo del
software y que sirvan para documentar el proyecto.
Cada una de estas herramientas tiene destinatarios específicos. El ejecutable, por poner un
ejemplo, deberá se instalado en alguno de los servidores de la empresa; los requerimientos técnicos
serán analizados por quién ser encargue de infraestructura; los manuales tendrán que estar a
disposición de cada interesado.
Es importante asegurar que cada usuario que accederá el sistema tenga los permisos
suficientes para acceder al servidor, incluyendo la posibilidad actualizar archivos. Estos permisos
son de acceso genérico y complementarios a los más granulares que la aplicación le otorgue. Un
usuario puede, por ejemplo, tener acceso a modificar datos, pero tener vedado emitir determinados
listados. Esos permisos los maneja la propia aplicación, pero previamente debe tener acceso al
servidor para poder ejecutar el sistema.
Si el software debe interactuar con otras aplicaciones de la organización, por ejemplo

aplicativos de la AFIP, se deberán indicar los modos de realizar dichas conexiones y los usuarios y
permisos a utilizar en cada caso.
Una vez instalado el sistema también habrá que establecer cuáles serán los protocolos para
las actualizaciones. Habrá que definir si es posible que estas se realicen en forma remota y en qué
horarios podrán hacerse estos cambios, de modo de no afectar la disponibilidad del sistema en
momentos en los que este operativo el negocio. También habrá que ver de qué forma se harán
cambios a bases de datos cuando, por ejemplo, sea necesario agregar un campo o cambiar atributos;
cosa que por supuesto debe hacerse sin afectar la integridad de los datos ya cargados. Incluso habrá
que prever la contingencia de que la nueva versión tenga algún problema no detectado previamente
y que deba volverse a la versión anterior de la aplicación o de la base de datos. Hoy día, la mayoría
de los sistemas cuentan con procesos de actualizaciones automáticas, como Windows, tienen
incluidos los procesos de actualización, de modo que el usuario simplemente actualice
En concordancia con lo dicho, un punto muy importante que se deberá documentar será el
modo de hacer un backup completo de la aplicación, qué archivos deben resguardarse, dónde están
ubicados y qué archivos externos son necesarios preservar. Habrá que proporcionar indicaciones
detalladas de cómo restaurar la aplicación desde cero junto con los datos de la última sesión válida,
en el hipotético caso de que, por ejemplo, sea necesario formatear algún equipo.
Hoy día, la mayoría de los sistemas cuentan con procesos de actualizaciones automáticas. El
usuario solo debe autorizar la actualización y el propio sistema se ocupa de realizar todo el proceso.
De igual modo, tambien tienen incluidos opciones de backup (y de recupero), que funcionan de
modo automático. Se puede seleccionar la periodicidad; que sean completos o incrementales (es
137
decir que solo se haga copia de los cambios diarios); elegir la nube como destino de las copias o que
estas estén cifradas, como ocurre con Whatsapp. De más está decir que todo esto no ocurre solo, y
que son funcionalidades del sistema que deben diseñarse y programarse.
Por supuesto que cuando la instalación es complicada y requiere configuraciones muy

específicas, es deseable que el equipo de desarrollo colabore con los administradores de servidores
y bases de datos para lograr una implementación exitosa.
Todos los procesos anteriormente descriptos son fundamentales para asegurar una puesta
en marcha exitosa y, por lo tanto, será importante prever una revisión o auditoría para asegurar que
cada uno de los requerimientos de instalación han sido respetados. Por ejemplo, habrá que testear
que en efecto los usuarios tengan todos los permisos que necesitan o que el hardware de las
estaciones de trabajo cumple con las especificaciones. Del resultado de esta auditoría, además de
asegurar el correcto funcionamiento del sistema, pueden surgir cambios en el proceso de instalación
para las próximas versiones o para otros sistemas que se desarrollen.
3. El manejo de múltiples versiones
Es frecuente que los desarrolladores majen simultáneamente más de una versión del mismo
software. Puede haber, por ejemplo, versiones para diferentes sistemas operativos o idiomas.
También pueden existir personalizaciones o funcionalidades agregadas que hicieron para un cliente
o grupo de clientes específicos.
Incluso se puede estar trabajando en una actualización mayor, mientras se sigue

manteniendo y corrigiendo eventuales problemas de la versión actualmente en operación. También
puede pasar que dos programadores necesiten corregir a la vez un mismo código fuente.
Ante estas circunstancias es necesario ser muy cuidadoso a la hora de construir y distribuir
el software. Cada ejecutable debe contener sus componentes específicos y a cada cliente debe
recibir la versión que le corresponde.
Somerville define que “La gestión de versiones (VM, por las siglas de versión management)
es el proceso de hacer un seguimiento de las diferentes versiones de los componentes de software o
ítems de configuración, y los sistemas donde se usan dichos componentes. También incluye asegurar
que los cambios hechos a dichas versiones por los diferentes desarrolladores no interfieran unos con
otros. Por lo tanto, se puede considerar a la gestión de versiones como el proceso de administrar
líneas de código y líneas base31”
El siguiente gráfico muestra como diferentes componentes se integran en distintas

versiones. Podemos pensarlo como que existen 2 versiones del sistema, una en español y en otra
en inglés. Habrá componentes genéricos que forman parte de ambas versiones y otros específicos:
31
El concepto de línea base hace referencia a una porción de código que ya ha sido testeada y aprobada y que no
permite modificaciones, con el objeto de que no se introduzcan cambios que dañen partes vitales del sistema o que
funcionan.
138
Es decir, si se necesita actualizar un componente, por ejemplo, el A, solamente para aquellos
clientes que posean la versión en español, esta actualización generará el subcomponente A1.3. A la
hora de compilar la nueva versión en español, se utiliza dicho componente. La versión en inglés del
software, por el motivo que fuera, seguirá utilizando la versión A original del componente. Es decir
que los nuevos cambios realizados no afectarán a los clientes que estén utilizando la versión inglesa
y por lo tanto no hay necesidad de actualizarse.
Obviamente, si se modifica la librería L1, los cambios afectarán a ambas versiones porque es
un componente compartido por las dos.
Si bien esto presupone complicaciones y una alta posibilidad de equivocar versiones y

componentes, es posible utilizar software de gestión de versiones. Estos operan como grandes
repositorios, donde se almacenan los componentes individuales y luego permiten generar, de modo
automático, la compilación de archivos necesaria para cada cliente o versión específica. Estos
sistemas también cuentan con la posibilidad de generar instaladores automatizados que le
simplifican a los administradores de los sistemas de la empresa la tarea de copiar cada componente
en el lugar en el que deba estar.
De este modo se prepara la versión final para la entrega (o reléase). Una entrega (release)
de sistema es una versión del software que se distribuye a los clientes. Habitualmente estas
versiones se identifican con números o nombres para poder identificarlas fácilmente. Para software
de mercado masivo es posible identificar por lo general dos tipos de entregas: Release Mayor, que
proporciona por lo general funcionalidades significativamente nuevas, y Release Menor, que repara
bugs y corrige problemas reportados.
Una costumbre arraigada, aunque no obligatoria, es la de identificar los reléase mayores con
un número y los menores con fracciones de este: Ej. Windows 10 versión 1909. Firefox 80.0.1, Word
139
16.0.12527.2098632. Android solía utilizar nombres de postres, los que se ordenaban
alfabéticamente, para reemplazar los números de sus versiones mayores. Android 8 era conocido
como Oreo, Android 9 era Pie. Estos nombres y códigos de versión pueden ser internos de la
empresa que los desarrolla o trascender a los clientes.
La correcta identificación de versiones se vuelve central a la hora de las actualizaciones

automáticas. Por ejemplo, será posible lanzar una actualización de Windows que solo sea aplicada
a las versiones 1909, sin que afecte a otras versiones.
También es posible obligar a que todos los clientes actualicen las versiones consideradas
obsoletas para seguir actualizando el software. Incluso el soporte técnico o las actualizaciones
pueden finalizar para determinadas versiones o dejar de funcionar en determinado hardware: Ej.
Windows 7 finalizó su suporte en enero de 2020, IOs 12 ya no funciona en Iphone 4 o Whatsapp no
puede instalarse en Android 2.3 o IOs 8, o versiones anteriores.
4. La capacitación de usuarios
Por mejor que sea un sistema, por probado que esté, por más sólido que sea, puede fallar si
el usuario no sabe usarlo, o si lo utiliza incorrectamente. De nada sirve hacer un sistema integral,
con decenas de buenas funcionalidades si el usuario no las conoce o usa apenas las básicas.
La primera indicación que suele darse en estos casos es que todo software debe
acompañarse de sus respectivos manuales de operación. Pero nada más alejado de la realidad si se
quiere lograr capacitar eficazmente a usuarios reales.
Una ley no escrita dice que “cuanto más extensos y completos sean los manuales de usuario,
menos gente los leerá”. Una segunda ley, tampoco escrita, establece que “cuanto mayor sean las
actualizaciones que reciban los sistemas, menor será la actualización los manuales de uso”. No solo
nadie los lee, sino que estos quedan obsoletos en la primera actualización.
Por supuesto, los manuales de uso deben existir, pero deben ser pensados más como una
herramienta de consulta y referencia que como una herramienta de capacitación. Son pocos los
usuarios que aprenden a usar un sistema leyendo sus manuales.
No existen manuales de Facebook, ni de Instagram, ni de los home-banking. Mejor dicho, en

realidad si existen, pero casi nadie los leyó. Sin embargo, los millones de usuarios usan a diario esos
sistemas.
Las ayudas en línea, los chatbot (asistentes virtuales) y los videos explicativos (siempre que
sean cortos y específicos) suelen tener mayor aceptación que los documentos de texto.
Eventualmente se podrán prever reuniones de capacitación presenciales o virtuales. En estos casos
siempre hay que recordar que el usuario debe atender sus propias obligaciones y los tiempos para
32
En algunos casos, como Windows, el número de versión hace referencia al mes y año en el que se lanzó la
actualización. En otros casos, como el Word o Firefox, con códigos que dan al desarrollador una mayor información
respecto a que componentes contiene o que errores se han corregido.
140
capacitaciones intensivas no abundan. En ocasiones también será útil instalar entornos de prueba y
capacitación en cuales el usuario podrá entrenarse y “jugar” libremente con el software, en sus
propios timpos, y sin el temor de afectar la operatoria real.
Debemos tratar de construir software que, por su simpleza y su similitud con el mundo real
y la operación manual, no requiera grandes conocimientos para operarlo. Debemos minimizar la
posibilidad de ingresar datos erróneos. Podemos usar la propia pantalla para indicarle al usuario
qué es lo que está haciendo bien o mal (mostrándole un cartel que el precio ingresado es incorrecto,
o que falta completar algún campo o poniendo en verde los datos sin errores) o cuál es la siguiente
operación que se espera que realice (ej. revise su casilla, debió haber recibido un mail de
confirmación de los datos ingresados). La mejor capacitación se da cuando el usuario usa realmente
el sistema. Analizar qué es lo que hace el usuario, impedirle hacer cosas incorrectas y asistirlo en la
propia pantalla es un método muy efectivo de entrenamiento.
Del mismo modo se puede utilizar el mismo sistema para informarle al usuario de nuevas
funcionalidades; por ejemplo, resaltando de forma especial un nuevo botón, o generándole una
alerta que le indique que se ha incorporado una nueva funcionalidad o un nuevo listado.
5. Fechas de implementación
Por lo general la fecha en la que se implementa el software viene dada por el cliente o por
condiciones externas. Por ejemplo, puede necesitar tener lista la aplicación antes de comenzar con
determinada campaña de venta; la apertura de una sucursal; el lanzamiento de un nuevo producto
o incluso el vencimiento de la licencia de uso de la versión anterior. También puede haber plazos
determinados por normativas legales; de organismos de contralor o, incluso, imposiciones de casa
matriz.
Pero… ¿qué pasa cuando nosotros podemos elegir la fecha? ¿Da lo mismo hacerlo en
cualquier momento del año? ¿Cuál es la mejor fecha para elegir?
Obviamente la primera y más obvia respuesta es que la mejor fecha para entregar un
software cuando esté terminado y lo suficientemente probado. Más allá de esta obviedad, no todas
las fechas son iguales. Por supuesto que cada tipo organización y cada tipo de sistema van a
condicionar cuáles son los mejores momentos para implementar software. Aquí van algunas
consideraciones:
• Primer día hábil del año: Año nuevo vida nueva dice el refrán. Por qué no empezar
también estrenando sistema. Muchas organizaciones suelen elegir esta fecha para
implementar el software y es porque existen dos importantes ventajas. La primera
es que la mayoría de las empresas cierra su ejercicio comercial en esa fecha, realiza
inventarios, pone todo en orden y arranca con sus cuentas en cero. La segunda es
que suele ser un mes donde hay menos movimiento comercial y por lo tanto habrá
más tiempo para la capacitación y para corregir eventuales errores.
Pero claro, también enero suele ser un mes de vacaciones del personal de la empresa.
Los operadores habituales pueden no estar trabajando e incluso se complica la
capacitación ya que hay que realizara en tandas. El personal técnico, tanto de la
141
empresa usuaria como de la desarrolladora, también pueden estar de licencia y ser
más difícil atender y corregir cualquier problema que surja.
• Aprovechar los cierres de ciclo o ejercicio: Enero es mes de vacaciones, pero más allá
de eso, cualquier inicio de ciclo es un excelente momento para comenzar a utilizar
un software. Todos los sistemas procesan datos acumulados y no da lo mismo poder
arrancar con las cuentas en cero que tener que migrar operaciones anteriores.
Cualquier comienzo de mes puede ser preferible a hacerlo en la mitad ya que, por
ejemplo, datos impositivos como el IVA, tienen cortes mensuales.
• Aprovechar los momentos de menor operatoria: Buena parte de las empresas tienen
operatoria estacional. Diciembre suele ser un mes muy complejo, con muchos
feriados y muchas operaciones por las fiestas. No parecería ser el mejor para
implementar sistemas. Sin embargo, a veces hay que hacerlo por cuestiones
presupuestarias (si no se paga en diciembre la erogación impactante contra el
presupuesto del año siguiente). Enero, como se dijo, suele ser tranquilo, salvo para
empresas vinculadas al turismo. En fin, hay que conocer cuáles son los ciclos de la
organización y procurar que la implementación sea en los momentos más favorables.
• Los viernes: Esta expresión no hay que considerarla tan literal, sino significando que
puede ser conveniente implementar un sistema teniendo un margen, aunque sea
pequeño, para solucionar algún problema que pueda presentarse. Si algo falla el
viernes puede solucionarse durante el fin de semana, minimizando el impacto.
Desde luego, el viernes debe ser evitado si la empresa opera el fin de semana y nadie
puede atender un reclamo o solucionar un problema hasta el lunes.
• Lejos de las auditorias o cierres de balance: Las empresas suelen tener auditorias
periódicas, controles externos y obligaciones de presentar balances o información a
organismos de contralor. Estas operaciones suelen requerir preparar información
especial y, ocasionalmente, generan trabajo extra. Suelen ser momentos de tensión
en las organizaciones. No parece buena idea sumar en ese período la implementación
de un nuevo software.
Salvo que el nuevo sistema provea funcionalidades específicas o información
pertinente para la auditoria (por ejemplo, que emita nuevos listados con la
información exacta que requiera el organismo auditor), es preferible que los sistemas
se implementen lo más lejos posible de las mencionadas situaciones.
• Considerar los tiempos y rutinas de los usuarios: Ya se comentó que las

organizaciones tienen ciclos y obligaciones puntuales en momentos específicos. Lo
mismo ocurre con los usuarios. Hay áreas que hacia fin de año tienen picos de
trabajo, otras hacia fin de mes, algunas que están enfrentando procesos de cambio
o rotación del personal, jefes recién llegados… Cada área tiene su mejor momento
para atender las nuevas tareas y obligaciones que les impondrá la implementación.
Es importante el diálogo y la coordinación con los usuarios y negociar, dentro de lo
posible, cuáles son los mejores momentos para los cambios.
• Mantener ciclos de entrega: En metodologías ágiles, donde las implementaciones

son constantes, es importante que los ciclos de implementación (sprints) se
mantengan fijos, para que el usuario sepa cuáles son las semanas en las que habrá
142
nuevas versiones. En los casos de que sea necesario un cambio en la rutina habitual
será necesario una nueva coordinación. Por ejemplo, si se realizan sprints de 2
semanas, las actualizaciones pueden caer en la semana 1 y 3. Si por algún motivo,
como puede ser una semana de confinamiento o de feriados, esos ciclos se corren
para la semana 2 y 4, podrían coincidir con cierre mensual y, por lo tanto, ser mal
momento para cambios nuevas versiones.
• Con la mayor anticipación posible: Como se dijo, a veces las fechas son fijas. Siempre
hay que considerar que los sistemas, por mejor testeados que estén, pueden tener
fallas en el momento de implementación. Esto no solo es por errores que pueda tener
el software, sino también por fallas humanas de quienes los operan. Un cajero
bancario no va a poder operar con la soltura habitual el día que, por primera vez,
deba usar un nuevo sistema de caja. Hay que considerar pues esta curva de errores
y aprendizaje. Procurar que el software esté disponible para operar cierto tiempo
antes de la fecha clave, para tener tiempo de entrenar, de solucionar algún problema
y que cuando llegue el día, la operatoria sea lo más normal posible.
• Según el calendario. Determinadas industrias, como por ejemplo el desarrollo de

video juegos, tienen momentos específicos del año donde las ventas de su software
se disparan. Una de ellas, por ejemplo, son las navidades en EE.UU. No contar con la
nueva versión del juego, o sacar al mercado un nuevo título después de esa fecha,
puede ocasionar pérdidas millonarias por usuarios que no lo comprarán como regalo
para esas fechas especiales.
• Antes que mis competidores. Cuando se desarrolla software genérico, es decir que
no es a medida de una organización determinada, debo procurar estar a la
vanguardia respecto de otros programas similares que haya en el mercado. Por
ejemplo, si la AFIP obliga a la emisión de factura electrónica, contar prematuramente
con un software que sirva para dicha emisión, supone fidelización y la posibilidad de
atraer nuevos clientes. Del mismo modo si una actualización por cambio normativo
se entrega con anticipación y sin errores, producirá beneplácito entre los clientes,
mientras que una entrega tardía generará problemas y malestar con el sistema. El
FIFA y el PES con dos ejemplos donde, la demora en actualizar versiones, pueden
hacer que los usuarios miguen a la otra plataforma.
Una ultima observación: Existen casos en los que los sistemas deben ponerse en
funcionamiento el día más crítico de todos y donde no es posible postergar la implementación.
Ejemplos de este tipo pueden ser los softwares de acceso a recitales o a partidos de futbol, donde
deben ponerse en funcionamiento para ese día sí o sí. Si bien se espera que hayan sido texteados,
es imposible, a veces, emular las reales condiciones de operación, con miles de usuarios queriendo
comprar su entrada o tratando de validar el acceso desde su celular, usando redes que,
necesariamente, se congestionan. Acá las alternativas son pocas. No se pude pedirle a la gente que
no entre toda al mismo día o que vaya ingresando por tandas en horarios diferentes. Mas allá de las
pruebas, eventualmente habrá que prever mecanismos de contingencia por si el sistema falla, ya
sea entregando entradas manuales o deshabilitando algunas funciones secundarias. La AFIP, por
ejemplo, suele modificar accesos los días de vencimiento, para que no se sature la operatoria de su
sitio Web. Lo mismo hacen los diarios ante noticias de alto impacto, liberando de su home de aquel
contenido que pude bloquear las conexiones.
143
6. Migración de datos
En toda organización hay datos que se necesitan preservar. A veces, pertenecen a un sistema
previo y deben ser incorporados al nuevo para continuar con la operatoria (por ejemplo, los saldos
actuales de las cuentas corrientes). Otras veces, esos datos solo deben quedar a disposición para
consultarse como históricos. Lo cierto es que en cada implementación se necesita resolver qué se
hará con los datos almacenados en los sistemas anteriores (o existentes en registros manuales).
Existen casos, como los software de recursos humanos, en donde se requiere tener acceso a
toda la historia del empleado, por ejemplo, para calcular antigüedades, indemnizaciones o datos del
cese laboral.
En estos casos deben proveerse mecanismos para migrar los datos del viejo formato al
nuevo. A veces estas migraciones son sencillas, una simple copia, otras hay que construir procesos
complejos. Por ejemplo, puede ser necesario dividir los datos que almacenan en un mismo campo
el nombre y apellido, si es que el nuevo sistema requiere que se guarden por separado. También es
posible que el nuevo sistema tenga campos obligatorios que no existían anteriormente, o en
formato diferente (numérico versus texto).
Es común que los sistemas prevean opciones básicas de importación de datos, que obligan
al usuario a preparar y tabular los datos existentes, por ejemplo, en Excel, respetando un formato
exigido. En otros casos se incluyen migraciones automáticas desde determinados software
estándares y conocidos. En aquellos casos que la migración es compleja, es posible que se requiera
la construcción de un software específico para realizar dicha tarea, que será complementario y
presupuestado aparte.
Pueden plantearse varias estrategias a la hora de planificar la migración de datos:
• No migrar los datos antiguos: El nuevo sistema comienza a una fecha determinada y de
ahí hacia adelante. Los datos históricos deben consultarse en la vieja aplicación. Puede
incluso construirse alguna interfase para que los usuarios puedan acceder a esos datos
sin salir del sistema actual.
• Migración de totales a una fecha: No se migra la totalidad de los datos sino totales
acumulativos, por ejemplo, saldos de inicio de cuentas contables, o total de sueldos
anuales.
• Migración parcial: Se migran todos los datos desde algún periodo determinado, por
ejemplo, del año en curso.
• Migración total: Se migra la totalidad de los datos anteriores, procesándolos para que
sean manejables por el nuevo sistema. En estos casos es importante asegurar que los
datos almacenados en el sistema anterior sean completos y pertinentes, de modo de no
incorporar “basura” al nuevo sistema.
De lo anterior se desprende que la fecha elegida para la implementación del nuevo sistema
tendrá impacto en el proceso de migración, ya que no es lo mismo comenzar a operar el 1 de enero
que a mediados o fines de año. En el primer caso, por citar un ejemplo, no será necesario tener
información detallada para el cálculo de aguinaldos, mientras que si se empieza después si será
144
necesario cargar los datos de meses anteriores. Atado a esto, está claro que los posibles atrasos en
la entrega del software pueden originar mayores costos en el proceso de migración.
7. Comenzando a operar
Una vez que el nuevo sistema ha sido correctamente instalado en los servidores y
dispositivos de los usuarios, llega el momento de comenzar efectivamente la operación real. Este
momento suele denominarse “go-live”, “salir en vivo”, “salida a producción”, “pasar a producción”
o algún término similar.
Por lo general, un nuevo sistema reemplaza a alguno que ya tiene la organización. Este podrá
ser un software o un sistema de registro manual. En cualquier caso, la operatoria ya funciona y el
nuevo sistema puede mejorarla, pero también podría causar problemas y detenerla. ¿Cómo
conviene implementar el nuevo software para minimizar los riesgos? Básicamente encontramos 3
alternativas:
• Cambio abrupto: En este caso, en una fecha determinada el actual, sistema deja de estar
operativo y se comienza a operar con el nuevo. Es la opción más arriesgada porque cualquier
problema implicará que la organización deje de funcionar o que su información contenga
errores. Si bien es la opción más arriesgada, en ocasiones es la única viable. Por ejemplo, si
se requiere implementar un hardware específico y éste solo funciona con un nuevo sistema
(molinetes de acceso, tótems de información, terminales de autoservicio, etc.). Además de
tomar recaudos extras en la etapa de testeo, requiere que los usuarios estén previamente
bien entrenados. Usualmente es posible que el sistema reemplazado pueda quedar
operativo para consultar datos históricos.
• Corrida en paralelo: Durante un período de tiempo ambos sistemas funcionan en forma

paralela. Es una opción segura, pero costosa. Requiere los usuarios deban atender y carguen
datos en forma simultánea en los dos sistemas. Ocasionalmente, debe contarse con
hardware; espacio físico o personal adicional para que a la vez se puedan realizar la doble
operatoria. Es una opción válida, por ejemplo, para sistemas de sueldos, donde puede
hacerse una liquidación en cada aplicativo y comparar que en ambos lleguen al mismo
resultado. Pero claro, sería inviable en sistemas masivos de facturación en mostrador.
• Implementación por módulos: En sistemas modulares es posible que los mismos se vayan
implantando en etapas sucesivas. Por ejemplo, podría implementarse primero la facturación
en mostrador, luego el módulo de presupuestos, el de cuenta corriente, etc. Este tipo de
implementación minimiza los riesgos y facilita la capacitación, aunque la empresa debe
mantener activos dos sistemas y algunos usuarios tendrán que operar simultáneamente en
2 plataformas diferentes. Es el tipo de implementación que se utiliza en desarrollo ágil donde
las funcionalidades se van agregando de modo incremental y constante. Como
contrapartida, no todos los sistemas se pueden implementar de este modo. Por ejemplo, un
sistema módulo de facturación no se podría implementar de modo separado que el módulo
de stock, ya que la operatoria del primero impacta en el segundo. Claro, también es posible
implementar versiones reducidas de ambos módulos por separado.
145
En algunos sistemas on-line, donde no se cambia la base de datos ni la lógica del negocio,
sino solamente la interfaz de gráfica es posible mantener por un tiempo ambas versiones. De este
modo se le puede ofrecer al usuario que utilice la nueva versión o que continúe usando aquella a la
que está acostumbrado. Los desarrolladores pueden ir ajustando detalles, ofreciendo ventajas,
armando instructivos y mejorándola; hasta lograr que finalmente sea ampliamente aceptada por
todos. Este tipo de implementaciones es frecuente verlas es aplicaciones masivas, web o redes
sociales, donde se le permite al usuario mantener por un tiempo la actual interfaz, mientras va
tomándole la mano a la nueva.
Por supuesto cada uno de estos métodos tiene ventajas y contras. La elección final tendrá
que ver con el tipo de sistema; el tipo de empresa; la criticidad de los datos que maneje; las
capacidades de los usuarios y, por supuesto, si es posible y conveniente mantener operativo el
sistema anterior.
8. La resistencia al cambio
No es posible finalizar este capítulo sin considerar la resistencia al cambio que puedan tener
los usuarios, ya sea por cuestiones reales (más trabajo en la carga inicial o la necesidad de aprender
una nueva operatoria) y/o percibidas (el sistema va a reemplazar mi tarea, miedo a lo nuevo,
perdidas de control sobre los datos).
Lo cierto es que, independientemente de las ventajas y facilidades que aportan los nuevos
sistemas, también es verdad que modifican el modo actual en el que se desarrollan las tareas.
Ademas se modifican las relaciones de poder en la organización. Quien antes manejaba datos en
papel, pierde el poder de ser el único dueño de esa información. Si alguien le presentaba al gerente
un informe todas las semanas, quizá dejará de hacerlo (porque el gerente lo obtendrá de modo
directo). El que durante años manejó un sistema y lo conoce de memoria, ahora deberá aprender a
usar uno nuevo. El que antes utilizaba cómodamente una PC ahora tendrá que operar un dispositivo
móvil.
Múltiples pueden ser los motivos por los cuales algunos usuarios se resistan a la
implementación de un nuevo sistema. Y aquí la coordinación entre los desarrolladores y los
responsables internos del sistema juegan un rol fundamental. Debe quedar claro que desarrollar un
nuevo software no fue una idea alocada ni técnica, sino que fue una necesidad operativa y política
de la organización, y que cuenta con el aval de la más alta dirección.
La participación de los usuarios en las etapas de relevamiento, análisis y pruebas,

haciéndolos sentir parte de este nuevo proceso, escuchando sus opiniones y necesidades, ayuda
disminuir resistencias. Si el usuario realmente comprueba que el sistema hace lo que pidió y que
además le facilita la tarea, terminará comprendiendo los beneficios de su implementación.
También es importante que los jefes y máximos responsables participen en las tareas de
capacitación y reuniones previas al lanzamiento. Esto ayuda a comprender que el nuevo sistema es
algo prioritario para la organización. Ellos podrán explicar los beneficios que traerá y despejar las
dudas.
146
En algunos casos será útil contar en el equipo de desarrollo personas con conocimiento
especifico en gestión del cambio organizacional, para trabajar especialmente en propuestas que
permitan disminuir esta resistencia y lograr un despliegue exitoso.
9. Bibliografía

147
9
Apunte 9

Mantenimiento de Software
148
1. Introducción
Cuando se habla de construcción de software se suele pensar, como objetivo final, en poner
en marcha una aplicación informática, cumpliendo las especificaciones, los plazos y los costos
previstos para el proyecto. Sin embargo, este es solo un primer paso. Las organizaciones siguen
evolucionando y los sistemas deben acompañar dicha evolución. Los cambios y agregados son
imprescindibles. Una vez puesto en marcha, el software habitualmente entra en una etapa de
constante evolución. A dicha etapa nos referimos cuando hablamos de mantenimiento.
En ocasiones, este proceso termina siendo mucho más largo e importante que el de la
construcción original y, con el tiempo, el software termina siendo mucho más completo; con más
funcionalidades y mucho más seguro y confiable que el primer desarrollo.
El mantenimiento va más allá de reparar errores, agregar nuevas funcionalidades y adaptar

el software al contexto. En este apunte se buscará poner foco de atención sobre varios temas de
interés respecto de esta etapa.
2. Definiciones
Definir qué es el mantenimiento de software parece sencillo: Es la modificación de la

aplicación luego de que ha sido puesta en funcionamiento. Estas modificaciones pueden ser para
corregirla, adaptarla a cambios del contexto o agregarle nuevas funcionalidades. Ian Sommerville,
en su libro “Ingeniería de Software” habla de 3 tipos de mantenimiento:
• Reparaciones de fallas (Correctivo):

Busca corregir errores de codificación, de funcionamiento o de incumplimiento de los
requerimientos. Estos últimos son habitualmente los más costosos de solucionar.
• Adaptación ambiental (Adaptativo):

Este tipo de mantenimiento se requiere cuando cambia algún aspecto del entorno del
sistema, como el hardware, el sistema operativo, o incluso, nuevos requisitos legales. El
software debe modificarse para que siga funcionando y respete las nuevas normativas.
• Adición de funcionalidad (Perfectivo):

Este tipo de mantenimiento es necesario cuando varían los requerimientos del sistema
en respuesta a un cambio organizacional o empresarial. La escala de los cambios
requeridos en este caso suele ser mucho mayor que en los otros tipos de mantenimiento.
Claro que esta distinción es más teórica que práctica. Quizá solo tenga sentido a los efectos
de un mejor entendimiento de la etapa. Lo cierto es no importa en qué se origina la necesidad de
cambio, si estamos preparando una falla pequeña o agregando una nueva funcionalidad, siempre
será imperativo responder a estas solicitudes de la mejor manera. Para ello volverá comenzar un
nuevo proyecto de desarrollo de software, obviamente acotado, que permita introducir el cambio
de modo correcto. Por supuesto, habrá que cuidar de no degradar el resto sistema y manteniendo
su calidad.
149
3. ¿Mantenimiento o Garantía?
La enorme mayoría de las publicaciones de ingeniería de software describen 6 etapas en el

ciclo de vida de un sistema: Análisis, Diseño, Codificación, Prueba, Puesta en Marcha y
Mantenimiento. Algunos autores ni siquiera contemplan al mantenimiento y todo culmina cuando
se implementó el sistema.
Pero… ¿Qué pasa con la garantía? ¿Por qué somos tan exigentes en solicitar garantía en casi
cualquier producto que compramos, salvo en el software? ¿Por qué solemos devolver el hardware
defectuoso para que lo cambien por otro, pero no procedemos igual con las aplicaciones
informáticas?
La respuesta quizá esté en la naturaleza propia de un software. Si compramos una zapatilla

y notamos que la suela esta rajada, o que el color no es el mismo que pedimos, sabemos que eso
no puede arreglarse. Al menos no sin comprometer al producto, una suela reparada no es lo mismo
que una suela nueva de fábrica. Diferente es el caso del software. Este puede repararse y funcionar
como nuevo. Si se le agrega un campo a una pantalla, la misma se comporta exactamente igual a
que si ese campo hubiera existido en el desarrollo original. Lo mismo si se cambia de color. Quien
opera una aplicación es incapaz de determinar si en esa pantalla hubo cambios o agregados
posteriores al desarrollo original. No tiene sentido quedarnos con una computadora que no
funciona o con una zapatilla rota, pero sabemos que el software puede repararse a nuevo.
Independientemente de esto, no siempre el software tiene garantía. O si la tiene es muy

corta y en seguida se busca pasar a la etapa de mantenimiento. Es cierto… el mantenimiento
correctivo se parece mucho a lo que uno pretendería de una garantía, pero con dos diferencias muy
importantes:
1. La garantía debería ser obligatoria, el mantenimiento no. El desarrollador debe

asegurar que el software funciona sin errores y, además, que ejecuta eficazmente
aquellas tareas para las que fue programado. Todo aquel que recibe un software tiene
derecho a reclamar que funcione, independientemente de si ese contratará o no un
mantenimiento con el proveedor.
2. El mantenimiento tiene un costo adicional para quien lo contrata, por fuera del precio
inicial pautado. La garantía de funcionamiento es parte del desarrollo y, su costo,
debería estar incluido en el precio original. El usuario no tiene por qué pagar extras a lo
acordado inicialmente para poder corregir errores o problemas que el software nunca
debió tener.
Hay que comprender que tanto el proceso de testeo (donde se encuentran los errores),
como el de depuración (donde se corrigen) forman parte de la creación de software. El cliente debe
en realidad asumir el costo de ambos, pero no como un adicional, porque ninguno de los dos
procesos mencionados es extra u optativo. Queda entendido que cuando alguien paga por un bien
o servicio, esta debe funcionar correctamente. En el caso en que haya alguna falla el proveedor
deberá hacerse cargo del costo de la reparación, sin exigir nada más al cliente. Por supuesto que,
para hacer frente a estas reparaciones, quien vende suele cargar un valor en el precio que cubra
esos eventuales costos.
150
Podría haber excepciones… muchos productos se compran y venden sin garantía, pero esos
es algo que ambas partes saben y que están dispuestas a aceptarlo. Por supuesto, sería una opción
demasiado arriesgada comprar un software que no pueda corregirse y confiar que este va a
funcionar desde el inicio sin ningún error.
Para que se entienda mejor el concepto se puede plantear un ejemplo por el opuesto. Se
comparan dos softwares para decidir cuál de ellos conviene comprar. El primero sale 1000$, pero el
desarrollador nos asegura que cualquier error que aparezca en los primeros 6 meses será corregido
sin cargo. El segundo sale 500$, no incluye ninguna garantía, aunque el programador nos dice que
realiza todas las pruebas necesarias para que no haya errores y que además si los hubiera los corrige
con un abono de mantenimiento obligatorio de $ 50 durante 6 meses. ¿Conviene elegir el segundo
paquete, porque es más barato que el primero? Bueno, dependerá de la evaluación que se haga al
segundo proveedor y los riesgos que se están dispuestos a asumir, pero está claro que un software
que vale la mitad y que no tiene garantía de funcionamiento es posible que tenga muchísimos
problemas. Además, a los costos de reparación hay que sumarle los costos por no poder operar
correctamente el sistema.
En definitiva, es importante redefinir el proceso de ciclo de vida del software para agregar
esta etapa: Ingeniería de Requerimientos, Diseño, Codificación, Prueba, Despliegue, Garantía y
Mantenimiento
Hay que recordar también que, por las características propias del software, la mayoría de los
problemas aparecen en los primeros tiempos de uso. Una vez que se estabiliza, no se estropea y
funciona sin errores hasta que finaliza su vida útil. A diferencia de los productos tradicionales, donde
una garantía corta cubre al fabricante de los problemas vinculados al desgaste, en software se
pueden dar garantías muy largas, incluso a perpetuidad, a sabiendas que los errores generamente
afectan solo los primeros tiempos de uso.
4. Prueba versus Garantía
Uno de los fundamentos de aplicar Ingeniería de Software al desarrollo, es poder producir

aplicaciones confiables y sin fallas. La prueba tiene como objetivo detectar los posibles errores,
antes de que el sistema sea puesto en producción. Está probado que los procesos de calidad
minimizan la posibilidad de que los errores lleguen a al usuario final. En este contexto… ¿qué tan
importante es la garantía?
La garantía justamente le garantiza al usuario, valga la redundancia, de que todos los

controles de calidad se cumplieron. Si se relajaron, el desarrollador se verá obligado a enfrentar
mayores costos para resolver los problemas que aparezcan. Por este motivo, es de esperar que el
desarrollador procure detectar los problemas antes de entregar el software. De ese modo se
ahorrará los costos de resolverlos luego, en el período de garantía. Siempre es mucho más barato
solucionar problemas mientras el software está aún en desarrollo, que una vez que este fue
implementado.
A como sea, el usuario siempre sale beneficiado si el software tiene garantía, no solo porque
no tiene que pagar para solucionar eventuales fallas, sino porque es el mejor modo de asegurarse
151
que el desarrollador buscó hacer las cosas de la manera correcta y puede suponer que tiene un
software probado y seguro para operar.
5. La dificultad en los contratos de mantenimiento
La etapa de mantenimiento implica un acuerdo contractual entre partes, con más o menos
formalidades. Por un lado, se fijarán que cosas estarán cubiertas en esta etapa y, por el otro, se
establecerá una prestación monetaria que cubra los costos. En pólizas las garantías comunes,
estamos acostumbrados a encontrar un extenso texto de “letra chica” con un motón de exenciones
y limites, que protegen al consumidor, pero tambien al fabricante de cuestiones inculpables. En
software, tampoco la cosa puede resultar tan simple.
Como hemos dicho, el mantenimiento tiene 3 orígenes: 1) errores, 2) cambios o 3) nuevas

funcionalidades. ¿Qué precio habría que fijar para que cubra libremente todo esto? ¿En un mes se
pueden pedir decenas de cambios? ¿Cualquier adaptación está incluidas? ¿Toda nueva
funcionalidad estará cubierta por el canon pagado por el mantenimiento?
Podrían establecerse límites. Por ejemplo, se podría establecer que todos los errores serán
solucionados sin límite; que además se destinaran equis cantidad de horas por mes para cambios y
mejoras y que las adaptaciones se presupuestarán aparte, a un valor hora especial. Incluso pueden
establecerse alguna banda o escala, por ejemplo 50 horas gratis, 50 horas a un valor bonificado y el
resto a un valor full. Además, pueden pautarse plazos de resolución según la urgencia de caso. Quizá
los errores puedan resolverse en 24 horas, mientras que los demás cambios no tienen tanta urgencia
y pueden demorar, por ejemplo, una semana.
Pero la realidad de nuevo complica las cosas. ¿Si algo no fue pedido correctamente… es un
error o una modificación? Si el software hace algo, pero de un modo distinto a como el usuario lo
quiere… ¿es error o modificación? ¿Cómo sabe el usuario que las modificaciones solicitadas están
dentro el tope de horas mensuales incluidas en el precio? Si el gobierno modifica de un día para el
otro la retención de ganancias… ¿De quién es la responsabilidad de que el sistema este modificado
de modo urgente? ¿Y si cambia el sistema operativo o el cliente decide reemplazar las PCs, por
dispositivo móviles?
Los contratos pueden ser más o menos detallados. Incluso elaborados por especialistas
letrados y hasta ser auditados. Pero los más importante es que las partes actúen de buena fe y que
entiendan que esta etapa es un juego de suma cero. Si alguna de las partes tiene beneficios
extraordinarios, es porque la otra los pierde. El desarrollador tiene que poder cubrir
razonablemente sus costos con en precio fijado, y la empresa que opera el software tiene que recibir
prestaciones que justifiquen ese monto que abona periódicamente. La confianza, la transparencia
y el dialogo siempre ayudan. Por ejemplo, se le puede explicar al usuario que el cambio solicitado
es complejo y que se hará, pero que el próximo mes no se aceptarán otros cambios. O que el error
marcado no es tal, que se corregirá, pero no con la urgencia que se corrigen otros errores.
La relación cliente-desarrollador establece una alianza estratégica ante ambas partes. A los
dos les conviene que el software ande bien y que evolucione. El desarrollador evaluará seguramente
la posibilidad de participar de otros desarrollos que le presente el cliente. A su vez, este se
beneficiará de seguir trabajando con un proveedor confiable. Es por eso que no siempre la garantía
152
(o el mantenimiento) debe ser interpretado solamente bajo la fría letra de un contrato. A veces
conviene otra dinámica de apuesta a futuro.
Otra de las cosas que deben acordarse es cuándo finaliza el contrato de mantenimiento y en
qué condiciones se termina el vínculo. No resulta razonable plantear un mantenimiento indefinido.
Llegará un momento que el usuario ya no pida más cosas y que no resulte conveniente seguir
teniendo recursos ociosos a la espera de que se produzcan. Pero tampoco es posible que, por alguna
razón intempestiva, se deje al usuario con un sistema que ya no puede seguir modificando. Es
posible que al finalizar un primer contrato, que aparezca otro que, por ejemplo, asegure a la
organización usuaria que seguirá recibiendo actualizaciones urgentes, pero ya no podrá pedir
cambios o modificaciones. Nuevamente, el contrato de mantenimiento debe ser beneficioso para
ambas partes para que decidan continuarlo.
En los casos de software genérico (Windows, por ejemplo) el ciclo de soporte se encuentra
claramente definido. Las distintas versiones van recibiendo diferentes tipos de mejoras,
correcciones y actualizaciones por un tiempo determinado. Luego, pueden pasar a una etapa donde
solo reciben parches de seguridad. Finalmente, algún momento ya los sistemas ya no reciben ningún
tipo de soporte ni asistencia.
6. El mantenimiento ocurre al final, pero se piensa al inicio
Una de las cosas que deben definirse al comienzo de un proyecto es cómo será la evolución
del sistema. Si se prevé que software cambiará luego de su primera versión, debe programarse de
modo tal que estos cambios sean factibles, sencillos de realizar y que no degraden el sistema
La utilización de parámetros externos; la división modular; la programación sencilla; la

documentación detallada; la inclusión de funciones de actualización automática; el uso de
estándares; la posibilidad de que el usuario pueda agregar funcionalidad (por ejemplo, crear sus
propios listados) son, entre otras, cosas que facilitan el mantenimiento posterior. Cuando se diseña
el sistema y en especial cuando se lo programa, se deben adoptar todas las buenas prácticas que
faciliten el mantenimiento posterior.
Ejemplificando, si se prevé que el sistema se actualice on-line, es deseable que esté que
pueda actualizarse por módulos. No sería válido pensar que para corregir un error en la calculadora
de Windows deba actualizarse todo el sistema operativo. La calculadora debe poder ser
reemplazado por una versión corregida en forma fácil e independiente. Del mismo modo… si puedo
cambiar la tasa de IVA en un archivo de parámetros, la actualización del sistema sería mucho más
fácil que si el 21% forma parte del propio código fuente y debe cambiarse en cada lugar donde
opere.
Obviamente, diseñar el software con funcionalidades que le permitan recibir correcciones

automáticamente, o en forma remota, va a facilitar los cambios y reducir los costos de la etapa. Las
actuales tiendas de aplicaciones permiten que, con solo subir una nueva versión, esta se despliegue
en forma automática, y casi inmediata, a todos los usuarios. Sin embargo, en software empresarial
esto no es tan fácil. Los despliegues automáticos no siempre son deseables ya que pueden
interrumpir flujos de trabajo, o afectar otras partes críticas del sistema, que hoy funcionan bien,
pero podrían dejar de hacerlo tras la automatización. El mantenimiento remoto también puede abrir
153
brechas de seguridad y la posibilidad de que alguien use esas funcionalidades para filtrar código
malicioso. Todo esto debe ser cuidadosamente revisado y tratado con toda la rigurosidad que el
tema merece.
Por otro lado, no todo el software se piensa para para ser actualizado en el futuro. Hay
software embebido dentro de ciertos dispositivos o programas de un solo uso (por ejemplo, un
software que se desarrolla para alguna tarea puntual y única, como puede ser un conversor de
archivos entre 2 sistemas diferentes). Pero, aun así, siempre es conveniente programarlo pensando
en que cosas se le pueden agregar para que funcione a futuro en algún otro caso similar.
Los mayores costos que representa pensar de este modo (es más caro hacer software
parametrizable que no hacerlo) terminan produciendo mayores beneficios a la hora de tener que
corregir un error.
7. La preservación de los datos
Una de las cuestiones centrales a la hora de actualizar software es preservar los datos del
usuario. Y esto tiene 2 cuestiones vinculadas:
• La primera y más obvia… los datos deberían almacenarse en un archivo distinto de la

aplicación principal. De este modo, puedo hacer modificaciones en el programa, luego
reemplazar el archivo ejecutable por el nuevo y los datos quedan intactos. Esto no ocurre
si la lógica del sistema y los datos están en el mismo archivo. En Excel, por ejemplo, si yo
modifico la planilla con nuevos cálculos y fórmulas no puedo simplemente reemplazar
luego la planilla del cliente sin que pierda su información.
• Aun cuando los datos se encuentren separados de la lógica que los maneja, hay veces
que los cambios solicitados requieren cambios en la estructura de dichos datos. Por
ejemplo, cuando se necesita agregar un campo, modificar un tipo de datos o agregar una
tabla. De nuevo en este caso no es posible pisar el archivo de datos con uno con la
estructura corregida, sino que hay que hacer los cambios de modo que se preserven los
datos ya cargados. Seguramente será necesario en estos casos realizar alguna aplicación
para pasar los datos de la vieja estructura a la nueva, o realizar los cambios manualmente
sobre la base de datos original.
En este sentido, siempre es deseable que cualquier nueva implementación, sea automática
o manual, haga primero una copia de seguridad completa del sistema actual, antes de correr los
procesos de actualización. También es importante siempre existan los mecanismos para permitir
volver a utilizar la versión anterior en el caso de que algo no funcione como se espera con el software
actualizado.
154
8. Mantenimiento y gestión de sistemas heredados
Un tema particular para considerar son los sistemas heredados. Son sistemas que ya no
reciben nuevos cambios ni a los que se le agregan funcionalidades, pero es necesario mantener ya
que prestan algún servicio a la organización. También debemos incluir en este caso a los sistemas
desarrollados por terceros que debamos administrar (incluso continuar con su mantenimiento, por
ejemplo, corrigiendo errores si los hubiera.) En estos casos tenemos una serie de alternativas para
analizar y ver cuál es la más conveniente:
• El caso más sencillo es donde el sistema ya no va a realizar un aporte efectivo a los

procesos empresariales, o casi todas las funcionalidades principales han sido absorbidas
por otras aplicaciones. En estos casos puede ser factible desechar completamente el
sistema y quitarlo de los ambientes productivos.
• Otro caso es aquel sistema que es relativamente estable, no se le incorporan nuevas

funcionalidades, no aparecen errores o problemas graves y los usuarios tienen
relativamente pocas peticiones de cambio. Si es así, quizá sea conveniente continuar
dando servicios de mantenimiento a este sistema.
• Cuando la calidad del sistema se haya degradado por el cambio constante y cada vez se
dificulta más modificarlo, es hora de pensar en un recambio. Aparecen dos alternativas:
Una, dejar la aplicación tal cual y sin cambios y construir otra en paralelo que tenga las
nuevas funcionalidades. La otra opción, obviamente, es que el nuevo software termine
reemplazando por completo al anterior.
• También existen factores externos que, en ocasiones, obligan a un reemplazo aun

cuando el software preste servicios de un modo satisfactorio. Cuestiones como
actualizaciones de hardware, vencimiento de licencias de software o simplemente
cambios muy significativos en la operatoria de la organización, determinan que sea
necesario pensar en un nuevo desarrollo.
9. Costos del mantenimiento
El mantenimiento de software suele representar una parte muy importante de los costos de
las áreas de sistemas. En sistemas empresariales los costos suelen ser comparables con los de
desarrollo inicial. Es decir, se gasta tanto dinero en mantener y modificar un sistema ya funcionando,
como el que se gastó en su momento para programarlo.
Además, hay situaciones particulares que aumentan tanto la dificultad de modificar los
sistemas, como sus costos y ya no resulta económicamente viable seguir manteniendo el software.
Entre ellas podemos mencionar:
• El desarrollo original no se pensó para ser adaptable o modificable, con lo cual es más
complejo y caro cambiarlo.
155
• Los continuos cambios, parches y agregados, degradan el software al punto que cada
nueva corrección aumenta el riesgo de que el sistema deje de andar. Un caso que
ejemplifica este punto es cuando se llegan a límites que originalmente parecían lejanos.
Por ejemplo, cuando ya no se permiten agregar más campos a una tabla de una base de
datos.
• La documentación está incompleta, no existe o no está actualizada.
• El paso del tiempo y los cambios en el equipo de desarrollo que hace que los
programadores originales ya no estén, y quienes los reemplazan quizá no tengan el
conocimiento necesario sobre aquel sistema.
• Prácticas deficientes que, tiempo atrás servían, pero ahora se vuelven ineficientes y
obsoletas.
• La empresa ya no cuenta con programadores que utilicen el lenguaje de programación

el que fue programado el software. Incluso, en ocasiones, tampoco son fáciles de
encontrar en el mercado laboral.
• Se requieren mantener estructuras viejas de hardware o sistemas operativos. A veces, la

virtualización permite simular entornos pasados, pero, de no lograrlo de ese modo, quizá
necesita operar un hardware viejo que ya no se consigue o que es costoso de mantener
(por ejemplo, un mainframe).
• Se requieren licencias operativas o de la base de datos que por algún motivo ya no se

conviene mantener (por ejemplo, casos de licencias cotizadas en dólares que se vuelven
impagables en determinado momento)
En estos casos siempre es conveniente evaluar si los costos de mantener un sistema no son
mayores que del de construir uno nuevo.
10. Mantenimiento y Desarrollo Ágil.
Una de las características distintivas del desarrollo ágil es que los sistemas están cambio
permanente. Los usuarios proponen cambios, mejoras y nuevas funcionalidades en el sistema que
ya tienen operando, y los desarrolladores las van programando e implementando en forma de
incrementos periódicos y permanentes (sprints en Scrum).
Estos conceptos se asemejan mucho al funcionamiento la etapa de mantenimiento de un

software. Podríamos pensar que, en determinado momento, un proyecto desarrollado siguiendo un
modelo dirigido por un plan, pasa a comportarse como un desarrollo ágil: El sistema queda abierto
al cambio constante y permanente. La verdad, no se equivoca demasiado quien piensa de este
modo.
Lo que hay que definir, entonces, es que estrategia de desarrollo se utiliza durante esta etapa
de mantenimiento. Puede utilizarse un modelo lineal secuencial reducido donde, cada vez que surge
156
una necesidad de cambio, se elabora un mini proyecto de desarrollo donde de pasan por todas y
cada una de las etapas del modelo. Puede pensarse en un modelo en espiral infinito, donde en cada
iteración se agrega funcionalidad, analizando la conveniencia o no de tal cambio (análisis de riesgo)
Pero también es factible convertir ese proyecto en un desarrollo ágil y aplicar un modelo scrum a
partir de la implementación, no importa cómo se desarrolló originalmente.
Cualquiera alternativa que se elija será válida. Pero lo que hay que tener en cuenta es que
hay que seguir un modelo de desarrollo, el que fuera. Ágil o dirigido por un plan, el que mejor se
adapte al momento. Solo siguiendo un modelo se puede cumplir con todos los pasos que aseguren
la calidad del cambio y, por lo tanto, la calidad del nuevo sistema.
Siempre hay que recordar que, ante cualquier modificación, el sistema deberá pasar
nuevamente por toda la etapa de pruebas, testeando no solo la sección cambiada, sino todo el resto
del software para asegurarse que no ha quedado comprometido al algún otro punto de este.
11. El dilema del mantenimiento infinito
Una de las funciones del mantenimiento del software (o del desarrollo ágil) es permitir que
el sistema acompañe la evolución de las organizaciones, los cambios externos, se adapte a nuevo
hardware o dispositivos y pueda utilizarse en nuevos sistemas operativos. Pero esto nos lleva a una
serie de situaciones que debemos considerar.
La primera de ellas el software tiene límites. Al igual que un edificio… se le pueden agregar
pisos, se los puede modificar, pero llega un punto en que los cimientos no alcanzan. Agregar una
construcción en la terraza puede hacer que el edificio colapse. En el software pasa algo similar. Cada
cambio que se le introduce lo va mejorando, lo va ampliando, pero también va degradando su
estructura o su base de datos. El sistema puede volverse lento, pesado y hasta complejo de usar.
Llega un punto donde es necesaria una reingeniería completa del sistema para que volver a tener
un sistema optimizado y listo para continuar recibiendo mejoras.
¿Y qué pasa con las APPs o con sistemas genéricos no atados a una determinada empresa?
¿Qué pasa cuando el software en cuestión depende de desarrolladores que tienen como objetivo
seguir agregando funcionalidades y mantenerlo activo? Acá es donde muchas veces se cae en una
trampa peligrosa: sigo actualizando el software agregándole cosas que nadie pidió ni necesita, o lo
dejo tal y como esta (asumiendo obviamente que funciona bien y sin errores), corriendo el riesgo
de que se piense que es una aplicación obsoleta y abandonada.
Muchas veces las aplicaciones agregan funcionalidades de manera periódica, la mayoría de

las cuales pocos utilizan. Obviamente esto hace que la aplicación se vuelve más demandante de
recursos, más pesada en su uso, con una interfaz que comienza a complicarse. Llega un punto que
los usuarios prefieren pasarse a otra aplicación más simple que cubre específicamente nuestras
necesidades.
Esto se agrava en ocasiones donde el equipo encargado del mantenimiento tiene menos
recursos que el que programó la aplicación original o, incluso, es otro. Y, además, se enfrenta a una
interesante dualidad: Por un lado, su objetivo es mejorar el sistema y agregarle nuevas
funcionalidades; por el otro, los usuarios están acostumbrados a una nueva versión que cumple con
157
sus requisitos y no necesitan cambiar. Eso sin contar con que, al aumentar las funcionalidades, y con
ello las líneas de código, la posibilidad de fallas y errores aumenta.
Se pueden dar decenas de ejemplos de sistemas, aplicaciones y juegos que los usuarios
abandonan por perder la simpleza original o por exigir dispositivos cada vez más potentes para su
uso. O simplemente por imponer cosas que el usuario no necesita y no le aportan nada especial. Los
“Mosaicos” o “Tiles” que pretendieron reemplazar al clásico menú de inicio de Windows son un
ejemplo. Estos tenían todo el sentido en pantallas táctiles, pero no en equipos tradicionales. Las
quejas y el pedido para que vuelva el clásico menú fue masivo. Los “Live Tiles”, esos mosaicos
animados que conviven hoy en Windows 10 con los íconos tradicionales del menú, son rechazados
por muchos usuarios, que los perciben como un innecesario consumo que recursos. Todo indica que
dicha funcionalidad desaparecerá en la próxima versión del sistema operativo.
Dos reglas no escritas ni formales pueden aplicarse en estos casos.
1. “Lo que anda bien, no debe arreglase”. Si una aplicación funciona si errores y cumple
con las necesidades del usuario, lo mejor es dejarla tal y como está. Cualquier cambio
en el código, por menor que sea, implica el riesgo de que aparezca alguna falla. Hay
veces que el usuario valora actualizaciones frecuentes, pero en general prefiere
aplicaciones estables, a cuyo uso está familiarizado y cuyos sus resultados son
confiables. Imaginemos el caso de que un auto autónomo choque, sólo porque a un
ingeniero de software se le ocurrió que el código debía optimizarse.
2. “El usuario siempre tiene razón”. Independientemente de lo que piense el líder de

proyecto o el grupo desarrollador, el usuario es el que define, en última instancia, lo
que necesita o no de un sistema, y el modo en el cual quiere resolverlo. Si el equipo
de desarrollo piensa que una nueva interfaz puede modernizar nuestra aplicación y
la puede hacer más intuitiva, pero el usuario cree lo contrario, no tiene sentido forzar
el cambio.
Por supuesto, además del usuario u el equipo de desarrollo, otros factores intervienen en un
sistema. A veces los cambios son necesarios porque debemos adaptar el software a un nuevo
sistema operativo o a nuevos estándares de desarrollo. A veces debemos hacerlo más
seguro, o debemos incorporar controles que las autoridades de contralor exigen. En esos
casos el cambio será inevitable, pero habrá que explicar bien al usuario el origen de este y
cuáles serán los beneficios que traerá su implementación.
12. ¿Todo el software requiere mantenimiento?
En contraposición con el punto anterior, cabe también preguntarse si todo el software que
se desarrolla debe ser modificado en algún momento de su vida útil. La respuesta es que no, aunque,
generalemtne, esto es una excepción.
Existe software que podríamos “de única vez” y que tiene un propósito puntual y específico
que una vez cumplido, deja de existir. Por ejemplo, el software que se realiza para migrar datos de
un sistema a otro. Una vez realizada la migración ya no tiene más utilidad.
158
También existe un montón de aplicaciones que son instaladas en dispositivos no
actualizables, como relojes, maquinaria, juguetes, automóviles, televisores, calculadoras,
electrodomésticos (No confundir con la versión “Smart” de dichos dispositivos). Ese software sigue
funcionando mientras el dispositivo siga utilizándose. Hay programas que, si bien reciben
periódicamente actualizaciones y mejoras, sus primeras versiones siguen funcionando tan bien
como el primer día. O incluso mejor, dado que los procesadores más poderosos de hoy día, pueden
mejorar el funcionamiento. El buscaminas o el solitario de Windows 95 son dos ejemplos, pero hay
miles de aplicaciones de antaño que podemos seguir usando. Ya se ha dicho anteriormente que el
software no se desgasta. Una vez alcanzada su madurez, puede seguir ejecutándose de por vida. En
todo caso, un software deja de poder utilizare solo cuando ya no es soportado por las computadoras
actuales.
¿Pero qué pasa con los softwares comerciales y de las organizaciones? Acá la cosa es
diferente. Uno no se imagina que un software, por mejor programado que esté, pueda brindar
servicios a una organización durante 20 años. Pero no por un defecto del software en sí, sino porque
los procesos organizacionales cambian y vuelven obsoleto al software. También aparecen nuevas
computadoras, dispositivos y sistemas operativos. Entonces hay que terminar por optar entre
mantenerse con hardware y software del pasado, o dar el paso y actualizar los sistemas.
Recientemente, tanto Apple como Google, comenzaron a retirar de sus tiendas aplicaciones
que llevan tiempo sin actualizarse (además de otros factores como la cantidad de descargas). ¿Es
razonable pensar que las Apps deban ser actualizadas o condenadas a desaparecer? Mas allá de las
quejas y de las excepciones, la realidad es que es tiene sentido que así suceda. Los dispositivos
cambian, las pantallas incorporan, por ejemplo, los famosos “notch” en la parte superior para dar
lugar a la cámara, aparecen y desaparecen botones. El propio sistema operativo va a agregando
funcionalidades y capas de seguridad. Un software que utiliza componentes del sistema operativo
que son obsoletos o inseguros necesariamente deben ser forzados a cambiar. Por supuesto que
también hay funcionalidades sugeridas, y que los desarrolladores pueden optar por incluir o no,
como nuevos diseños de los menús, nuevas paletas de colores, modo nocturno y una gran cantidad
de etcéteras.
En resumen, por lo general el software recibe mantenimiento durante toda su vida útil, ya
sea para corregir defectos o para ir acompañando los cambios en el entorno, en la organización, en
el sistema operativo o en los dispositivos en los que opera, aunque no es algo que no es algo que
obligatoriamente deba pasar.
13. Bibliografía

159
10
Apunte 10
Conceptos Fundamentales de la
Estimación, Costeo y Precio del Software
160
1. Introducción
Una de las funciones principales de cualquier administrador de proyectos es la de estimar o

presupuestar. Estimar qué recursos se van a necesitar, a partir de qué momento, y por cuánto
tiempo serán utilizados; es la base necesaria para determinar el costo de un desarrollo de software.
Además, armar un plan y presupuesto, permite al administrador tenerlo bajo control, anticiparse a
posibles desvíos, y cumplir los plazos y costos comprometidos.
El desarrollo de software tiene sus particularidades. La posibilidad de ir agregando,

ampliando y modificando el producto sin degradarlo, como también el hecho de ser una actividad
de desarrollo intelectual hacen, que la estimación se vuelva una tarea a veces casi imposible. El
objetivo de este trabajo es exponer la problemática y brindar algunas posibles alternativas de
solución.
2. Estimación de software
La estimación de un proyecto es quizá la parte tarea más compleja que debe desarrollar el
encargado de gestionarlo. En determinadas industrias, en función de los estándares y la experiencia,
existen tablas estimativas que facilitan la tarea. Hay tiempos estimados de cuanto lleva construir
una casa; las automotrices saben cuánto les lleva el proceso de fabricación de un vehículo, pero…
¿existe tal cosa en el software?
En principio no. Y si existen… solo serían válidas si el proyecto de desarrollo y el software a

construir fuera muy parecido a otros anteriores, cosa que rara vez ocurre en la realidad. Y aun
cuando así sea, casi con seguridad va a correr en un entorno de hardware distinto o incluso sobre
versiones actualizadas del sistema operativo.
¿Cómo pueden estimarse, de un modo razonable, los recursos que se utilizarán en la

construcción de un software? Aunque estimar es tanto un arte como una ciencia, esta acción no
necesariamente puede llevarse a cabo de manera fortuita Para comenzar, pueden destacarse dos
técnicas para aplicar:
• Técnicas basadas en la experiencia: La estimación de los requerimientos futuros se

basan en la experiencia del administrador con proyectos similares anteriores. En
esencia, es el propio administrador quien emite un juicio informado de cuáles serán
los recursos necesarios. Para que esta técnica sea lo más precisa posible, es necesario
que en los proyectos anteriores se haya recolectado toda la información cuantitativa
necesaria, de modo que sirvan para compararlo con el proyecto que se habrá de
estimar. La utilización de métricas, sin duda, ayudan en esta tarea.
• Modelos algorítmicos de costos: En este caso se usa un enfoque formulista para

calcular recursos, en base a estimaciones de atributos del producto (por ejemplo, el
tamaño), como así también las características del proceso (por ejemplo, la
experiencia del personal implicado). Las empresas de desarrollo ms grandes suelen
161
desarrollar sus propios modelos, aunque existen algunos modelos estándares como
el COCOMO33,
Estas técnicas, y la estimación en general, se ven afectadas por una serie de fatores:
Complejidad del proyecto: Cuanto más complejo sea el proyecto, obviamente más difícil
será estimar el esfuerzo necesario para llevarlo a cabo. Sin embargo, complejidad, no es una
medida absoluta. Por el contrario, se ve relacionada con la experiencia pasada. El primer
desarrollo de una aplicación de comercio electrónico seguramente será excesivamente
complejo. Pero si el equipo de desarrollo ha construido varias similares anteriormente, la
complejidad no será percibida como importante.
El tamaño del proyecto: Cuanto mayor sea el proyecto, la cantidad de componentes a

construir y la interdependencia entre ellos aumenta fuertemente. Dividir el proyecto en
etapas puede ayudar en estos casos.
La incertidumbre del contexto: La posibilidad de que los requerimientos varíen a medida

que avanza el proyecto, por cuestiones internas o externas, también pueden afectar la
estimación. No siempre es posible pautar desarrollos cerrados que no admitan
modificaciones, menos en proyectos grandes que se extiendan el en tiempo.
La información histórica: Se ha dicho que la experiencia es fundamental a la hora de estimar.

Pero… para que esta experiencia sea confiable es preciso que se construya sobre datos
válidos. Debo cuantificar y registrar datos del desarrollo actual, no solo para medir su avance,
sino para que me sirva como parámetro para proyectos futuros. Los registros de información
histórica se vuelven muy valiosos.
¿Y qué cosas deben estimarse? Básicamente recursos y el período de tiempo durante el cual
usaré esos recursos. Será necesario estimar:
• Recursos humanos: La actividad desarrollo de software es una actividad que

depende fundamentalmente de los recursos humanos y de su capacidad intelectual.
Será necesario contratar líderes de proyecto, analistas, diseñadores, programadores,
testar, implementadores, especialistas en riesgo y seguridad. Si el proyecto es más
grande, aparecerán seguramente muchas más funciones (analistas de experiencia de
usuario, arquitecto se software, analistas de calidad, entre otros). Para cada uno de
los recursos necesarios deberá estimarse la cantidad, los conocimientos requeridos
y donde estarán ubicados físicamente.
• Recursos ambientales: Contemplan tanto los espacios físicos, como las

computadoras, redes, internet y las licencias del software de desarrollo. En el caso
de que el software se construya para algún hardware en particular (por ejemplo, un
determinado modelo de celular, o alguna maquinaria, por ejemplo, una
tragamonedas), será necesario proveer al equipo de desarrollo acceso al mismo.
33
Puede consultarse punto 23.6 del libro “Software Engineering” Teenth Edition, de Ian Sommerville, para una
profundización del tema de modelos empíricos de costos y el modelo COCOMO.
162
• Componentes34 a desarrollar: Será necesario construir nuevos componentes,
podrán reutilizarse componentes ya desarrollados (por ejemplo, el componente que
gestiona el login de usuarios, o tablas ya cargadas o la documentación de ciertas
funcionalidades), o también modificar alguno y adaptarlo al nuevo desarrollo.
También existe la posibilidad de comprar o conseguir externamente componentes
completos e incluirlos en el nuevo sistema, por ejemplo, un carrito de compras o un
botón de pago.
En cualquier proyecto, la precisión de la estimación varía en el tiempo. A medida que el

proyecto avanza y se desarrollan ciertas tareas, la incertidumbre va disminuyendo. No es lo mismo
tratar de estimar los tiempos que llevará un desarrollo antes de iniciar la programación, con la
dificulta que lleva determinar cuánto se tardará en codificar un módulo, que una vez que esta etapa
está terminada.
A medida que el proyecto avanza, la certeza también. En el extremo, una vez que el proyecto
está terminado, la estimación será 100% cierta. Pero claro, también es inútil estimar algo que ya
pasó. Cuanto más temprana sea la estimación más útil será para el proyecto, pero mayor también
el margen de error y la posibilidad de no cumplirla. Este tema será vuelto a analizado más adelante
con la presupuestación.
3. Restricciones
No es del todo cierto que el software se estime libremente. Habitualmente el software debe
ser implementado en una fecha determinada, por ejemplo, antes de fin de año, o para la apertura
de un nuevo local. Tampoco es cierto que el precio del software pueda ajustarse libremente una vez
34
El término componentes no solo hace referencia a programas de computación. Muchas otras cosas deben construirse,
como manuales, datos precargados, documentación, diseños de pantalla, etc.
163
que se valorizaron los componentes. Por el contrario, muchas veces la organización cuenta con un
determinado presupuesto y hay que ajustarse a él.
Tampoco los recursos humanos disponibles son ilimitados. No puede contratarse libremente
a todo el personal que se desee35. Además, muchas veces, las empresas desarrollan en paralelo más
de un sistema, y deben ir asignando a un proyecto los recursos en tanto se liberen de otro.
Es interesante considerar a las restricciones como lados de un triángulo. Esto permite

aumentar o disminuir uno de sus lados, a expensas de los otros dos. Es decir, si fuera necesario
acortar la duración de un proyecto, habrá que contratar más recursos y aumenta el costo. Si, por
ejemplo, se requiere reducir costos, se podrá aumentar el tiempo, permitiendo eventualmente los
recursos se compartan con otros proyectos.
Las siguientes figuras muestran cómo es posible acotar costos, pero alargando el tiempo
necesario y el uso de recursos. O como se puede reducir tiempos, pero con más costo y tiempos36.
35
Los recursos humanos del área de IT son altamente demandados a nivel local y regional. Los recursos que demanda
la industria son, en muchos casos, mayores a los profesionales que se egresar anualmente en el sistema universitario.
También es difícil capacitar personal y/o reemplazar al existente. Hay una curva inicial de aprendizaje importante hasta
que el nuevo integrante se alinea con el modo de trabajo y los estándares de la organización. A menudo, el tiempo que
demora un programador en rendir del mismo modo que el que reemplaza, suele ser mayor que lo que necesita el
proyecto.
36
Mas adelante se observará que el costo está relacionado con el tiempo en el que se usen los recursos. Sin embargo,
es posible pensar en utilizar recursos en lugar de un programador senior full time, 2 programadores junior part time.
Seguramente estos dos programadores serán más baratos que el primero, pero también demorarán más tiempo.
164
Pero… ¿Qué pasa si en el proyecto deben contemplarse la vez 2 restricciones? Siguiendo con
el ejemplo de los triángulos, algebraicamente no será posible construir un triángulo con igual
superficie si se reducen el largo de 2 de sus lados. En sistemas no hay una imposibilidad matemática,
pero sería sumamente extraño lograr un sistema en menos tiempo y con menos recursos, o tratar
de disminuir a la vez los costos y los tiempos.
Sin embargo, hay otra alternativa. Es posible reducir a la vez y de modo proporcional todos
los lados del triángulo si se acuerda que el sistema tenga menos alcance y, por lo tanto, requiera
construir menos código.
Hay que admitir que otro modo es resignar calidad. Por ejemplo, si no se hicieran controles
de calidad o se limitaran las pruebas, el software será más barato, utilizaría menos recursos y llevaría
menso tiempo. A esta altura del libro está claro de lo riesgoso e inconveniente que puede ser eta
alternativa.
165
4. Costo del software
El desarrollo de software no sigue los esquemas propios de un desarrollo tradicional. Sus

costos, por lo tanto, no pueden ser calculados siguiendo la fórmula de costeo estándar:
Costo de producción = materia prima +

mano de obra directa +
costos indirectos de fabricación.
Para empezar, no hay materia prima. Y si la hay, porque rara vez los desarrollos se inician
desde cero, sino que reutilizan algunos componentes, estos no tienen costo (o ya fueron cobrados
cuando se desarrollaron originalmente).
Por otro lado… los costos indirectos de fabricación muchas veces son irrelevantes37. Si bien
existe un producto concreto (el software) hay más semejanzas con los servicios profesionales, que
con la fabricación de bienes.
¿Cómo se calculan entonces los costos de un proyecto? Se dijo anteriormente que para
desarrollar software es necesario contar con determinadores recursos, fundamentalmente recursos
humanos, que se utilizarán durante parte o todo el tiempo de desarrollo. Esto permite armar la
siguiente ecuación:
COSTO TOTAL = ∑ (COSTO del RECURSO * TIEMPO DE UTILIZACION)

+ GASTOS INDIRECTOS
De este modo, sumando el costo de cada recurso a emplear, según el tiempo38 que se haya
estimado utilizarlo, y agregándole el proporcional de los gastos indirectos, se habrá estimado,
razonablemente, el costo del software. Si a eso se le agrega el margen de utilidad esperado, se
tendrá entonces calculado el precio al que habrá que vender el software.
Lamentablemente hay una pequeña trampa… para estimar recursos se necesitará saber que
componentes tendrán que construir esos recursos. ¡Y dichos componentes no se conocen hasta no
haber avanzado en el proyecto! En efecto, hasta no finalizar el relevamiento, no será posible saber
la funcionalidad del software. Y hasta no diseñar la solución, no será posible conocer que tan
complejos serán los módulos que habrá que programar y, mucho menos, imaginar cuantos recursos
serán necesarios emplear en su construcción.
Pero claro… avanzar sobre las etapas de análisis y diseño tiene un costo. Sin cubrirlo, no
pueden iniciarse el proyecto. Un círculo vicioso. ¿Se puede salir?
37
Además de difícil de calcular, la amortizacion de una de una PC, el costo proporcional de Internet o la energía eléctrica
insumida para producir una pieza del software, resultan claramente insignificantes, por ejemplo, comparados contra el
valor hora que se les paga a los programadores.
38
Algunos recursos son independientes del tiempo que dure el desarrollo, por ejemplo, licencias del entorno de
desarrollo, componentes reutilizables, hardware específico para el proyecto. En estos casos la ecuación funciona igual,
sumándolos en forma directa sin ponderación de tiempos.
166
5. Presupuestación de software
Primero hay que comprender que, en realidad, un desarrollo de software no comienza con
por la etapa de análisis39. Se ha marcado anteriormente la existencia de una primera etapa de
definición inicial. Con esos datos preliminares se puede hacer un presupuesto inicial estimado,
basado en la experiencia, y en métricas de proyectos anteriores. Seguramente será provisorio,
tendrá un elevado margen de error, pero servirá como idea global de la magnitud del proyecto.
La segunda idea consiste en dividir el proyecto en partes. No se buscará presupuestar todo

el software al detalle sino solamente las primeras etapas. Luego, con la información de las primeras
tareas, se podrán presupuestar las siguientes. Existen principalmente dos técnicas para dividir y
descomponer las tareas de un proyecto:
• Descomposición basada en el problema: Divide el software en base a que problema

resuelve (ABM, listados, pantallas, entrevistas, historias de usuario)
• Descomposición basada en el proceso: Se descompone el proyecto en función de los

procesos (análisis, diseño, etc.)
El este último caso es posible comenzar presupuestando solamente las etapas de análisis y
diseño. Terminada esta última etapa, ya con el panorama más claro de que habrá que construir, se
presupuestan las siguientes instancias, refinando y ajustando el presupuesto global inicial.
Este enfoque puede parecer extraño, en especial para quien pretende saber cuánto le va a
costar un sistema. Sin embargo, es ampliamente extendido en otras industrias: primero se cobra el
desarrollo de un plano o diseño y, luego de aprobado, se presupuesta el costo de la obra.
Es importante destacar que el diseño tiene un valor económico por sí mismo, y aun cuando
no se acepte el segundo presupuesto, no habrá perdido dinero40. Ese diseño servirá para que otros
programadores lo realicen o para que se construya más adelante cuando se consiga el prepuesto.
En ocasiones, en proyectos muy grandes y complejos, esta división podría ser más granular,
presupuestando cada etapa por separado o incluso dividiendo el proyecto global para ir entregando
el software por partes, o versiones sucesivas. Las técnicas de descomposición basada en el problema
también pueden ayudar para presupuestar un proceso (ej. cuantos listados deberán construirse en
la etapa de codificación, a cuántos usuarios habrá que capacitar en la etapa de implementación)
En resumen, un proyecto de software podría tener, mínimo, 3 instancias de presupuestación.

El primero, estimativo, ocurrirá en la etapa de definición inicial, para dar una idea global de
magnitud del proyecto. Un segundo presupuesto, más ajustado y basado en información
recolectada en la etapa mencionada, que abarque solamente el análisis y el diseño. Finalmente, y
ya con la especificación de los componentes que deberán construirse, se presupuesta resto de las
tareas. De nuevo, en proyectos más grandes y complejos, posiblemente otras etapas deban ser
39
Puede consultarse el apunte “Conceptos Fundamentales del Desarrollo de Software Dirigido por un Plan” para un
mayor detalle las etapas de desarrollo de software y la comunicación inicial con el cliente.
40
Para más detalle, ver “El Valor económico del Diseño”, en el apunte “Conceptos fundamentales del diseño de
Software” de César A. Briano
167
presupuestadas por separado. De este modo, el riesgo de trabajar sin un presupuesto aprobado
queda acotado solamente la etapa de definición inicial. Riego que por otro lado es razonables e
inherentes a la profesión.
Dado que el muchas veces un proyecto de software no es un producto cerrado, sino que
puede tener modificaciones y cambios, los presupuestos deben considerar también esta posibilidad.
De no permitirlo se corre el riesgo de forzar a cumplir con el presupuesto, privando a la organización
de la posibilidad de obtener un mejor software.
En línea con lo anterior también hay riesgos de estimaciones autocumplidas: Si la estimación

de tiempos o de costos no es la correcta, se termina ajustando el proyecto de desarrollo para que
la cumpla. Y esto se hace a expensas de quitar funcionalidad al software o afectar su calidad. En
ocasiones, hasta incluso se llega a reducir la prueba del software al mínimo (incluso eliminarla) solo
para cumplir con los plazos de entrega. Esto puede ser catastrófico.
6. Determinación del precio del software
La determinación del precio del software no solo depende de una adecuada estimación de
los recursos y del valor de estos. Intervienen una serie de consideraciones adicionales que deben
tener sen cuenta:
• Como ya se indicó, es imposible fijar precios finales y realistas antes de realizar la

ingeniería de requerimientos. Puede darse una idea global en función de la experiencia
y del valor de proyectos anteriores.
• Al igual que lo indicado para el presupuesto, puede darse un precio que solo incluya las
etapas iniciales de análisis y diseño. El precio de la codificación solo será posible de
determinar una vez que se conozca qué es lo que se quiere programar.
• Cuando se calcula un precio, hay que hacer consideraciones más amplias de índole
organizacional, económica, política y empresarial. A veces conviene hacer un proyecto
aun sin ganar dinero, apostando, por ejemplo, a que se continúen solicitando cambios y
mejoras. También puede buscarse una relación estratégica con el cliente respecto de
futuros desarrollo que éste tenga previstos.
• Hay que considerar los riesgos asociados con el proyecto. En escenarios muy riesgosos
seguramente se cotizará un precio mayor para cubrir posibles contingencias. La misma
consideración podrá tenerse si detecta alta volatilidad de los requerimientos,
suponiendo que puedan implicar contramarchas y reprogramaciones.
• Debe prestarse especial atención a aquellos componentes del sistema que tengan una
especial dificultad técnica, y cuya estimación inicial del tiempo de desarrollo sea riesgosa.
Se pueden prever recursos adicionales que eventualmente podrían utilizarse o bien
acordar con el cliente algún esquema de compensación de modo de que entre ambos
cubran riesgo.
168
• Dentro de los costos indirectos hay que considerar la garantía, ya que corresponderá
hacernos cargo del costo de reparación de los errores que se encuentren, tanto en la
etapa de pruebas como una vez implementado el software.
7. Particularidades del software
Entre tantas otras particularidades que tiene la construcción de software, una es que se pueden
hacer copias exactas a costo casi cero. Producir una unidad, dos o cientos de ellas, prácticamente
sale lo mismo. Dicho de otro modo, en el desarrollo del software todo el costo se lo lleva la primera
unidad.
Esta particularidad cambia la ecuación del precio del software en 2 sentidos:
• Si se está produciendo un desarrollo comercial abierto, destinado a múltiples clientes (ej.

un juego, Windows, una app para celular), obviamente no va a ser el primero que lo
compre, el que cargue con todo el costo. Por el contrario, será proporcionado entre
todas las unidades que se estimar vender. Si finalmente se venden más copias que las
estimadas inicialmente, será todo ganancia. Por otro lado, en el caso de que se vendan
menos que las previstas, el proyecto podría no recuperar sus costos.
• Si el desarrollo es para un cliente en particular, la ecuación es diferente. En este caso se

produce una sola unidad y es lógico que este cliente pague todo el costo de desarrollo.
Pero hay una consideración. Que se haga un desarrollo particular no quiere decir que el
desarrollador no se quede con experiencia y con componentes que luego pueda vender
en otro desarrollo. Incluso también está la posibilidad de conseguir un segundo cliente,
con necesidades similares, que pueda recibir el sistema con unos pocos cambios. En este
caso, el desarrollador recibiría una ganancia extraordinaria: vendería dos o más veces un
sistema que ya cobró en forma completa.
Es importante en este punto analizar cómo será el contrato que se firmará con el primer
cliente. Si se permite que el desarrollador conserve la propiedad intelectual del software
y la posibilidad de que revenda todo o parte del desarrollo, es posible pautar un precio
menor con el primer cliente, teniendo en cuenta la chance de obtener ganancias futuras
con la reventa del sistema41.
8. Presupuesto y costos de un desarrollo ágil
Tal como se ha analizado en unidades anteriores, La planificación inicial del proyecto y la

estimación son claves para poder realizar un presupuesto y costear el software. Sin embargo,
41
Muchas empresas prefieren firmar contratos que aseguren la propiedad total del software, aun pagando más por el
sistema. Si bien esto es posible… debe tenerse en cuenta que, en definitiva, el desarrollador que lo programó una vez
puede volver a hacerlo. Bastarán unos pocos cambios en la interfase como para que sea difícil demostrar que se trata
del mismo software.
169
ninguna de estas dos cosas existe en desarrollos ágiles. Por un lado… no hay plan que presupuestar.
Por el otro… el sistema está en permanente desarrollo y por lo tanto el cliente puede pedir que se
incorporen todas características que necesite.
Desde el lado del desarrollador, este pretenderá recuperar, mes a mes, el costo de los
recursos asignados al proyecto, y tener además un margen de ganancia. El cliente, por otro lado,
buscará que beneficio que obtenga por la utilización del software y sus nuevas funcionalidades sea
mayor que la inversión que está realizando para su desarrollo42.
Esta ecuación también se debe ser positiva si fuera un desarrollo interno: El beneficio
obtenido por el software debe superar el costo de los recursos que asigna la empresa para
desarrollarlo.
Un criterio comúnmente utilizado es el de facturar horas efectivamente utilizadas. Pero para

esto se requiere una relación de confianza entre el cliente y el proveedor. Si, por ejemplo, facturasen
más horas que las realmente insumidas, la relación cantidad de modificaciones entregadas / horas
facturadas disminuye y, para el cliente, puede resultarle menos atractivo continuar con el proyecto.
Otra opción es fijar un precio por componente. Por ejemplo, se puede costear el valor del
equipo de trabajo y en función de eso valorizar un sprint (costo de todos los recursos del equipo por
el tiempo de duración del sprint). También pueden valorizarse las historias de usuario (con algún
tipo de ponderación, conforme el esfuerzo que demanda su desarrollo) y cobrar luego en función
de las historias de usuario resueltas en el período. Claro que, aun elegido esté criterio, tampoco va
a ser posible saber cuántos sprints o historias tendrá finalmente el proyecto.
Otra cuestión que no puede dejar de mencionarse es como se definen las duraciones
mínimas del proyecto, de modo que el cliente no deba continuar con el desarrollo más allá de lo
razonable, pero tampoco abandonar el proyecto antes de del tiempo, dejando al desarrollador con
recursos comprometidos que no podrá solventar. La experiencia y las métricas obtenidas en
proyectos anteriores son útiles para hacer algún tipo de “estimación de mínima” de modo que se
pueda decir que las primeras o principales historias de usuario se pueden desarrollar en un tiempo
determinado.
A partir de ese tiempo, el cliente puede decir si continua o no agregando funcionalidad al

software.
El resumen. Un presupuesto y costeo preciso requiere un plan detallado a seguir. Si se acuerda

no trabajar guiándose por un plan, debe acordarse también no trabajar apegándose a costos
definidos de antemano. El desarrollador buscará satisfacer al cliente con entrega periódica de
software valioso; de modo que siga siendo beneficioso para el cliente seguir solventando el
proyecto.
42
Este es concepto de Retorno de la Inversión (ROI, por sus siglas en inglés). Esta métrica permite a las organizaciones
calcular si ha ganado dinero por las inversiones que realiza. Su fórmula más habitual consiste en restar a la ganancia
total, los costos de esta y dividir ese valor por los costos de la inversión. ROI = (Ganancia Total – Costos de la Inversión)
/ Costos de la inversión. Se busca que el valor sea positivo y lo más alto posible.
170
Para muchas organizaciones que se manejan presupuestos mas estrictos, o que deben
conseguir fondos de aplicación específica, por ejemplo, en casa matrices, esta es una de las grandes
trabas a la hora de encarar desarrollos en modelos ágiles.
Para finalizar, es importante decir que muchas organizaciones con el tiempo logran desarrollar
modelos empíricos de costos, basados en su propia experiencia que les permite mejorando el costeo
y fijación de precios.
9. Bibliografía
IAN SOMMERVILLE: Software Engineering. Tenth Edition. 2016. Pearson Education.

ROGER PRESSMAN: Software Engineering. Eigth Edition. 2015. Ed. McGraw-Hill.
171
11
Apunte 11
Decisiones estratégicas antes de desarrollar

software.
172
1. Introducción
En el apunte 2 de este libro, se plantea que todo desarrollo de software comienza con la
“Comunicación Inicial” entre el cliente y el desarrollador. Allí es donde se acuerdan los lineamientos
básicos del proyecto. Esto es una verdad, pero a medias.
Antes que una organización decida desarrollar un sistema, aparen una serie de alternativas
que deben considerarse. La primera es si realmente un software solucionará el problema que tiene
la organización. Luego deberá analizar si lo desarrollará o comprará hecho, si lo instalará en sus
servidores o lo usará desde la nube o, incluso, podrá pensar no usar software y tercerizar el proceso.
Conocer a fondo cada una de estas alternativas exceden el alcance de este apunte. La
tercerización (u outsourcing), por ejemplo, es un tema vasto y complejo del que se han escrito libros
enteros. Comprar software, otro ejemplo, implica conocer de políticas y contratos de licenciamiento
(en nuestra Carrera, materias como Derecho Informático se ocupan de ello). La propuesta de este
apunte no es abarcar discos temas a fondo, pero si alertar sobre la necesidad de tomar ciertas
decisiones estratégicas que, incluso, pueden derivar en que se desista de la idea de desarrollar el
software que se tenía pensado.
2. El software no siempre es la solución
No hace falta en este punto hablar de los beneficios que un sistema informático le trae a una
organización. No solamente porque puede hacer determinadas cosas más rápido, con menor costo
y operar con mayores volúmenes de datos, sino porque mejora el modo de trabajo de los
empleados, y ayuda a formalizar y ordenar los procesos de la organización.
Pero… ¿siempre son beneficios? Usar un sistema informático que, además de facilitar las
operaciones, estandariza procesos es algo bueno. Evitar, por ejemplo, que un empleado anote las
salidas de un depósito en un cuaderno según su propia codificación y criterio y, en lugar de eso,
pase a registrarlo de un modo estándar en un sistema, sin dudas es beneficioso para la empresa.
Pero si hacer esa registración genera una demora extra en entregar cada pieza y con eso se retrasa
la producción, hay que dudar de los beneficios.
Es necesario destacar los sistemas son cada vez más poderosos, pero no hacen magia ni
resuelven por sí solos los problemas de las organizaciones. Un mal proceso administrativo será
siempre malo, informatizado o no. A veces desarrollar software ayuda también a repensar un
proceso, a eliminar trabas, a hacerlo más rápido y eficiente. Pero otras veces no.
Quizá lo primero que hay que tener en cuenta es que los procesos manuales suelen ser
eficientes por naturaleza: nadie quiere más cosas que le requieran más esfuerzo que las necesarias.
Un sistema puede potenciarlo, puede hacerlo más rápido, puede mejorar el proceso posterior de
los datos, pero para ello, la aplicación no debería copiar exactamente al proceso manual.
Para comprender lo dicho, podemos usar como ejemplo la confección de cheques. Los datos
que se completan em un cheque de papel son los mínimos necesarios para poder transferir el dinero
173
a la persona que debe recibirlo. El escribir el importe dos veces, uno en letras y otro en números, es
un modo de dificultar que quien lo recibe, pueda cambiar el monto de la operación. Sin embargo,
ninguna aplicación bancaria copia ese modelo. Es innecesario pedir la fecha de esmision, no hace
falta escribir el monto dos veces (el receptor no puede cambiarla) y sería ridículo pretender una
firma ológrafa en un celular para validad la operación. Las APPs bancarias no copian fielmente la
operatoria manual, que es eficiente para el mundo físico, sino que la mejoran y la potencian a partir
de las posibilidades que da un entorno digital.
Un par más de ejemplos concretos quizá sirvan para comprender mejor el punto. El primero
es un caso personal:
Muchos años atrás, la empresa Lotus, famosa en el mercado por ser la desarrolladora de
una de las primaras planillas de cálculo que existieron, lanzó al mercado una agenda llamada Lotus
Organizer. El software era una agenda que copiaba al detalle a las agendas en papel, desde la
solapas hasta las hojas con anillas. Así se veía la agenda.
Más por una cuestión de modernidad que de practicidad, muchos comenzamos a usarla. Y
digo de practicidad porque, al menos las primeras versiones, no agregaban demasiada funcionalidad
a las agendas manuales. Pero además… tenía una gran contra: no era portable. Solo se instalaba en
una sola PC. Es decir que cada vez que se quería anotar una cita había que ir hasta la PC. Obviamente,
como no existía interner, la agenda de la PC de casa no se sincronizaba con la de la oficina. En el
mejor de los casos se la podía instalar en una notebook, pero había que cargarla a todos lados para
consultar la agenda. Mucho más complicado era su uso cotidiano: Cierta vez anoté la dirección de
174
un cliente al que debíamos visitar con mi socio43 y al llegar al edificio no recordábamos el piso. En el
hall de entrada tuvimos que abrir el portafolio, sacar la notebook, encenderla (y esperar a que
encienda), acceder a la agenda y ver el piso. Todo esto nos llevó unos 4 o 5 minutos de incomodidad,
sentados en la escalera. Consultar nuestra agenda en papel, que hasta entonces llevábamos en
nuestros bolsillos, nos hubiera permitido resolver el problema en segundos. Que un sistema copie
exactamente un sistema manual, sin agregarle ninguna funcionalidad, no suele ser buena idea.
Otro ejemplo tiene que ver con las estaciones de servicio. En un tiempo al terminar de cargar
combustible, se pagaba (con efectivo o tarjeta) y se seguía viaje. Hoy los playeros tienen que
registrar datos en un sistema, usando una computadora ubicada en un lugar incómodo, usando
mouse que no siempre suele estar en lugar más accesible (peor aun cuando se opta por pantallas
“touch” en lugares donde suele haber grasa y suciedad y los operadores usan guantes). Recién
cuando terminan el registro y desperdician montón de papel en tickets que van a la basura (algunos
son requisitos legales) se produce el cobro. Aun para pagar con QR, que debería ser inmediato, se
necesita esperar que se registre la operación. Supongo que sistematizar esta operatoria traerá algún
tipo de beneficio a las petroleras o dueños de la estación, pero lo cierto es que para el usuario solo
le significan demoras. Si registrar la operación en un sistema implica demorar la carga 2 minutos (y
en ocasiones demoran incluso más tiempo), cada 30 autos que carguen nafta, la estación de servicio
habrá estado inactiva por 1 hora.
Antes de pensar en desarrollar un sistema hay que pensar si los problemas que hoy tiene la
operatoria realmente se van a solucionar con ese sistema y, fundamentalmente, si no van a aparecer
otros. A veces, mejor que un nuevo sistema, es preferible usar mejor el que se tiene (sea manual o
informatizado). En otras ocasiones, bastará con cambiar el proceso administrativo. Pero siempre
hay que tener en mente que copiar en un sistema algo que anda mal, posiblemente lo haga andar
peor.
Por último, hay que analizar que software y aplicaciones tenemos disponibles actualmente
y si con dichas aplicaciones no basta para atender las necesidades. Los paquetes de ofimática44 son
cada vez más poderosos y permiten resolver cada vez más temas de la organización. Con Excel, se
pueden construir tablas y planillas que habitualmente son todo lo que un área necesita. Con Google
Forms se pueden generar formularios de carga Web para pedidos remotos, sin necesidad de tener
siquiera conocimientos en programación.
Los listados, las consultas, las diferentes salidas y modos de presentar la información
gerencial son uno de los temas centrales a la hora de diseñar software. Y es complejo de pensarlas
y diseñarlas. En primer lugar, por la alta volatilidad, frecuentemente se necesita agregar o quitar
algún dato de un listado, sumar un nuevo total, presentar un gráfico, etc. Pero también porque, a
medida que se va usando un sistema y se descubre su potencial, y se detecta que es posible obtener
más y mejor información que la que se pensó al comienzo. Hoy día podemos pedir que la única
salida que tenga un sistema es que permita exportar todos los datos a Excel y luego usar esa
herramienta para analizar todos los datos y presentarlos del modo que el usuario quiera.
43
Por aquel entonces, mi socio (y amigo) era el profesor Victor Veriansky, quien hoy me acompaña como docente en la
cátedra, y con quien compartí esta y muchas otras de las experiencias con las que aparecen en este libro.
44
Microsoft Office, Google WorkSpace o LibreOffice son algunos ejemplos de software que proveen valiosas
funcionalidades para empresas de todo tipo.
175
3. Desarrollar versus Comprar
Una vez evaluado el contexto y decidido que implementar un nuevo software es necesario,
la siguiente decisión que hay que tomar es si se va a desarrollar45 uno desde cero o se comprará
alguna solución que ya exista en el mercado. Incluso a veces ni siquiera hay que comprarla, porque
hay excelente software gratuito listo para implementar.
Un software desarrollado a media es sin dudas algo bueno para la organización. El sistema
hace todo lo que necesita la empresa y del modo en el cual lo hace. El software se adapta a la
operatoria y no al revés. Cumple con todos sus requisitos, inclusive los no funcionales y permite que
el operador lo personalice a su gusto.
Un buen traje, confeccionado a medida por un buen sastre, sin dudas nos hará lucir
impecables en una fiesta importante. Pero… ¿y si el sastre no resulta tan bueno como creíamos? O
quizá sea excelente y use las mejores telas importadas, pero sus costos son demasiado altos como
para poder págalo o justificar su compra. Incluso la realización y hechura puede demorar mucho y
ni estar listo a tiempo. Al menos conviene explorar si un traje estándar, comprado en una casa de
moda, no cumple razonablemente con el cometido. A lo mejor no me calza perfecto, pero me lo
puedo probar, ver cómo me queda, hacerle algún arreglo pequeño y tenerlo ya listo para la fiesta.
Seguramente será más barato y puedo destinar el dinero que me sobre a una nueva corbata y
zapatos.
A lo largo de todo el libro se ha podido ver que desarrollar software de calidad no es tarea
sencilla, tampoco barata. Si se encuentra un software ya desarrollado que cumpla razonablemente
con los requerimientos de la organización, a la larga, terminar siendo una mejor alternativa que
encarar una construcción a medida. Puedo implementar el sistema en forma más rápida e incluso
ahorrar dinero para poder, por ejemplo, actualizar el hardware.
Por supuesto, salvo que mi negocio opere de un modo muy simple y estandarizado, será casi
imposible encontrar un software en el mercado que cumpla con todos mis requerimientos. Algunos
autores indican que, si encontramos un software que cumpla con el 80% de los mismos, será mucho
mejor comprar, que desarrollar a medida. Otros incluso hablan de un porcentaje menor. Sin
embargo, hablar de porcentajes de cumplimiento tiene poco sentido. Ningún sistema, ni siquiera
uno desarrollado a medida, cumple con el 100% de los requerimientos. Entre otras cosas, porque
hay limitaciones tecnológicas, de costos y de tiempos. Pero ninguno pude dejar de cumplir aquellos
que son prioritarios y fundamentales para la organización. De qué sirve que un sistema de
facturación cumpla con el 95% de lo que necesita la empresa si resulta que no permite imprimir una
factura en las condiciones que se necesitan.
¿Qué cosas deben considerarse entonces a la hora evaluar de comprar o desarrollar

software? Roger Pressman en su libro Ingeniería de Software nos sugiere las siguientes preguntas:
45
El desarrollo podrá ser interno o encargado a un tercero. A los efectos de la decisión desarrollo compra, es indistinto.
176
1. ¿La fecha de entrega del producto de software será más próxima que la del software que
se desarrolle internamente?
2. ¿El costo de adquisición más el costo de personalización será menor que el costo que
implica desarrollar el software internamente?
3. ¿El costo del apoyo exterior (por ejemplo, un contrato de mantenimiento) será menor
que el costo del apoyo interno?
Del mismo modo, Ian Sommerville marca algunas ventajas a la hora de elegir utilizar lo que
el autor denomina Sistemas COTS46, pero que se refiere a lo que más comúnmente se lo conoce
como sistemas pre-planeados o, más comúnmente, enlatados:
• Implementación rápida de un sistema fiable, que ya está funcionando en otros clientes.
• Es posible analizar el software antes de implementarlo, y ver si es adecuado para mis

necesidades. Incluso se pueden comparar varias alternativas para ver cuál es el que
mejor se adapta a mis necesidades.
• Se evitan riesgos y demoras en el cumplimiento del plan de desarrollo y las fechas de

implementación.
• No deben dedicarse recursos al desarrollo de un nuevo sistema (aunque sí a la

personalización e implementación)
• El proveedor mantiene actualizado el software y corrige las fallas.
• Es posible utilizar software desde la nube.
Otra de las cosas se las que se saca beneficio al comprar un sistema ya desarrollado es que
la organización puede imponer las mejores prácticas respecto del modo en el que el sistema
resuelve determinados procesos. Cuando una empresa compra algún sistema de clase mundial,
como por ejemplo SAP, está adoptando los procesos estándares que dicha enpresa sugiere para
determinadas funcionalidades. Lo mismo ocurre cuando un banco incorpora un sistema que ya
utilizan otros bancos, incorpora las mejores prácticas del sector a su operatoria. Por supuesto estos
sistemas suelen permitir cambios y personalizaciones, e incluso elegir entre más de un modo de
operar.
46
COTS: Comercial-Off-The-Shelf. Refiere a aquellos sistemas comerciales que ya están listos para usar y que el usuario
puede tomar por si mismo de estante de una tienda. Hoy el software ya no se vende en tiendas, pero es el equivalente
a descargar de internet un software o instalar una aplicación y usarla, sin necesidad incluso de que el proveedor
intervenga.
177
Pero claro, también hay desventajas. Entre ellas podemos mencionar:
• La organización debe, aunque sea mínimamente, adaptarse al sistema y a la forma de

operar que este impone.
• Atado con lo anterior, para el usuario, la personalización es menor. Este comenzar debe
trabajar del modo en el que el proveedor del software pensó, que puede ser diferente e,
incluso, menos eficiente que el modo de trabajo actual.
• Ningún sistema enlatado va a cubrir el 100% de las necesidades. ¿Qué se hace con los
requerimientos no cubiertos? Algunos quizá sean requerimientos secundarios y quizá
pueda prescindirse de ellos. Otros no, y quizá sea necesario pedirle al proveedor que, en
el caso de ser posible, personalice nuestra versión para incluirlo. Esto pude suponer
salirnos de la línea estándar de actualizaciones y que cuando salgan nuevas versiones no
las pueda utilizar hasta que no sea compatible con mi personalización. Otra opción es
que no sea el proveedor quien construya la personalización, sino que sea el cliente, por
ejemplo, y como ya se mencionó anteriormente, utilizase Excel para armar alguna
consulta o presentar gráficos si el sistema comercial no los tuviera de fondo.
Nuevamente en este caso siempre hay riesgos de que actualizaciones futuras invaliden
el desarrollo hecho por afuera.
• Pérdida de diferenciación y de ventajas competitivas. Como ya se analizó anteriormente,

los sistemas potencian los procesos y usar un sistema diferente y mejor que el de sus
competidores supone hacer valer el modo distintivo que una organización opera.
• Se depende de proyecto de negocio de la empresa desarrolladora. Se supone que quien

tiene un software bueno y que pudo vender a varios clientes, va a seguir manteniendo,
adaptándolo y mejorándolo. Pero este puede no ser el plan del proveedor. Muchas
circunstancias lo pueden llevar a cambiar de estrategia, desde cuestiones
macroeconómicas y de mercado, hasta haber encontrado otro nicho de negocio que le
proporcione mayor rentabilidad. Incluso determinadas actualizaciones, como por
ejemplo las impuestas tras cambios de sistemas operativos, pueden requerir una
inversión muy grande que no esté dispuesto a realizar. Hay múltiples ejemplos, incluso
en proveedores tan importantes como Microsoft o Google, que dejan de ofrecer sus
productos, o al menos dejan de actualizarlos, y nuestro sistema queda virtualmente
abandonado. En el caso de sistemas comerciales, a veces se pueden hacer acuerdos que
permitan, en el caso de que el proveedor decida no continuar con el desarrollo de sus
sistemas, que la empresa que lo adquirió reciba el código fuente y la posibilidad de
continuar ella actualizando el software.
Para finalizar hay que recordar que también puede construirse un sistema a medida
comprando ciertos componentes y desarrollando otros, o integrar uno software comprado que haga
alguna funcionalidad, con otro a medida que se ocupe de otras. Determinados softwares enlatados
tienen módulos abiertos que permiten que desarrolladores externos programen personalizaciones
y agregados. Siempre hay que recordar la premisa de no alejarse demasiado de los estándares para
no quedar fuera de las actualizaciones.
178
Incluso si consideramos como sistema toda la organización, es frecuente encontrar empresas
que tienen algún software enlatado, por ejemplo, para la contabilidad, y después desarrollos a
medida para ventas al mostrador y que a su vez se integran con carritos de compra on-line.
4. “On Premises” versus “Cloud”
Otra de las cosas que habrá que definir es donde estará instalado el software. Sin entrar en
el análisis de los tipos de licenciamiento y sus diferentes costos, las opciones más comunes son
cuatro:
• On Premises47. En este caso tanto el software se instala y ejecuta computadoras de la

organización que utiliza el software. Toda la responsabilidad sobre el funcionamiento de
este recae en el cliente que, obviamente, deberá contar con la infraestructura necesaria
en cuanto a servidores y computaras para alojar el sistema y procesar la información.
También deberá contratar el personal de IT necesario para asegurar la operación y
solucionar eventuales fallas.
• “Cloud” o en la nuble. En esta modalidad el software que desarrollamos no reside en las

computadoras del cliente sino en alguna infraestructura tecnológica a la que se accede
vía internet. Esta infraestructura la puede proporcionar el propio proveedor, brindando
acceso remoto a sus servidores o la puede brindar un tercero especialista en estos
servicios. Por ejemplo, es posible montar el sistema en servicios en la nube como Amazon
Web Services o Microsoft Azzure, entre otros. Por supuesto en esta modalidad el cliente
de desentiende la infraestructura tecnológica y solo debe asegurar una buena
conectividad (si se corta internet, los sistemas estarán inaccesibles). A pesar de estar en
una nube compartida, el software es de uso exclusivo. En el caso de que el desarrollador
tenga más de un cliente, algo habitual, utilizará una copia diferente que alojará en
diferentes espacios de almacenamiento. Los datos de la empresa y sus backups, pueden
residir tanto en la nube como en modo local, o alguna alternativa mixta.
• SaaS: Software como servicio. Una alternativa parecida a la anterior es contratar no un

desarrollo de software propio sino utilizar uno genérico que abastece, vía Internet, a
muchos usuarios a la vez. En esta modalidad el cliente no adquiere el software
propiamente dicho sino la capacidad de utilizar los servicios que este provee, mediante
algún tipo de abono o contratación. A deferencia del modelo anterior, si bien los datos
se mantienen separados, el software es único para todos los clientes. Microsoft Office
365 es un ejemplo de este tipo de servicios. Un único software que presta servicios
simultaneo a miles de usuarios. Como en esta modalidad el software es único, cualquier
cambio que se le haga al mismo impactará instantáneamente en todos los clientes que
lo utilicen. El software se mantiene siempre actualizado y los errores suelen ser
solucionados en forma muy rápida. Los cambios mayores, en especial aquellos que
afectan significativamente el modo en el que se opera el sistema, suelen ser anunciados
47
Si bien suele pronunciarse o encontrarse escrito en singular, como “on premise”, el modo correcto de utilizar este
término en inglés es con su forma plural: “on premises”
179
con anticipación, e incluso se pueden proveer versiones de entrenamiento para que el
usuario se anticipe al cambio.
• En un servidor propio e individual, pero instalado físicamente en las instalaciones del

proveedor. Esta opción permite que el desarrollador se ocupe de la infraestructura y de
la actualización del software, pero, al estar en un servidor diferente al resto, da una
garantía adicional en cuanto a la privacidad de los datos. También de este modo el cliente
se asegura mayor performance y velocidad de respuesta, ya que el software reside en un
servidor dedicado exclusivamente a atender su operatoria, sin compartirlo con los demás
clientes del proveedor. A medida que las nubes públicas se van volviendo más seguras,
rápidas y confiables, esta operación es cada vez menos utilizada.
Está claro que cada una de estas opciones presenta ventajas y desventajas. Ser dueño
exclusivo de un software y de su operación sin dudas es la opción más segura para que nada caiga
en manos de terceros o de competidores, pero también requiere pagar un alto costo para mantener
la infraestructura.
Compartir un software instalado en la nube con otros clientes hace que la empresa pierda el
control total de sus datos y su operación, pero también ahorra costos y se asegura de contar siempre
con un software que recibe de modo prioritario las mejoras y actualizaciones.
5. Tercerización (outsourcing)
La tercerización u outsourcing implica contactar a un proveedor para que se haga cargo de

todo el proceso. No se desarrolla un sistema. Tampoco se compra. No siquiera se usa como servicio,
sino que directamente toda la operatoria pasa a un tercero.
Por diversos motivos esta opción es cada vez menos frecuente. Uno de los principales era la
ventaja de no tener que ocuparse de un desarrollarlo propio ni de mantener una infraestructura
informática, cosa que hoy se soluciona, por ejemplo, con un modelo SaaS.
Sin embargo, no deja de ser una alternativa válida, en especial cuando el proveedor del
servicio, además de operar el sistema, le agrega valor a la operación. Por ejemplo, muchas empresas
pequeñas en lugar de contar con un sistema de haberes, delegan la operatoria en un tercero,
generalmente, un estudio contable. De este modo no solo se desentiende del sistema, sino que
tampoco tiene que contar con personal especializado en liquidar sueldos. A fin de mes simplemente
reciben los recibos y demás documentación respaldatoria, que fue procesada con el sistema del
estudio.
Hoy día es más frecuente encontrar modelos híbridos que completamente tercerizados. Por
ejemplo, es habitual que el sistema sea operado en su totalidad por un tercero pero que parte de la
operatoria la haga el propio usuario. Volviendo caso de sueldos, es posible que de toda la operatoria
se ocupe el estudio contable, pero que las novedades mensuales (licencias, altas, horas extras, etc.)
las cargue el propio cliente.
Otro ejemplo que, si bien no es una tercerización tradicional, pero podría caer en esta
operaria son las plataformas de ventas por internet. La empresa no desarrolla ni mantiene un
180
sistema de transacciones on-line, sino que terceriza toda la operatoria en Amazon o Mercado Libre,
aunque mantiene parte de la operación como es la carga de artículos, precios y stock48.
6. Conclusión
Para las organizaciones, los beneficios de implementar un software son innegables. Es difícil
imaginar una área o proceso que no pueda ser mejorado o potenciado con un sistema informático.
Sin embargo, antes de tomar la decisión de construir un software, es necesario poner sobre
la mesa una serie de temas que incidirán sobre el tipo de proyecto que deberá encarar la empresa.
En algunas ocasiones, incluso, hasta puede determinarse que un nuevo desarrollo no servirá para
resolver sus problemas ni mejorar el desempeño de un área. Continuar con el sistema actual, aun
cuando este sea manual, podría ser una alternativa.
7. Bibliografía

48
Los modelos de negocios de las plataformas de venta on-line como Mercado Libre o Amazon, son mucho más
complejos y abarcativos como para pensar en una siempre tercerización. Sin embargo, simplificándolos y desde el
alcance de este apunte, bien pueden ser como ejemplos de una moderna forma de outsourcing: La empresa no
desarrolla ni opera el software, sino que terceriza toda la operación de venta on-line, desde su publicación, venta,
cobranza y a veces hasta la entrega. La empresa solamente se ocupa de cargar las novedades (nuevos artículos, precios
o stock) como lo haría en un sistema de sueldos.
181
Licencia, acuerdo de uso y distribución:
El presente libro ha sido pensado como material de lectura complementario a la bibliografía de las materias
de la Facultad de Ciencias Económicas de la UBA. Puede ser distribuido libremente con fines educativos,
quedando prohibida cualquier tipo de comercialización o lucro. Al distribuirse, no debe alterarse el formato
y/o contenido original.
Compilación de Apuntes sobre Ingeniería de Software © 2021 by Cesar Ariel Briano is license
under CCBY-NC-ND 4.0
182

Compilacion de Ingenieria de Software PDF

Cargado por

Copyright:

Formatos disponibles

Compilacion de Ingenieria de Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Compilacion de Ingenieria de Software PDF

Cargado por

Copyright:

Formatos disponibles

Con una visión

Lic. César Ariel Briano

Archivo Digital: descarga y online

1. Ingeniería de Software. I. Título.

Este libro está disponible gratis on-line en https://briano.com.ar/libro

Finalmente, cabe aclarar que esta compilación no es un resumen de ningún libro, ni de la

Apunte 3 Conceptos Fundamentales del Desarrollo Ágil de Software ............................. 45

Apunte 4 Ingeniería de Requerimientos Claves para un desarrollo exitoso ..................... 71

Apunte 5 Conceptos Fundamentales del Diseño de Software ......................................... 87

Apunte 6 Conceptos Fundamentales de la Codificación de Software ............................ 110

Apunte 7 Conceptos Fundamentales de las Pruebas de Software ................................. 120

Apunte 8 Conceptos Fundamentales del Despliegue de Software ................................. 135

Apunte 9 Conceptos Fundamentales del Mantenimiento de Software .......................... 148

Apunte 10 Conceptos Fundamentales de la Estimación, Costeo y Precio del Software .. 160

Apunte 11 Decisiones estratégicas antes de desarrollar software. ................................. 172

Licencia, acuerdo de uso y distribución .......................................................................... 182

El desarrollo de software se ha vuelto central en nuestros días. Las organizaciones necesitan

Por si faltaban ejemplos, la pandemia puso en evidencia como nunca en la historia, la

En épocas de virtualidad, también comprendimos el rol primordial del software en las

En el Blog del Museo de Informática de la Universidad Politécnica de Valencia se encuentra

Los sistemas no podían tener resultados azarosos o depender de la pericia de un

3. El software: Un producto ubicuo, indispensable y vital

• Permite la creación de nuevas tecnologías (ej. Ingeniería genética).

• La inteligencia artificial potencia la investigación y la capacidad humana. (ej. nuevos

• Dejó de ser un producto empresarial para convertirse en un producto comercial, se

• El software tiene un doble valor: es un producto en sí mismo, pero a la vez, la herramienta

El Boeing 787 podría pararse de repente por error software

Las tragedias aéreas, desgraciadamente, están sucediéndose con demasiada

Una revisión invalida miles de estudios del cerebro.

El Banco Nación duplica créditos y débitos de sus cuentas

Por un error informático, aparentemente vinculado a la Red Link, las operaciones

4. La naturaleza del software

1. El software se desarrolla o modifica con el intelecto; no se manufactura en

Aunque hay algunas similitudes entre el desarrollo de software y la fabricación

Ambas actividades dependen de personas, máquinas y herramientas, pero la relación

2. El cálculo de costos es distinto y no siguen un esquema tradicional.

En cambio, en el desarrollo del software todo el costo se lo lleva la primera unidad.

3. La mayor parte del software se construye para un uso individualizado,

A medida que evoluciona una disciplina, se crean un conjunto de componentes

En software, a pesar de facilidades de reutilizar el mismo componente para otro

Es importante destacar, conforme lo analizado en el punto anterior, que los mayores

También hay que mencionar que no estamos ante un proceso de reciclado o de

La curva de la siguiente figura muestra como los errores de programación, no detectados

Ya hemos mencionado la importancia del software en la actualidad. Esta enorme industria

1) Se demora mucho tiempo en desarrollar software. Habitualmente, más de lo previsto. No

3) Es difícil medir el avance del proyecto mientras se desarrolla o mantiene el software.

Un sistema informático requiere de tres componentes básicos que interactúan ente sí

Michael Porter publicó en 1985 su libro “Ventaja Competitiva: Creación y sostenimiento de

“Es el establecimiento y uso de principios solidos de la ingeniería para obtener

“Es el estudio de los principios y metodologías para desarrollo y mantenimiento de

“Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo

• La ingeniería de software es una disciplina de ingeniería que se interesa por todos

• Las ideas fundamentales de la ingeniería de software son aplicables a todos los

• Los ingenieros de software tienen responsabilidades con la profesión de

• Las sociedades profesionales publican usualmente códigos de conducta que

8. El proceso de desarrollo del software

A modo general, y de un primer acercamiento (más adelante se perfeccionará este esquema)

2. Análisis de los requerimientos y su viabilidad:

3. Diseño general y detallado: