COMPENDIO DE GUIAS DIDACTICAS

Materia: Ingeniería de Software

Cátedra: Cesar A. Briano
1er cuatrimestre 2022

Guía 1: Software e Ingeniería de Software

Guía 2 - El proceso del Software
Guía 3 - Desarrollo dirigido por un plan
Guía 4 - Desarrollo Ágil
Guía 5 – Ingeniería de Requerimientos
Guía 6 - Claves relevamiento exitoso
Guía 7 – Diseño
Guía 8 - Codificación
Guía 9 - Prueba de Software
Guía 10 - Despliegue - Evolución
Guía 11 – Gestión de la Calidad
Guía 12 - Riesgos
Guía 13 – Confiabilidad y Seguridad
Guía 14 - Gestión del proceso de software
 1
PUNTOS CLAVES
La importancia del software
Los problemas al desarrollar software
Las características del software y la
particularidad de su desarrollo
La ingeniería de Software
Ética en el desarrollo de software
BIBLIOGRAFÍA
Libro de Sommerville: Capítulo 1
(salvo el estudio de caso)
Libro de C. Briano: Apunte 1
Código de Ética 2018 – ACM
El libro de apuntes NO reemplaza, sino que
complementa a Sommerville. Ambos son
lectura obligatoria.
VIDEO
https://bit.ly/2QxYrtN
Es fácil encontrar ejemplos de cómo el software y las aplicaciones
informáticas han cambiado aspectos claves de nuestra vida. Cada
vez con mayor frecuencia vemos que productos cotidianos “se
vuelven inteligentes” a partir de tener software embebido
(celulares, televisores, juguetes, hasta autos autónomos).
También es fácil encontrar los problemas que nos genera el
software cuando falla… desde no poder encontrar a nuestros
amigos si el Whatsapp no funciona o pagos que no podemos hacer,
hasta aviones que se pueden accidentar. Cuántas veces hay
trámites y cosas que no podemos hacer porque “se cayó el
sistema”. Ni siquiera podríamos estar cursando esta materia sin el
sistema de inscripciones o el campus virtual.
No es exagerado ni alarmista asegurar que desarrollar y/o utilizar
software que no sea de calidad pone en riesgo de modo directo la
salud, la seguridad, los derechos, los bienes o la formación de los
habitantes. Y en tal sentido, existe una responsabilidad para todos
los profesionales de la industria del software respecto de asegurar
que el mismo se construya con la mayor calidad posible. La ética
profesional debe ser aplicada y el rol de los Consejos Profesionales
se vuelven cada vez más necesarios.
Es preciso también analizar la naturaleza propia de la construcción
del software, que tiene particularidades que lo hacen diferente a la
producción clásica de otros bienes. EL software no se produce en el
sentido clásico, es decir transformando materias primas en un
producto terminado. Tampoco sus costos siguen un esquema
tradicional: La primera unidad se lleva todo el costo de
investigación y desarrollo, las subsiguientes prácticamente son a
costo cero. La amortización y desgaste también son particulares y
diferentes. Esto genera que el desarrollo de aplicaciones
informáticas se enfrente a desafíos distintos a los que aparecen en
la industria tradicional.
La Ingeniería de Software surge entonces como una disciplina que
busca que se desarrolle software bajo un paradigma de calidad,
construyendo aplicaciones confiables, seguras y que se generen
dentro de un proceso de trabajo sustentable y ético.
 2
PUNTOS CLAVES
Las etapas generales del proceso de
software
Especificación del software
Diseño e implementación del software
Validación del software
Actividades protectoras de la calidad
BIBLIOGRAFÍA
Libro de Sommerville: Capítulo 2
(Salvo puntos 2.1, 2.3.3 y 2.4)
Libro de C. Briano: Apunte 1, pto. 8
El libro de apuntes NO reemplaza, sino que
complementa a Sommerville. Ambos son
lectura obligatoria.
VIDEO
https://bit.ly/3jpbN82
Cuando se construye cualquier cosa hay que seguir algún proceso
específico. Esto asegura que el producto final cumpla con todos los
requisitos y que tenga la calidad adecuada.
Por ejemplo, al construir casas, se parte de ver qué tipo de vivienda
es la que quieren las personas que vayan a vivir en ella. Luego de
desarrollan los planos necesarios, que incluyen todos los detalles
necesarios para edificarla, por ejemplo, la medida de las puertas
ventanas. Finalmente se comienza la construcción, siguiendo esos
planos. Si no se siguieran los pasos de construcción en determinado
orden y, por ejemplo, si se colocaran las ventanas al inicio,
seguramente los vidrios se romperían durante la construcción.
Los mismo pasa para construir software. Hay que seguir
determinados pasos que comienzan con la comunicación con el
cliente para ver lo que necesita, la elaboración de planos (Diseño)
y finalmente el desarrollo (Construcción) propiamente dicho. Por
supuesto hay además pruebas y controles de calidad, que aseguran
el proceso.
Somerville destaca 4 grandes etapas para desarrollar software:
• Especificación: donde se busca comprender y definir qué
servicios se requieren del sistema, así como también la
identificación de las restricciones sobre la operación y el
desarrollo.
• Diseño e implementación: una descripción de la estructura
del software que se va a implementar, los modelos y las
estructuras de datos utilizados por el sistema, las interfaces
entre componentes del sistema y, en ocasiones, los
algoritmos usados.
• Validación: en la que se buscará demostrar que un sistema
cumple tanto con sus especificaciones como con las
expectativas del cliente.
• Evolución: una vez implementado el software, este seguirá
siendo modificado para que siga respondiendo a la
organización y su contexto durante su vida útil.
Como ya hemos dicho, la Ingeniería de Software busca asegurar la
calidad de la aplicación construida. Es por eso por lo que no basta
con seguir y respetar los procesos de construcción, sino que, en
forma paralela, deben ejecutarse una serie de actividades
protectoras de la calidad, que se ocuparán de fortalecer los
procesos, verificar que se cumplan los estándares y que todo el
proceso de realice dentro de un entorno controlado y repetible.
Por último, es importante mencionar que la variedad de software
de todo propósito que se construye hoy día hace difícil suponer que
exista un único proceso que pueda seguirse como guía. No existe el
proceso ideal ni nada que se le parezca. También pasa que un
proceso que funciona adecuadamente en una organización no
funciona para otra. Es por eso por lo que, en las siguientes
unidades, abarcaremos diferentes procesos de construcción.
 3
PUNTOS CLAVES
Desarrollo basado en un plan vs.
Metodologías Agiles.
Una propuesta integral: Se
complementa el enfoque tradicional al
que refieren diversos autores con una
serie de etapas previas y posteriores
al proceso propiamente dicho pero
que son parte integrante fundamental
en un desarrollo de software.
Los diferentes problemas y como cada
modelo resulta más apropiado para
resolverlo
Diferentes Modelos: Sus etapas, sus
ventajas y desventajas, para que tipo
de proyectos conviene usarlo y sus
particularidades
BIBLIOGRAFÍA
Libro de Sommerville: Capítulo 2
Libro de C. Briano: Apunte 2
El libro de apuntes NO reemplaza, sino que
complementa a Sommerville. Ambos son
lectura obligatoria.
VIDEO
https://bit.ly/3b2SEWI
A ninguno de ustedes se le ocurriría construir una casa comprando
ladrillos y cemento, viendo algún tutorial de como armar paredes y
poniendo manos a la obra. Saben de antemano que una casa
construida de ese modo va a caerse en la primera tormenta o,
simplemente, quizá no aguante el peso de los muebles y se venga
abajo.
Sabemos que para construir una casa hay procedimientos
formales, pasos que deben cumplirse. Todos sabemos que primero
hay que hacer un plano, luego un estudio del suelo, más tarde
comenzar por los cimientos, que, aunque no los veamos son
decisivos para la estabilidad de la casa. Luego se construye la
estructura con vigas y hormigón, más tarde se levantan las paredes
y el techo. Todos sabemos que los vidrios son lo último que se pone
(para evitar que se rompan durante la construcción) y por supuesto
la pintura será el último paso antes de que vayamos a vivir en ella.
¿Se pueden construir casas alterando las etapas? Si. Pero durante
los miles de años en las que lo hacemos hemos acumulado
suficiente experiencia como para saber que si pintamos al
comienzo cuando entremos, esa pintura estará dañada.
Todo este conocimiento se fue formalizando en una disciplina que
llamamos Ingeniería Civil (que obviamente comprende muchas
más cosas que las enunciadas).
Pero también sabemos que no todas las casas son iguales. Que en
el polo norte no tenemos cemento, pero sí hielo y que es posible
construir iglúes. Es las zonas de bosques la madera abunda y esta
también es buena para construir casas. Los grandes rascacielos
están sometidos a fuertes vientos y son sensibles a los movimientos
terrestres y, por lo tanto, necesitan estructuras especiales. En
zonas sísmicas, por ejemplo, se usan vigas más grandes y acero
para que se aumente la resistencia. En muchos casos la
construcción en seco (Durlok) tiene ventajas significativas en
cuanto a la velocidad y costo de la obra. Diversos problemas,
diversas respuestas. La ingeniería no tiene un único modelo de
construcción, sino que propone diversas respuestas frente a los
problemas que debamos enfrentar.
La construcción de software sigue el mismo paradigma. Por un
lado, debe seguirse algún modelo de desarrollo ya probado. Por el
otro no hay un único modelo sino varios que se adaptan a los
diversos escenarios en las que se construyen aplicaciones. Estos
modelos son propuestos por la Ingeniería de Software.
Esto es lo que encontraran en el apunte con una especial aclaración
final: Los modelos no son estáticos. A veces deben mezclarse. Al
igual que podemos construir una casa de modo tradicional y usar
Durlock para alguna de sus partes, también es posible que en su
vida profesional utilicen algún modelo base y le incorporen alguna
etapa también de otro modelo. Por ejemplo, podrían usar un
modelo lineal secuencial, pero realizando un análisis de riesgo en
algún momento.
 4
PUNTOS CLAVES
Metodología Ágil versus modelos
tradicionales
El Manifiesto Ágil y los principios que
guían el desarrollo ágil.
El modelo Scrum.
El modelo de Programación Extrema.
Ventajas, dificultades y limitaciones
de los desarrollos ágiles.
Casos de estudio.
BIBLIOGRAFÍA
Libro de Sommerville: Capítulo 3
Libro de C. Briano: Apunte 3
Manifiesto Ágil de Software
http://agilemanifesto.org/iso/es/manif
esto.html
El libro de apuntes NO reemplaza, sino que
complementa a Sommerville. Ambos son
lectura obligatoria.
VIDEO
https://bit.ly/3lvEUZd
“Desarrollo Ágil” versus “dirigido por un plan” … ¿Cuál Conviene?
Desarrollo Ágil parece un paradigma más moderno y que
acompaña el cambiante mundo actual. ¿Es así? ¿Reemplaza al
anterior?
Daria la impresión que el mundo va hacia desarrollos ágiles. La
razón: estamos en un contexto cambiante en el cual es difícil
imaginar que pueda planificarse un sistema completo en el
momento cero y luego desarrollarlo atado a ese plan, sin cambios.
Cuando ese sistema se entrega, después de varios meses… ¿La
realidad de la organización será la misma?
Esta afirmación es cierta pero solo en partes. Las organizaciones
no cambian necesariamente sus procesos al ritmo del contexto.
Son muchos los casos en donde el usuario debe adaptarse a la
organización y no al revés.
¿Entonces? Resulta que ambos modelos son válidos. Los
tradicionales servirán bien en empresas que tengan procesos
estáticos o se enfrenten a escenarios más estables. Pero aquellas
que enfrentan contextos variables, que tengan estructuras
flexibles y que se amoldan a lo que pasa afuera, no pueden trazar
un plan rígido para desarrollar software. Simplemente porque no
tienen un plan estático para ninguno de sus procesos internos.
En estos casos desarrollar software siguiendo el modelo ágil es la
solución. El software no se piensa completo al comienzo, sino que
se va desarrollado en iteraciones sucesivas que van a agregando
nuevas funcionalidades a medida que se va utilizando el software.
El usuario participa activamente del equipo de desarrollo y va
sugiriendo las nuevas necesidades.
Estas imágenes ayudan a estos conceptos:
Metodologías Tradicionales Metodologías Ágiles
Requisitos definidos al inicio. No existe una especificación inicial detallada
del sistema.
Cierta resistencia a los cambios. Especialmente preparados para cambios
durante el proyecto.

El sistema se entrega en forma completa al El sistema está siempre en desarrollo.

finalizar el proyecto.

El cliente interactúa con el equipo de desarrollo El cliente es parte del equipo de desarrollo.
mediante reuniones.

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

Útiles para organizaciones que operan en Útiles para organizaciones que operan en
entornos estables. entornos cambiantes
Con normas y procesos definidos de antemano Con procesos flexibles

Para software con funcionalidades críticas Donde los cambios del software son
bienvenidos
Claro que, para trabajar en este tipo de desarrollos, deben relajarse algunos procesos. La
documentación, por ejemplo, no es tan exhaustiva y no suele cumplir con requerimientos de
manuales detallados. La seguridad, otro ejemplo, a veces es menor, y no porque no pueda construirse
software seguro de este modo, sino porque el hecho de que el sistema este en constante cambio
necesariamente lo hace más vulnerable. Esto hace que las metodologías ágiles sean inviables de
aplicar en determinados escenarios o donde deban cumplirse rigurosas normas externas.

Como resumen les dejo una frase extraída del libro de Sommerville: “La decisión acerca de si se usa
un enfoque de desarrollo ágil o uno basado en un plan depende del tipo de software que se va a
elaborar, las capacidades del equipo de desarrollo y la cultura de la compañía que diseña el
sistema.”
 5

Este “meme” describe de un modo muy acertado un escenario

PUNTOS CLAVES lamentablemente muy frecuente en el desarrollo de software. Un
escenario donde, aun cuando el software termina construyéndose
Ingeniería de Requerimientos vs. con éxito, no alcanza los resultados deseados por la organización.
Relevamiento

Requerimientos funcionales y no
funcionales

Especificación de los requerimientos

(tema que se profundiza en
metodología)

El proceso de adquisición de
requerimientos y su análisis

Técnicas para adquirir relevamientos

Validación de requerimientos

¿Como es posible que las necesidades reales sean tan diferentes a

BIBLIOGRAFÍA
las que el usuario describe? ¿Cómo es posible que imagine recibir
una montaña rusa si solo dijo que necesitaba un columpio? ¿Por
qué el analista plantea una solución imposible sin que nadie lo
Libro de Sommerville: Capítulo 4
detecte? ¿Por qué la solución programada no puede usarse? Todo
esto termina en que se termina instalado algo intermedio… que
más o menos sirve para lo que el usuario necesita, pero realmente
nadie sale ganando con esto.

La pregunta entonces es… ¿De quién es la culpa?

VIDEO Lo primero que seguramente viene a la mente es que la culpa es
del usuario, que él no pidió realmente lo que necesitaba… Pero no,
la culpa nunca es del usuario. Y no lo digo porque eso de que “el
https://bit.ly/31CivBF cliente siempre tiene la razón”

Sucede que el usuario no estudió nunca ingeniería de software.

Conoce su tarea, sabe usar sistemas, pero no tienen idea de cómo
se desarrollan, ni de como pedir las cosas. Es justamente por eso
que contratan a un/a profesional. Los profesionales son
responsables de obtener los requerimientos de un modo efectivo.
Son los que han estudiado y tienen los conocimientos para hacerlo.

Hay 4 conceptos clave vinculados a la obtención de

requerimientos:

1. La obtención y comprensión de requerimientos es una de

las tareas más difíciles de la ingeniería de software.
Porque se trata de analizar usuarios y estos son personas
que tienen realidades complejas. No todos tienen la misma
visión de su trabajo, no todos salen beneficiados con la
implementación de un nuevo sistema, no todos saben
expresar con claridad lo que necesitan. Algunos pueden
 imaginar mejores formas de hacer las cosas, otros no. Quizá no todos deseen lo mejorar la
organización para la que trabajan. Incluso, y esto también pasa, algunos pueden salir
perjudicados a partir de la implementación de un nueva. Cuando se buscan los
requerimientos, es importante ver desde que lugar actúa cada usuario.

2. El nombre Ingeniería de Requerimientos es más apropiado para esta etapa que como se lo
conoce habitualmente: Análisis o Relevamiento. ¿Por qué? Porque los requerimientos hay
que construirlos. No basta con relevar o analizar “solo lo que me muestran” …. Hay que
indagar, ir más allá de lo superficial. Deben ser completos y debemos asegurarnos de que
todas las partes del futuro sistema fueron alcanzadas y que no hay dudas, ambigüedades ni
agujeros. Y si algo falta o el usuario desconoce, debo encontrar fuentes alternativas para
resolver mis dudas.

3. No caer en la tentación de empezar a construir pensando en que las cosas se aclaran mejor
mientras se desarrolla la aplicación. Lo que no se releva finalmente terminan resolviendo
los programadores como ellos creen, y no necesariamente del modo correcto. Se puede
avanzar rápido en la generación de código que finalmente habrá que rehacer o descartar.

4. Esta tarea debe adaptarse a las necesidades del proyecto. A veces se elige un enfoque
abreviado, a veces se lleva a cabo con mayor rigurosidad. Hay organizaciones y usuarios que
están acostumbrados a ser relevados, otros no. A veces es necesario complementar lo que
ellos dicen con documentación, normativa u otras experiencias. Incluso a veces cuando se
diseñan sistemas genéricos, no hay usuarios para relevar (ej. Cuando se lanzan una nueva
App al mercado)

También es necesario tener en cuenta que hay requerimientos funcionales (son los que describen
los servicios que proveerá el software) y no funcionales (aquellas limitaciones, estándares y
restricciones que el sistema debe cumplir). No siempre se presta atención a estos últimos y son tan
importantes como los primeros. Una organización puede requerir que se desarrolle el software
usando alguna base de datos especifica o algún lenguaje de programación particular. También puede
pedirnos que utilicemos determinados colores para las pantallas porque es el color institucional y no
otros porque es el de la competencia. A este tipo de cosas no se le suele prestar atención, pero a
ninguno se le ocurriría instalar un software con pantallas azules y amarillas en River. (Y viceversa)

Respecto de las estrategias de obtención hay muchas (entrevistas, cuestionarios, escenarios, casos
de uso) algunas más efectivas que otras. Pero de nuevo… siempre será más efectivo usar aquellas a
las que los usuarios estén más acostumbrados en la organización. Y no debe olvidarse tampoco el
análisis de la documentación existente. El modo que funciona hoy la organización es válido y es un
excelente punto de partida.

Finalmente, todo esto termina en un documento de requerimientos del software. Este documento
debe contener todo el detalle necesario para que los diseñadores comprendan las necesidades del
usuario de modo que puedan la mejor solución para ellas. El documento final debe contener:

• Servicios que se ofrecerán al usuario.

• Panorama de alto nivel de la arquitectura del sistema.
• Requerimientos funcionales y no funcionales 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, requisito de hardware.
Por último… lo más importante de todo…este documento debe ser validado por el usuario y debe
estar firmado por él. Esto nos asegura dos cosas.

1. Que hayamos comprendido bien lo que el usuario quiere y que no está faltando nada.
2. Más adelante servirá para zanjar diferencias y que evitar cuestiones del tipo “Al sistema le
falta tal cosa… ¿te acordad que lo hablamos?” Nada de recuerdos o cosas orales… lo que se
necesita tiene que estar explícitamente detallado. Si algo nos olvidamos, ahora si ya pasará
a ser responsabilidad compartida con el usuario.
 6

Si bien explicamos anteriormente porque preferimos adoptar el

PUNTOS CLAVES nombre de Ingeniería de Requisitos para referirnos a esta etapa, lo
cierto la tarea principal de la misma consiste en relevar información
Conceptos destacados de la etapa de que permita detectar los problemas deben solucionarse con el
relevamiento nuevo software a construir. Para ello se analizará documentación y
se entrevistará a usuarios para que nos cuenten como desarrollan
Los problemas habituales a los que sus actividades y cómo funcionan los procesos de la organización.
nos enfrentamos
La bibliografía sobre el tema da cuenta de las características de la
Escenarios hostiles etapa y analizan las diferentes herramientas que tienen a su
disposición los analistas para obtener información de los usuarios
(entrevistas, cuestionaros, construcción de casos de uso, etc.), pero
Mitos de la etapa
no suelen explayarse sobre las dificultades de esta etapa.
Un enfoque alternativo y
Hay una serie de situaciones que, o bien complican en
complementario
relevamiento, o bien distorsionan los datos obtenidos al punto de
invalidarlo:

• Los usuarios relevados son personas que tienen diferentes

BIBLIOGRAFÍA posturas e intereses personales respecto de la
organización en la que trabajan y del nuevo sistema a
construir. También puede ocurrir que aun cuando tengan
Libro de C. Briano: Apunte 4 una actitud positiva, no sean claros al momento de explicar
sus necesidades.

• Las organizaciones son sistemas complejos, atravesados

por múltiples factores internos y externos y que no están
exentas de presentar diferencias internas (jefes
enfrentados, celos personales o intereses políticos, por
VIDEO ejemplo)

https://bit.ly/3gF1VFF • Los analistas pueden tener dificultades en comprender el

vocabulario propio de una actividad, comprender los
procesos organizacionales o al analizar los documentos
técnicos o de registración contable que se le presenten.

• Si el software a desarrollar es una ampliación que

novedosa que no existe en el mercado o es genérica (no
desarrollada para una organización en particular) es
posible que no existan usuarios a quien relevar.

El apunte “Claves para un relevamiento exitoso” presenta una

recorrida por varios de los problemas que aparecen relevar
requerimientos para el desarrollo de software, avanza sobre
algunas falsas algunas creencias y, finalmente, propone un enfoque
alternativo para realizar esta etapa. Se busca de este modo
complementar el uso de las herramientas tradicionales, mejorando
la calidad de la información obtenida y, por ende, posibilitar un
mejor diseño de la solución informática.
 7
PUNTOS CLAVES
Características de la etapa de diseño
El diseño de la interfaz de usuario
Patrones de diseño
El valor económico del diseño
BIBLIOGRAFÍA
Libro de C. Briano: Apunte 5
Las 8 reglas de oro para el desarrollo
de la interfaz de usuario. Ben
Shneiderman, Designing the User
Interface:
https://www.cs.umd.edu/users/ben
/goldenrules.html
https://webdesign.tutsplus.com/es/
articles/8-golden-rules-for-better-
interface-design--cms-30886
VIDEO
https://bit.ly/2D6YolC
Una vez terminada la etapa de Ingeniería de Requisitos, y
detectados aquellos problemas que la organización desea resolver
mediante la construcción de un nuevo sistema, se pasa a una etapa
donde los técnicos comienzan a diseñar una solución informática
que pueda satisfacer las necesidades planteadas con eficiencia.
¿Siempre el software se construye ante problemas? En un sentido
amplio sí. Las computadoras y los programas informáticos son
herramientas que utilizamos para resolver de un modo más
eficiente alguna tarea que sería problemático resolver sin ellas.
Esto puede ser, por ejemplo, hacer un proceso de un modo más
rápido, hacerlo de un modo más preciso, gastando menos recursos,
hacerlo de un modo más seguro, o simplemente para tener un
mayor control del proceso.
No siempre la solución a un problema es implementar un sistema
y no siempre un sistema desarrollado soluciona los problemas, en
especial si no fue bien diseñado. Recuerdo, por ejemplo, un
software utilizado por una red importante de estaciones de servicio
que, para hacerle descuento al socio, acreditar los puntos en la
tarjeta de fidelidad de la petrolera y, finalmente, cobrar con crédito
o débito; demoraba más de 6 minutos y usaba 2,50 mts papel para
imprimir por original y duplicado los comprobantes de la
operación. Evidentemente una solución mal diseñada que, además
de un impacto ecológico negativo, le hacía perder 1 hora operación
cada 10 autos que cargaban nafta. Ese mismo proceso fue ahora
rediseñado y se implementó una nueva solución informática que
resuelve el mismo problema en 15 segundos y sin papel mediante
el pago vía QR.
La etapa de diseño es entonces aquella donde se piensa de qué
manera el software operará para resolver las necesidades
planteadas. Y claro… como ese diseño deberá ser luego construido,
deberá pues ser hecho con determinados diagramas y notación
estándar para que después cualquier programador sea capaz de
interpretarlo y, por ende, de programarlo.
En cierto modo, la etapa de diseño equivale a la construcción del
plano de la casa. Es ese caso el cliente tiene determinadas
necesidades (una casa con 3 dormitorios, uno en suite, living
comedor, cocina integrada, un sótano para guardar cosas y un
garaje con espacio para dos autos). El arquitecto con esta
información (requerimientos funcionales), con información
adicional que tiene del cliente: son personas mayores y no quieren
subir escaleras, les gustan los ambientes luminosos y les gustan los
hogares a leña, (requerimientos no funcionales) arman un plano de
la casa. Esa casa tendrá una sola planta, grandes ventanales y por
supuesto un hogar a leña en el comedor. A veces también harán
una maqueta (prototipo) que le servirá tanto al cliente como al
constructor para aclarar algunas dudas respecto de determinados
aspectos.
El diseñador entonces entregará al programador un plano detallado de todos los componentes que
tendrá el software, explicando cómo debe funcionar cada uno de ellos y que restricciones tendrán.
Como utiliza diagramas estándares (al igual que el plano de la casa tiene convenciones que indican el
ancho del pasillo o para qué lado debe abrir una puerta) el programador podrá interpretarlo u
construir la aplicación, aun cuando no haya participado de las etapas anteriores ni tenga contacto
con el cliente. La solución programada deberá ajustarse a lo pedido en el diseño.

Toda la parte metodológica, es decir cómo es la codificación para utilizar, forma parte de la materia
Metodología. Nosotros vamos a ver en esta parte las generalidades de la etapa y comprender de
modo global que tareas deben llevarse a cabo.

En el apunte de clase podrán ver cómo es la etapa de diseño, que cosas deben diseñarse y de qué
modo debe construirse. (entendiendo que la explicación técnica la verán después). Prestaremos
especial atención a algunos temas como las cosas que deben tenerse en cuenta a la hora de diseñar
una interfaz de usuario eficiente y cómo funcionan los patrones de diseño, que permiten reutilizar
componentes y facilitar la programación.

Por último, no podemos olvidar que la interfaz de usuario representa un punto crítico del software,
no solamente porque permite un adecuado uso de la aplicación sino porque la buena o mala
experiencia de uso de un software depende en buena parte del diseño de su interfaz. En tal sendido,
Ben Shneiderman, en su trabajo “Designing the User Interface: Strategies for Effective Human-
Computer Interaction” recomienda 8 reglas a seguir:

1. Luchá por la consistencia.

2. Buscá la usabilidad universal.
3. Entregá información de feedback.
4. Diseñá diálogos de cierre.
5. Prevení errores.
6. Permití la fácil reversión de acciones.
7. Dale el control al usuario.
8. Reducí la memoria de corto plazo.

Del mismo modo, los patrones arquitectónicos que, por ejemplo, Google, Microsoft y Apple proveen
para diseñar aplicaciones para sus respectivos sistemas operativos, permiten a los desarrolladores
independientes general aplicaciones consistentes con todo el ecosistema.
 8

Esta etapa es, quizá, la más fácil de explicar y comprender

PUNTOS CLAVES
Características generales de la etapa
¿Qué hace un programador?
conceptualmente: Es aquella etapa donde los programadores
codifican, utilizando un lenguaje de programación, los
requerimientos de diseño. Construyen efectivamente una
aplicación ejecutable, que puede correr en una computadora. Es
aquí donde el software comienza a existir.

También es cierto que esta etapa, como la anterior, queda también

fuera del foco de nuestra materia. Incluso, por ser un tema con una
problemática particular, queda afuera de mucha de la bibliografía
de Ingeniería de Software, y es abordada en libros específicos de
BIBLIOGRAFÍA programación. De hecho, para comprenderla requiere que se
conozcan los fundamentos de los lenguajes de computación.

Libro de C. Briano: Apunte 6
Durante el transcurso de la Carrera irán viendo con mayor detalle
en qué consiste la programación. Por ejemplo, tanto “Teoría de los
Lenguajes y Algoritmos” como “Construcción de Aplicaciones
informáticas” tienen práctica de programación que les abordar el
tema conocer cómo de codifica un software.

Pero claro, teniendo en cuenta las correlatividades, es necesario

VIDEO que puedan tener una introducción al tema y para eso está el
capítulo del Compilado de Apuntes, en donde podrán conocer a
https://bit.ly/2GaUn0V vuelo de pájaro las características de la etapa y las tareas que un
programador realiza dentro del proceso de construcción guiado
por la ingeniería de software.
 9
Usualmente, la etapa de prueba de software es definida como
aquella en la cual se comprueba que el software no tiene errores,
PUNTOS CLAVES 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
Conceptos y Características de la cierto, pero no es del todo apropiada.
prueba de software
En la etapa de prueba no se debe verificar que el programa
El proceso de pruebas funcione sino, por el contrario, se deben encontrar errores. Esto,
que parece un simple juego de palabras no lo es: Una cosa es
Pruebas de Desarrollo probar algo a ver si anda y otra diferente es exigirlo hasta que falle.

El mejor ejemplo son las pruebas a las que se someten los autos
Pruebas de Versión
antes de salir al mercado. En las pruebas de choque literalmente se
destruye el vehículo para encontrar componentes defectuosos o
Pruebas de Usuario
fallas de diseño. Lo mismo pasa con un electrodoméstico… a las
heladeras se la someten a la apertura de puerta, miles de veces,
Depuración
hasta que se rompa, determinando de este modo si la puerta
funcionaría bien en un uso normal.
BIBLIOGRAFÍA
En el software hay que hacer lo mismo. Someterlo a todo tipo de
situaciones buscando que el software falle. Con una ventaja
Libro de Sommerville: Capítulo 8 adicional… a diferencia de estos productos, el software no se
destruye con la prueba, puede ser corregido. Lo que se entrega es
Libro de C. Briano: Apunte 7 la misma copia funcionando, no otro producto similar.

El libro de apuntes NO reemplaza, sino que Algunas consideraciones sobre el producto de prueba:
complementa a Sommerville. Ambos son
lectura obligatoria. • Es un elemento crítico para asegurar la calidad de software
(Software Quality Assurance), pero no son sinónimos. La
calidad es un proceso amplio que involucra a todas las
actividades del proceso de desarrollo. Incluso la prueba
debe ser sometida a controles de calidad
VIDEO
• La prueba busca ejecutar un programa forzándolo con el
https://bit.ly/32S9QM4 objetivo de encontrar un error. Es una “actividad
destructiva”, destruye lo construido buscando que falle.

• El éxito de la prueba es encontrar errores.

• Las pruebas pueden mostrar sólo la presencia de errores,

mas no su ausencia. Este postulado enunciado por Edsger
Dijkstra 1972, se mantiene en nuestros días. Son
absolutamente excepcionales las aplicaciones que han sido
programados libres de error.

• Imposible probar todas las alternativas. Los caminos

lógicos de un software a veces implican millones de
combinaciones. Es necesario encontrar estrategias que
permitan encontrar la mayor cantidad con el mínimo
esfuerzo y tiempo. Por ejemplo, para probar si anda el
ingreso del DNI sería ridículo tener que cargarlos uno a uno
los millones de DNIs. Habrá que probar que pasa si queda
vacío, si se carga un número muy grande, alguno muy
 chico, si se carga con punto. es decir, se armará un juego de datos que permita probar
generalidades.

• “Es la única etapa optativa”. Esto que suena horroroso, es cierto. Un software no
puede construirse sin un análisis y diseño. Por supuesto no puede existir si no se
programa, y desde luego la puesta en marcha también debe ocurrir… pero la prueba…
es posible entregar un software con nula o muy poca prueba. Y esta etapa se termina
convirtiendo en la variable de ajuste cuando los tiempos del proyecto fueron mal
calculados y están excedidos: Como debo entregar el software si o si el lunes, hago
algunas pruebas (busco que funcione, no busco encontrar errores) durante el fin de
semana y lo entrego. Obviamente las consecuencias pueden ser gravísimas.

Para realizar una prueba es necesario armar un equipo, conformado tanto por miembros del equipo
de desarrollo, como por testers independientes. Este equipo irá ejecutando diferentes tipos de
pruebas para encontrar diferentes tipos de errores. Recién cuando el sistema sorteó con éxito las
mismas, estará listo para ser puesto en funcionamiento.

En el caso de que se encuentren errores, de ingresa en la etapa de depuración o debugging, donde

se buscan las causas del error y se lo corrige. Una vez corregido se vuelve a la etapa de testeo para
comprobar que la solución implementada en efecto corrigió el problema, y que no se han
incorporado otros errores al corregir el primero.
 10
El proyecto de software no acaba en el momento en el que finalizan
las pruebas y las revisiones pertinentes y el software está listo para
PUNTOS CLAVES operar.

El proceso de evolución del software.
Despliegue del Software.
Alternativas de implementación y
preservación de los datos.
A partir de ese momento se necesita, por un lado, implementar el
nuevo software y por el otro, ir modificándolo de modo que
acompañe la evolución del entorno y la organización. El software
evolucionará constantemente hasta que el mismo pasa a una etapa
de fin del servicio y retiro gradual.

Capacitación y gestión del cambio en el

SW

Construcción del sistema y gestión de

versiones

Mantenimiento del software.

Reingeniería Despliegue: consiste en instalar el software en las computadoras

del cliente para comenzar a operar Se debe considerar un nuevo
Administración de sistemas heredados entorno de hardware (el de la empresa), la capacitación de los
Depuración. usuarios que deban operarlo, los datos anteriores que deben
migrarse, la interacción con otros sistemas de la organización e
Parametrización de sistemas incluso con la resistencia al cambio de los involucrados.
comerciales (COTS).
Garantía: Es importante no confundir la etapa de mantenimiento
con la Garantía. Como desarrolladores debemos garantizar que
nuestro software funcionará sin errores, y que cumplirá con
aquellos requerimientos para los que fue diseñado,
BIBLIOGRAFÍA independientemente de exista o no una etapa formal de
mantenimiento posterior acordada con el cliente. Por supuesto los
términos de esta garantía, así como quien ser hará cargo de su
Libro de Sommerville: Cap. 9, 16 y 25
costo, son temas que se negociarán al pactar el desarrollo.
Libro de C. Briano: Apuntes 8 y 9 Mantenimiento De este modo se conoce a la etapa en el la cual se
van incorporando cambios y agregados al sistema de modo que
acompañe a la organización en su evolución. En modelos
tradicionales esta etapa es bien identificada como separada del
proceso de desarrollo, y ocurre una vez que el software fue
implementado. En desarrollos ágiles, el límite es más difuso ya que
VIDEO
el software está en cambio permanente.

https://bit.ly/3hPIHhG Versionado: Es posible que un mismo software se instale en

diferentes clientes. Y también es posible que estos clientes
necesiten cambios particulares. De ese modo un mismo software
base podrá tener más de una versión. Es importante administrar
esas versiones para, cada vez que se necesite generar una copia
específica, esta tenga todos los componentes y módulos correctos.
Como ejemplo, podemos pensar en un sistema que tenga dos
versiones, una en español y la otra en inglés. Operativamente los
sistemas son iguales, comparten gran parte del código.
Al preparar cada versión se compilarán los archivos específicos generales y los particulares de una
versión y de la otra.

Administración de Sistemas Heredados: Un tema particular a considerar son los sistemas heredados.
Sistemas que ya no reciben nuevos cambios ni a los que se 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.)

Reingeniería: En ocasiones, el sistema llega a un punto donde ya no conviene o no se puede seguir

modificándolo. En ese caso es posible realizar una reingeniería donde, a partir de un software
existente, se vuelve a generar otro nuevo. La reingeniería puede implicar volver a documentar el
sistema, refactorizar su arquitectura, traducir los programas a un lenguaje de programación
moderno, y modificar y actualizar la estructura y los valores de los datos del sistema.
La funcionalidad del software no cambia y, normalmente, conviene tratar de evitar grandes cambios
a la arquitectura de sistema.

Reutilización: La reutilización es clave en el proceso de desarrollo. Reutilizar código (por las

características propias, el software reutilizado siempre se comporta como si fuese nuevo) tiene
numerosas ventajas:

• Ahorro de costos, aprovechando parte del código desarrollado previamente en otros

proyectos. Por ejemplo, se puede reutilizar la rutina que valida el CUIT que ya fue
desarrollada anteriormente. La adecuada modularización del software es clave para este
aprovechamiento.
• Ahorro de tiempos: Aprovechar partes de código preexistente permite desarrollo más
rápido.
• Menos errores: Se supone que el software reutilizado ya fue probado en anteriores sistemas
y por lo tanto está libre de errores.

Muchas cosas, y no solo código puede reutilizarse y aprovechar sus ventajas:

1. Planes del proyecto.

2. Estimaciones de costo.
3. Arquitectura de datos.
4. Especificaciones de objetos y clases.
5. Diseños arquitectónicos de datos, de interfaz y de procedimiento
6. Código Fuente.
7. Documentación del usuario y técnica.
8. Interfaces.
9. Datos, por ejemplo, de tablas.
10. Casos de prueba.

Por supuesto, en algunos casos la reutilización será directa y completa (ej. rutina el cálculo del cuit)
y en otras servirá como base o experiencia para el nuevo desarrollo (ej. manuales)

Reutilización de Sistemas Comerciales (COTS): Un punto especial representa la generación de

software reutilizando plantillas o frameworks previamente desarrollados, los cuales solamente se
parametrizan para adecuarlos a la organización. Buena parte de los sistemas “enlatados” o
“preplaneados” que se incorporan a las empresas funcionan de este modo.

A este tipo de sistemas se los denomina COTS (por las siglas de Comercial-Off-The-Shelf ) es un
sistema de software que se compra listo (Comercial-Off-The-Shelf significa literalmente que el cliente
lo toma de la estantería, como si fuera un producto del supermercado; por supuesto hoy en día se
descarga de Internet) y luego puede adaptarlo a sus necesidades sin cambiar el código fuente del
sistema.
Por lo general se busca un estadío intermedio: El desarrollador tiene un entorno o framework base,
el cual personaliza conforme los requerimientos específicos del cliente. Incluso muchas veces el
software corre en los propios servidores del desarrollador, y el cliente los utiliza como un servicio.
Los grandes softwares empresariales (por ejemplo, SAP) son ejemplos de software estándar ya
desarrollado que se personalizan para cada cliente específico.

Las ventajas de reutilizar sistemas comerciales pre-desarrollados son múltiples:

1. Implementación rápida de un sistema fiable

2. Es posible analizar el software antes de implementarlo y ver si es adecuado para mis
necesidades
3. Se evitan riesgos y demoras
4. No deben dedicarse recursos al desarrollo de un nuevo sistema
5. El proveedor mantiene actualizado el software
 11
PUNTOS CLAVES
El Concepto de Calidad.
Revisiones e inspecciones
Mediciones y Métricas
Estándares de calidad, normas ISO y el
modelo CMM
BIBLIOGRAFÍA
Libro de Sommerville: Cap. 24 y 26
VIDEO
Guía Didáctica
https://bit.ly/34LVcav
Video sobre Calidad
https://bit.ly/30qdxqT
El concepto de Calidad no es tan sencillo de entender ni definir.
Cuando vemos un producto nos resulta fácil evaluar calidad.
Incluso en función de esta percepción, estamos dispuesto a pagar
más por un producto que por otro. Pero resulta difícil explicar qué
es la calidad. De hecho, si bien hay consensos, hay un alto grado de
subjetividad, y un artículo puede ser percibido como de buena
calidad por determinados consumidores y de baja calidad por
otros.
Roger Pressman, en su libro Ingeniería de Software, cita un
fragmento del libro de Robert Pirsig “El zen y el arte del
mantenimiento de la motocicleta”
Calidad.. sabes lo que es, pero no sabes lo que es.
Pero es una contradicción. Algunas cosas son
mejores que otras; es decir tienen calidad. Pero
cuando tratas de decir lo que es la calidad, además
de las cosas que la tienen, todo se desvanece. No
hay de que hablar. ¿Por qué paga fortunas la gente
por algunos artículos y tira otros a la basura? Es
obvio que algunas cosas son mejores que otras…
pero ¿en qué son mejores? ¿Qué demonios es la
calidad?
En realidad, calidad puede definirse de muchas maneras, depende
del contexto. La Real Academia Española la define como
“Propiedad o conjunto de propiedades inherentes a una cosa que
permiten apreciarla como igual, mejor o peor que las restantes de
su especie”. las Normas ISO refieren al “grado en el que un
conjunto de características inherentes cumple con los requisitos “.
¿Cómo se construye un producto de calidad? No existe un
componente que agrega calidad a lo producido. Tampoco a un mal
producto se le puede agregar calidad una vez que está terminado.
Es por eso que el concepto que se utiliza es el de Calidad de
Proceso. Se supone que, si un artículo determinado fue fabricado
siguiendo un proceso estandarizado y probado, el producto es
calidad. Es demostrable que procesos se siguieron para elaborarlo
y por ende asegurar que ese artículo se ha construido de la mejor
manera posible.
Para graficar mejor lo dicho… no es fácil demostrar que el plato que
vamos a comer es de calidad, pero si podemos certificar que las
cocinas son limpias, que los componentes provienen de
proveedores confiables, que se han cumplido con los protocolos de
almacenamiento y manipulación de alimentos, que se utiliza agua
potable, que el personal cumple normas de higiene personal, que
se ha fumigado el local… Entonces... un proceso de calidad en la
elaboración casi con seguridad significa que ese plato es de calidad.
En el desarrollo de software debemos entender que la calidad no debe pensarse al finalizar el código,
por el contrario, es una actividad protectora o sombrilla y debe estar presente en todo el proceso.
Las pruebas de software, si bien son parte del proceso que asegura la calidad del software, NO son
controles de calidad. Por el contrario, deben efectuarse controles de calidad a las pruebas, para
asegurar que estas se han desarrollado completas y cumpliendo los estándares prestablecidos.

El Aseguramiento de la Calidad (QA - Quality Assurance) consiste en la definición de procesos y

estándares que deben conducir a la obtención de productos de alta calidad. El control de calidad
(las pruebas) es la aplicación de dichos procesos para eliminar aquellos productos que no cumplen
con el nivel requerido.

El equipo QA debe ser independiente del equipo de desarrollo para que pueda tener una perspectiva
objetiva del software. Esto les permite reportar la calidad del software sin estar influidos por los
conflictos de desarrollo del software. Debe reportarse ante la gerencia ubicada sobre el nivel del
administrador del proyecto. La razón es que los administradores de proyecto tienen que mantener
el presupuesto y el calendario del proyecto y, a veces, una prueba fallida implica volver atrás el
proceso y demorar la entrega. Aunque por supuesto, en empresas pequeñas la gestión de calidad y
el desarrollo de software están inevitablemente vinculados con las personas que cumplen ambos
roles.

Durante el desarrollo de software deben una serie de momentos en donde se somete al producto a
diversos controles:

• Inspecciones: Son “revisiones de pares” en las que los miembros del equipo colaboran entre
sí para encontrar bugs en el programa en desarrollo. Miembros del equipo con diferentes
antecedentes que realizan una cuidadosa revisión, línea por línea, del código fuente del
programa.
• Revisiones: Son auditorias donde un grupo de personas examinan el software y
su documentación asociada en busca de problemas potenciales, omisiones en la
documentación y la falta de conformidad con los estándares.

MEDICIONES Y METICAS

En muchos pasajes de la materia hemos hablado de la importancia de la experiencia. También con

la necesidad de comparar el desarrollo con estándares. Para ambas cosas es necesario medir el
proceso con el objeto de utilizar esos datos para ser comparados con desarrollos futuros (acumular
experiencia) o comparar esos resultados con los que se fijaron como estándares.

La medición del software se ocupa de derivar un valor numérico o perfil para un atributo de un
componente, sistema o proceso de software. Sin embargo, las medidas no siempre nos permiten
comparar o sacar conclusiones. Que una persona mida 1.60 no nos dice demasiado. Necesitamos
saber su edad y su sexo para luego poder usar una tabla de pesos y medidas estándares y determinar
si es una persona alta o baja.

Las métricas de software se desarrollan a partir de las medidas, para obtener valores que puedan
ser comparables.

Ejemplos de medidas: Cantidad de Errores, Cantidad de líneas de código, Cantidad de horas

trabajadas, Tamaño en disco, Hojas de documentación

Ejemplos de métricas: errores cada 1K líneas código, Hs. trabajadas por día, cantidad de líneas
programadas por mes.

Que un desarrollo de software tenga 5 errores no me dice mucho. Que tenga 5 errores cada 1000
líneas de código programadas me permite comparar con desarrollos pasados o estándares y ver si
mi proceso se mantiene dentro de parámetros normales o debo ajustarlo.
Algunas consideraciones sobre métricas:

• Hay métricas privadas (individuo) y públicas (proyecto).

• Las métricas deben usarse con sentido común, interpretándolas correctamente.
• No deben utilizarse para sancionar ni para valorar a individuos. De hacerlo la persona
empezaría a trabajar solamente en función de cumplir la métrica, sin importar si eso es lo
mejor para el proyecto.
• No debe utilizarse una única métrica. Deben conciliarse resultados opuestos. (alguien puede
programar muchas líneas de código por mes, pero también puede cometer muchos más
errores que los normales). Hay varios análisis en este caso, por ejemplo, que parte del
sistema se esté programando, quizá sean módulos más sencillos donde se necesite avanzar
más rápido y donde los errores son menos importantes para el desarrollo del proyecto.
• Los resultados negativos deben considerarse como oportunidad (o necesidad) de mejora.

ESTANDARES DE SOFTWARE

Un aspecto importante del aseguramiento de calidad es la definición o selección de estándares que

deben aplicarse al proceso de desarrollo de software y la verifican de su cumplimiento. Los
estándares son importantes por:

• Los estándares auxilian la continuidad cuando una persona retoma el trabajo iniciado por
alguien más, se reduce el esfuerzo de aprendizaje requerido al iniciarse un nuevo trabajo.
• Los estándares reflejan la sabiduría que es de valor para la organización. Con frecuencia,
este conocimiento se adquiere sólo después de gran cantidad de ensayo y error.
Configurarla dentro de un estándar, ayuda a reutilizar esta experiencia y a evitar errores del
pasado.
• Como se dijo, la calidad del software es subjetiva, y al usar estándares se establece una base
para decidir si se logró un nivel de calidad requerido.
Las Normas ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and
Evaluation), es una familia de normas que tiene por objetivo la creación de un marco de trabajo
común para evaluar la calidad del producto software. No se ocupan de ver si el software es bueno,
rápido o libre de fallas, sino que se ocupan de evaluar como fue el proceso de construcción en una
serie muy amplia de ítems. Por ejemplo, evalúan que tan fácil de operar es un software o que tan
sencillo es de corregir o que tantas habilidades requiere para ser operado correctamente.

En el siguiente gráfico podremos observar a modo de resumen el modelo de calidad planteado por
las normas ISO 2500. Puede encontrarse información adicional en el siguiente enlace:
https://iso25000.com
EL MODELO CMM/CMMI

El Departamento de Estado de los Estados Unidos necesitó, en su momento, evaluar a las empresas
a las que les encargaba los desarrollos vinculados con sus sistemas militares. El interés principal era
saber si una determinada empresa tenía procesos lo suficientemente maduros y estandarizados de
modo que pudieran repetir con los nuevos desarrollos lo bueno que habían hecho en software
pasados.
Por esta razón hacia 1986 encargó a la Universidad Carnegie-Mellon que elaborara un estándar que
permitiera clasificar a las empresas según el grado de madurez de sus procesos.
El modelo cuenta con una serie de niveles que describen que tan maduros son los procesos de una
organización, entendiendo que, si siguen procesos bien definidos y estandarizados, sus productos
tendrán una mejor calidad y un menor número problemas.
Si bien se requiere una revisión formal por parte de una entidad habilitada para certificar los
procesos, técnicamente todas las empresas del mucho pueden ser ubicadas en alguna de estas 5
categorías:

Cuando se inicia un proceso formal de certificación, las empresas someten sus procesos a revisión
de modo de obtener un certificado que acredite formalmente su nivel. El nivel deseable a alcanzar
es 3. La mayoría de las organizaciones desarrollan software sin seguir procesos definidos y por lo
tanto estarían en un nivel 1 ó 2. Por supuesto ninguna de estas empresas se sometería a los procesos
de evaluación ya que, entre otras cosas, son pagos. Es posible que para participar de algunas
licitaciones o para obtener determinados beneficios impositivos se requiera que la organización este
certificada en el modelo CMM, nivel 3

Son muy pocas las empresas que llegan a nivel 4 ó 5, que por otra parte suelen alcanzarse en forma
conjunta. Solamente algunos softwares puntuales o algunos procesos de unas porcas organizaciones
alcanza esta categoría.

Nota: El modelo CMM y el CMMI son equivalentes. Ocasionalmente la escala varía y comienza en 0,
siendo el 4 el máximo nivel a alcanzar

PUNTOS CLAVES
• EL concepto de riesgo
• Tipos de Riesgo
• El proceso de gestión de riesgo
• Tablas de Riesgo
• Plan de Contingencia
BIBLIOGRAFÍA
Libro de Sommerville: Cap. 22
Apunte “Introducción a la Gestión de
Riesgos - BCP y DRP” de Christian
Cirone
VIDEO
https://bit.ly/3b7DkrR
Todo proyecto en el que nos embarquemos, sea del tema que sea,
tiene riesgos. Es posible que existan proyectos de muy bajo riesgo,
pero seguramente también tendrán bajos beneficios. Levantarnos
de la cama e iniciar una jornada diaria es riesgoso, pero
seguramente enfrentar ese riesgo traerá cosas buenas. Riesgo y
beneficio son conceptos que van de la mano.
La Real Academia Española define a Riesgo como la “contingencia o
proximidad de un daño”. Y esto nos lleva a analizarlo desde 2
magnitudes:
1. No existe riesgo sin incertidumbre. La probabilidad de que
el daño ocurra siempre es mayor que 0 y menor que 1. Es
decir que nunca tenemos certeza de que vaya a ocurrir, ni
tampoco de que no vaya a pasar.
2. El evento que se desencadene debe producir un daño. Si la
ocurrencia de un evento no puede dañarme, entonces deja
de ser un riesgo para mi.
Y analizar estas dos dimensiones del riesgo son fundamentales
porque en ellas está la clave. Para administrar adecuadamente los
riesgos debemos preguntarnos:
• ¿Qué puede salir mal?
• ¿Qué daño causaría eso que saldría mal?
• ¿Qué probabilidad existe?
Y en base a esto habrá que buscar una mitigación hay. Es decir que
cosas se pueden hacer para disminuir la probabilidad de ocurrencia
(ej. verificar que la instalación eléctica esté bien y que tenga la
protección térmica adecuada) o disminuir su impacto (ej. instalar
matafuegos para poder apagar un incendio antes de que se
propague).
Existen 2 tipos de estrategias para enfrentar al riesgo:
• Estrategias Proactivas: Buscan anticiparse al riesgo.
Por ejemplo, las pólizas de seguro (buscan que, si el
riesgo finalmente ocurra, el impacto sea menor)
• Estrategias Reactivas: Esperan a que el riesgo
suceda para actuar (Ej. los bomberos)
Ninguna de las estrategias es mejor que la. Simplemente hay riesgos
a los que uno puede anticiparse y otros que, por una cuestión por
ejemplo de costos de las medidas preventivas, uno prefiere esperar
a que ocurran para atacarlos. Nosotros podemos tomar vitaminas
para reducir la posibilidad de contraer alguna enfermedad, pero no
podemos extraernos órganos para prevenir otras. Depende cual sea
el tipo de riesgo al que nos enfrentemos, convendrá optar por una
u otra estrategia o incluso una combinación de ambas.
El proceso de gestión del riesgo tiene entonces 4 etapas:

1. Identificación del riesgo: Hay que identificar posibles riesgos para el proyecto, para el
producto y para la organización.
2. Análisis de riesgos: Se debe valorar la probabilidad y las consecuencias de dichos riesgos.
3. Planeación del riesgo: Es indispensable elaborar planes para enfrentar el riesgo, evitarlo
o minimizar sus efectos en el proyecto.
4. Monitorización del riesgo: Como los riesgos mutan en el tiempo, es
necesario monitorearlos permanentemente, verificar si los planes para atenuarlo sigen
vigentes y, si en la medida que se aprenda más sobre el riesgo, es recomendable alguna
variación.

Como no es posible ocuparse de todos los posibles riesgos, las “tablas de riesgo” son herramientas muy
útiles a la hora de gestionar el riesgo. En ellas se agrupan los riesgos según su probabilidad de ocurrencia
y su impacto, de manera que puedan asignarse más recursos prevenir y mitigar a aquellos riesgos que
tienen una alta probabilidad de ocurrir o que producirían un daño mayor.

La pandemia nos proporciona un escenario real para comprender mejor estos temas.

Supongamos que, parados en Mayo de 2019, las organizaciones hubieran tenido en sus planes de
riesgo, la posibilidad de que, por una pandemia, deba cerrarse la empresa y comenzar con el trabajo
remoto. Casi con seguridad todos le hubieran puesto 0 a dicha posibilidad (certeza de que no iba a ocurrir).
Hubiera sido aventurado asignar recursos a mitigar una posible situación que, si bien podría ser imaginada,
no era posible que ocurriera.

De igual modo que en la Ciudad de Buenos Aires, por ejemplo, no se plantean medidas que protejan los
centros de cómputos de terremoto. En las zomas sísmicas de Chile, por el contrario, esto es obligatorio

En enero de 2020 si podemos comenzar a tomar la pandemia como un riesgo. Posiblemente un riesgo que
comenzó en la zona verde (alejados de China esto podría tener bajo impacto y probabilidad de ocurrencia)
pero rápidamente escaló a la zona roja. Y es con eso que surge otra cuestión: Los riesgos deben ser
monitoreados permanentemente, para ver su evolución. De nuevo, no todos (las probabilidades de
terremoto no cambian) pero otros, cuando los identificamos, tenemos que identificar su volatilidad para
seguir su curso. Algunos pasaran de verde a rojo en pocas semanas y otros, quizá, hagan el camino
inverso.
 Dos años tarde, en mayo 2021 la pandemia, lamentablemente, ya no es un riesgo sino una certeza.
Dejamos de tratarlo como tal, ya no hay políticas de mitigación por si ocurre, y pasamos a tratarlo como
una certeza: implementamos protocolos de trabajo. Por supuesto aparecen otro riesgos y escenarios de
los que habrá que ocuparse, por ejemplo, los trabajadores de grupos de riesgo.

Es importante este ejemplo ya que cualquier política de mitigación de riesgos tiene sus costos (los
matafuegos cuestan plata). Entonces, por un lado, su costo tiene que ser acorde y proporcional al riesgo
que evitan. Por el otro, es imposible afrontar estrategias de mitigación para todos los riesgos. Es por
eso que se solemos ocuparnos de aquellos riesgos de la zona amarilla y roja (alto impacto y alto daño) y
el resto pueden dejarse en un segundo plano. Hubiera sido muy caro pensar en una política de teletrabajo
por pandemia hace dos años, para un riesgo que tenía bajísimas probabilidades de ocurrencia. Nadie
castigaría a un líder de proyecto por no haber atendido a esos riesgos en aquel momento, así como nadie
cuestiona los gastos en protocolos anti-covid actuales ya que dejo de ser un riesgo, es una certeza y por
lo tanto ya dejo de ser algo que hay que mitigar, sino que hay que atacar.

Finalmente se elaborará un “Plan de Contingencia” en el cual se plantean las alternativas con las que
cuenta la organización para garantizar la continuidad del negocio y las operaciones de una compañía, ante
una situación de peligro concreto. Por ejemplo, ante la falla de un servidor la compañía podrá operar
utilizando otro equipamiento, o ante la caída de un proveedor de Internet, podrá contar con una vía de
conexión alternativa.

Todo esto se plasma en un documento denominado “Plan de Gestión de Riesgos”. En este documento se
incluirá un estudio de los riesgos que enfrenta el proyecto, un análisis de dichos riesgos e información de
cómo se gestionará el riesgo cuando es probable que se convierta en un problema; qué medidas se
tomarán en cada caso para disminuir la probabilidad de que se manifieste, que se hará para disminuir su
impacto y que alternativas de contingencia se plantearán para asegurar la continuidad operativa del
negocio.

PUNTOS CLAVES
• Confiabilidad
• Disponibilidad y Fiabilidad
Una falla del software del servidor en una empresa de comercio
electrónico podría conducir a dicha compañía hacia una gran
pérdida de ingresos y, posiblemente, también de clientes.
Un error de software en un sistema de control embebido en un
automóvil provocaría costosas devoluciones de ese modelo por
reparación y, en los peores casos, sería un factor que contribuya a
los accidentes.

• Protección La infección de la compañía de las PC con malware requiere costosas

operaciones de limpieza para solventar el problema y, quizá, traiga
• Seguridad aparejada la pérdida o el daño de información sensible.

Los sistemas deben ser confiables y seguros. Estas son condiciones

que van más allá de que el sistema no tenga errores (es decir que
paso exitosamente las pruebas). Deben construirse sistemas
BIBLIOGRAFÍA pensando en estas características en especial en determinados
entornos, por ejemplo, un sistema bancario.

Un sistema puede ser considerado confiable en función de estas 4

Libro de Sommerville: Cap. 22 características:

• Disponibilidad: El sistema estará disponible para entregar

sus servicios cuando se lo requiera. En otras palabras, cuando
lo necesito, el sistema está andando.

• Fiabilidad: El sistema entrega sus servicios según las

VIDEO especificaciones. Es decir, la respuesta del sistema es la
correcta según lo que se especificó en el diseño.

• Protección: El sistema se ejecuta sin fallas catastróficas. Por

https://bit.ly/3jp1IrT ejemplo, el sistema no puede permitir dejar en cero valores
que luego produzcan errores de división por cero. O no
debería permitir continuar la operación si no se pudo validar
la identidad del usuario.

• Seguridad: Es la capacidad del sistema para protegerse

contra intrusiones accidentales o deliberadas.

Algunas propiedades que hacen que un sistema sea confiable:

Reparabilidad: Las fallas del sistema son inevitables; no obstante, el

desajuste causado por la falla podría minimizarse siempre que el
sistema logre repararse rápidamente, por ejemplo, mediante
actualizaciones automáticas.

Mantenibilidad: Mientras se usan los sistemas, surgen nuevos

requerimientos y es importante mantener la utilidad de un sistema
al cambiarlo para acomodar estos nuevos requerimientos. Es decir
que si, por ejemplo, aparece una nueva norma los sistemas se
actualicen para contemplarla.
 Supervivencia: La supervivencia es la habilidad de un sistema para continuar entregando servicio en
tanto está bajo ataque y mientras que, potencialmente, parte del sistema se deshabilita. Por
ejemplo, permitir consultar el saldo de una cuenta, aunque este inhabilitada la posibilidad de hacer
transferencias.

Tolerancia para el error: Esta propiedad se considera como parte de la usabilidad y refleja la medida
en que el sistema se diseñó de modo que se eviten y toleren los errores de entrada de usuario.

¿Cuáles son las amenazas de seguridad de un sistema?

• Amenazas a la confidencialidad del sistema y sus datos: Pueden difundir

información a individuos o programas que no están autorizados a tener acceso a dicha
información.
• Amenazas a la integridad del sistema y sus datos: Tales amenazas pueden dañar o
corromper el software o sus datos. (El pago de un cliente podría ser erróneamente
imputado a otro)
• Amenazas a la disponibilidad del sistema y sus datos Dichas amenazas pueden
restringir el acceso al software o sus datos a usuarios autorizados (es decir que los que
pueden y deben entrar, no puedan hacerlo)

Para mejorar la seguridad de un sistema pueden implementarse algunos controles como por
ejemplo:

• Evitar la vulnerabilidad: Diseñar el sistema y los controles de modo en que los

ataques no tengan éxito (ej. encriptación de datos, operación en modo off-line)
• Detectar y neutralizar ataque: Diseñar controles cuya funcionalidad sea que
monitorear la operación y verificar patrones de actividad inusuales (como por ejemplo
conexiones remotas desde algún servidor o país extraño) y eventualmente tomar
acciones, como desactivar partes del sistema, restringir el acceso a ciertos usuarios, etc.
• Limitar la exposición al riesgo y recuperación. Adoptar estrategias previas como las
copias de respaldo automatizadas, hasta tener pólizas de seguros que cubran los costos
asociados con un ataque exitoso al sistema.

Es necesario que la organización establezca una serie de políticas respecto de la seguridad de los
sistemas y sus datos. Y que estas políticas sean coherentes con el tipo de datos que se estén
resguardando. No será lo mismo la seguridad que hay que brindarle a este documento, que si accede
a ver su contenido alguien que no es alumno del curso la verdad es que poco importa, que datos más
sensibles como historias clínica o claves de acceso a cuentas bancarias. Por ejemplo, en los bancos,
es habitual que existan todas o varias de estas políticas de seguridad:

• Modificación obligatoria de todas de las contraseñas maestras y de cuentas

especiales que ya vienen por defecto.
• Cambio obligatorio de las contraseñas de acceso en el primer inicio de sesión.
• 8 (ocho) caracteres de longitud mínima para las claves.
• Control de la composición de las contraseñas (por ejemplo: caracteres alfabéticos,
numéricos, especiales, mayúsculas y minúsculas).
• Registro histórico de las últimas 12 (doce) contraseñas utilizadas y no permitir
duplicarlas
• Intervalo de caducidad automática de las mismas a los 30 (treinta) días.
• Bloqueo permanente de la cuenta del usuario ante 3 (tres) intentos de acceso
fallidos.
• Desconexión automática de la sesión de usuario en la aplicación y en la red por
tiempo de inactividad a los 15 (quince) minutos.

Es importante también contemplar al eslabón más débil que tiene cualquier esquema de acceso y
de contraseñas: El usuario. Muchas veces se plantean contraseñas hiper seguras, de muchos
caracteres que no solo son muy seguras, sino que también son muy difíciles de recordar para el
usuario. Lo mismo pasa cuando me impiden repetir contraseñas… cuando se agotan las fechas claves
o los nombres de las hijos o mascotas, no queda otra que inventar claves más sofisticadas que luego
olvidaremos. Lamentablemente es frecuenta encontrar contraseñas anotadas en post-it pegados al
monitor.

La siguiente imagen pertenece a la Agencia de Manejo de Emergencias de Hawai que, entre otras
cosas, alerta al sistema de defensa de EE.UU sobre misiles que ataquen al país. La imagen fue enviada
al público para alertar sobre una falsa alarma de un misil. El problema es que al agrandar la imagen
se podía ver pegada la contraseña de acceso al sistema.
 14
PUNTOS CLAVES
• Trabajo en equipo
• Plan del proyecto
• Técnicas de estimación
• Gestión del Personal
• Calendarización
• Fijación del precio del software
BIBLIOGRAFÍA
Libro de Sommerville: Cap. 22
Libro de C. Briano: Apuntes 10 y 11
VIDEO
https://bit.ly/3hDFYb3
Elegir una metodología adecuada, ágil o tradicional, y un modelo
de proceso que se adapte al tipo de construcción que debo realizar,
es sin duda una decisión importante, pero no garantizan por sí solos
el éxito del proyecto. En realidad, los procesos deben ser
gestionados adecuadamente para que todo funcione del modo en
el que fu previsto y se eviten riesgos e imprevistos.
El proceso de construcción de software en, por lo general, parte de
un proceso mayor de implementación de un sistema e involucra
decisiones de múltiples niveles, por ejemplo, la compra de un
determinado hardware. En la Carrera, la gestión de proyectos es
abarcada por varias materias con distintos enfoques (Metodología/
Gestión de Recursos Informáticos). En Ingeniería de Software nos
centraremos exclusivamente en gestión de la etapa de codificación
propiamente dicha.
Somerville en el libro comienza aclarando que “La gestión de
proyectos de software es una parte esencial de la ingeniería de
software. Los proyectos necesitan administrarse porque la
ingeniería de software profesional está sujeta siempre a
restricciones organizacionales de presupuesto y fecha. El trabajo
del administrador del proyecto es asegurarse de que el proyecto de
software cumpla y supere tales restricciones, además de que
entregue software de alta calidad. La buena gestión no puede
garantizar el éxito del proyecto. Sin embargo, la mala gestión, por
lo general, da como resultado una falla del proyecto: el software
puede entregarse tarde, costar más de lo estimado originalmente
o no cumplir las expectativas de los clientes.”
PLANEAMIENTO
El planeamiento de proyectos es una de las tareas más importantes
de un administrador de proyectos de software. Como
administrador, debe dividir el trabajo en partes y asignarlas para
que las realicen los miembros del equipo del proyecto. También
deberá analizar los riesgos y anticipar los problemas que pudieran
surgir, preparando eventuales soluciones de contingencia. Es
necesario considerar:
• En la etapa de previa al inicio es necesario un plan para
ayudarle a decidir si cuenta con los recursos para
completar el trabajo, y si estos están capacitados para el
tipo de proyecto que se llevará a cabo. También será
necesario realizar una primera evaluación de los tiempos
que demandará el proyecto y sus costos. Dado que esta
primera estimación se basa en información preliminar, es
meramente especulativa y habitualmente basada en la
experiencia adquirida en proyectos anteriores.
• Durante la fase de inicio, se debe determinar quién
trabajará en el proyecto, cómo se dividirá el proyecto en
incrementos, cómo se obtendrán y asignarán los recursos
necesarios.
 • Iniciado el proyecto, las etapas del plan podrán ajustarse conforme se vaya obteniendo
información y avanzando en el desarrollo del proyecto. Los planes podrían ajustarse
conforme surja nuevos requisitos. Si los proyectos tienen naturaleza cambiante, será
apropiado utilizar metodologías ágiles o modelos de desarrollo que contemplen esta
situación.

ESTIMACIÓN
Una vez trazado el plan general que guiará el proyecto, será necesario estimar los recursos que se
necesitarán, en que cantidad, en qué momento temporal y cuál será su costo. Por supuesto también
será necesario contemplar las restricciones sobre los mismos. Es necesario estimar:

• Recursos humanos: Que habilidades deberán poseer, en qué número se precisan y

donde estarán físicamente ubicados.

• Recursos de entorno: Espacio físico (oficinas, escritorios, etc.), Hardware necesario,

redes y licencias de software.

• Recursos de software reutilizables: Será necesario contar con componentes de

software que se integrarán al software: librerías, diseños de pantalla, módulos ya
desarrollados y listos para usar, módulos que deben personalizarse, etc.

Dado que es extremadamente complejo hacer adecuadamente una estimación completa y detallada
de desarrollos grandes, una estrategia que puede aplicarse es dividir el proyecto es partes. Es posible
descomponer un proyecto según:

• Los problemas que resuelvan: Agrupar y estimar por un lado todo Programas de ABM
(Altas, bajas y modificaciones de datos) que sean necesarios, por el otro los listados, las
pantallas de carga, etc.

• El proceso: también es posible descomponer desarrollo en sus procesos y estimar primero

la etapa de análisis, luego el diseño, la codificación y prueba y la implementación. La ventaja
de esta división es que cada estimación será más exacta en función de la información que
obtenga de la etapa anterior. Como desventaja hay que decir que es necesario tener alguna
estimación genera previa para ver si el proyecto es viable de ser encarado.

GESTION DEL PERSONAL

Seguramente una de las primeras y más difíciles decisiones que deberá afrontar el administrador de
un proyecto de construcción serán las vinculadas con el personal abocado en el proyecto y, en
particular, la de conseguir los programadores idóneos para la construcción. El desarrollo de software
es una actividad intensamente humana y, como tal, el costo del personal es una parte muy
significativa del proyecto.

Existen varias dificultades a la hora de conseguir los recursos humanos necesarios. El personal de IT
(Tecnología de la información) es altamente demandado a nivel mundial y suele ser una traba
importante porque la gran mayoría de los programadores ya se encuentran trabajando:

• Es difícil conseguir personal altamente capacitado, en especial cuando se requieren

conocimientos avanzados en determinadas tecnologías.

• Es difícil capacitar al personal. Si bien se puede pensar en contratar programadores y

capacitarlos, esto no ocurre de un día para el otro y el mayor rendimiento no se da en forma
inmediata. Además, existe el riesgo que, una vez capacitado, el desarrollador opte por otro
trabajo que le ofrezca mayores beneficios.
 • Es difícil desarrollar, motivar, organizar y mantener la fuerza de trabajo. El horario flexible y
otros beneficios son muchas veces más valorados que el sueldo.

• Es difícil reemplazar personal. Si un programador abandona un proyecto (o se enferma y no

puede continuar) reemplazarlo no es sencillo, primero porque no es fácil encontrar gente
disponible pero aun cuando se la encuentre hay una curva de aprendizaje que ralentiza
inevitablemente la marcha del proyecto.

• Es difícil disponer recursos en tiempo y forma. Muchas veces los retrasos en proyectos
anteriores hacen que los programadores que se suponían ya deberían estar a disposición
del proyecto actual, todavía estén con tareas pendientes.

El trabajo en equipo es fundamental. Somerville hace hincapié en las ventajas de trabajar en grupo,
así como también da varias recomendaciones vinculadas a la gestión del mismo. En este sentido:

• El grupo puede establecer sus propios estándares de calidad.

• Los individuos aprenden de los demás y se apoyan mutuamente.

• El conocimiento se comparte.

• Se alientan la refactorización y el mejoramiento continuo.

Entre los temas que debemos prestar atención respecto del manejo y organización interna del grupo
aparecen las siguientes preguntas:

• ¿El administrador del proyecto debe ser el líder técnico del grupo? ¿Tiene la suficiente
habilidad y experiencia para tomar decisiones críticas vinculadas al desarrollo?

• ¿Quién se encargará de tomar las decisiones técnicas críticas, y cómo se tomarán?

¿Las decisiones las tomará el arquitecto del sistema, el administrador del proyecto o se
llegará a un consenso entre un rango más amplio de miembros del equipo?

• ¿Cómo se manejarán las interacciones con los participantes externos y los altos directivos
de la compañía? Por lo general administrador del proyecto será el responsable de dichas
interacciones, pero puede ser necesario una persona con habilidades políticas y de
interacción adecuadas.

• ¿Cómo es posible que los grupos logren integrar a personas que no se localizan en el mismo
lugar? ¿Cómo se tomas las decisiones en esos casos?

• ¿Cómo puede compartirse el conocimiento a través del grupo? ¿Qué herramientas

de comunicación se utilizan? ¿Cómo evitar el intercambio excesivo de información?

CALENDARIZACION
La calendarización de proyectos es el proceso de decidir cómo se organizará el trabajo en un
proyecto como tareas separadas, para luego prever cuándo y cómo se ejecutará cada tarea. Se
estima el tiempo calendario para completar cada tarea, el esfuerzo requerido y quién trabajará en
las tareas identificadas. Esta tarea puede presentar una serie de dificultades:

• Fechas irreales, arbitrarias o establecidas externamente (el sistema debe estar terminado
para tal fecha)

• Requerimientos del cliente variables.

 • Subestimación (honesta) de la dificultad.

• Riesgos varios

• Dificultades humanas no previsibles (ej. enfermedades)

• Falta o fallas en la comunicación.

• Falla en la administración de retrasos

La habilidad y experiencia de quien lleva adelante el proyecto son decisivas a la hora de cumplir en
tiempo y forma con lo pautado. La utilización de diagramas de Pert y Gant y de software de
calendarización de tareas (ej. Microsoft Project) pueden colaborar en la tarea.

ESTIMACION DEL PRECIO DEL SOFTWARE

Una vez que están estimados los recursos y su costo, estaremos en condiciones de poder fijar el
precio que tendrá el software. Sin embargo, esto no será tan simple como aplicar la tradicional
fórmula de costeo: PRECIO: COSTO DE LO RECURSOS + COSTOS INDIRECTOS + MARGEN DE UTILIDAD
Dado que no es un producto cerrado y que puede tener variaciones en el proceso de construcción
aparecen varias consideraciones que deben tenerse en cuenta:

• La fijación de precios depende de una adecuada comprensión de los requerimientos y una

acertada estimación de recursos

• Cuando se calcula un precio, hay que hacer consideraciones más amplias de índole
organizacional, económica, política y empresarial

• Es imposible fijar precios finales y realistas antes de realizar la ingeniería de requerimientos.

Las etapas iniciales y de relevamiento deben cotizarse por separado. Luego con el problema
comprendido podrá hacerse una estimación de precios más precisa.

• Puede darse una idea general de precios basadas en la experiencia y en desarrollos

anteriores, que luego se ajustará.

• Con frecuencia, las estimaciones del proyecto se autosatisfacen. La estimación se utiliza para
definir el presupuesto del proyecto, y el producto se ajusta para que se cumpla la cifra del
presupuesto. Un proyecto que está dentro de presupuesto puede lograr esto a
expensas de las características en el software a desarrollar.

• Debe pensarse en los intereses de la empresa, los riesgos asociados con el proyecto y el tipo
de contrato que se firmará.