1

Resumen IIS
Contenido
Introducción – capítulo 1 .............................................................................................................. 4
Procesos de software – capítulo 2 ................................................................................................ 4
Actividades del proceso de software ........................................................................................ 5
Cambios ..................................................................................................................................... 6
Mejora de procesos................................................................................................................... 7
Metodologías ágiles – capítulo 3................................................................................................... 8
Windows XP............................................................................................................................... 8
Historias de usuario ............................................................................................................... 8
Refactorización ...................................................................................................................... 8
Desarrollo dirigido por pruebas ............................................................................................ 9
Pair programming...................................................................................................................... 9
Scrum....................................................................................................................................... 10
Escalamiento ........................................................................................................................... 11
Ingeniería de requisitos ............................................................................................................... 14
Clase 1 – capítulo 4 (+ Wiegers) .............................................................................................. 14
Requerimientos funcionales y no funcionales .................................................................... 14
Procesos de ingeniería de requerimientos ......................................................................... 16
Técnicas para obtención de requisitos................................................................................ 16
Clase 2 – capítulo 4.3 y 5 ......................................................................................................... 17
Escenarios, casos de uso e historias de usuario .................................................................. 17
Clase 3 (ya no sé qué capítulo porque las ppt están en cualquier orden) .............................. 18
Clase 4 ..................................................................................................................................... 19
Modelos de contexto .......................................................................................................... 19
Modelos de interacción....................................................................................................... 20
Modelos estructurales ........................................................................................................ 20
Modelos de comportamiento ............................................................................................. 20
Documento de requerimientos de software....................................................................... 21
Validación de requerimientos ............................................................................................. 21
Diseño de software ..................................................................................................................... 22
Clase 1 - capítulo 7 .................................................................................................................. 22
2

Clase 2 - capítulo 6 .................................................................................................................. 22

Decisiones de diseño ........................................................................................................... 23
Patrones de diseño .............................................................................................................. 23
Clase 3 – capítulos 16 y 17 ...................................................................................................... 24
Ingeniería de software basada en componentes ................................................................ 24
Modelos de componentes .................................................................................................. 24
Desarrollo para/con reuso .................................................................................................. 24
Sistemas distribuidos .......................................................................................................... 25
Patrones arquitectónicos para sistemas distribuidos ......................................................... 25
Software as a service ........................................................................................................... 25
Construcción................................................................................................................................ 26
Clase 1 – Swebok ..................................................................................................................... 26
Consideraciones prácticas ................................................................................................... 26
Tecnologías de construcción ............................................................................................... 27
Verificación y validación .............................................................................................................. 28
Verificación y validación – capítulo 8 (apenas) + Spillner capítulos 2 y 3 ............................... 28
Pruebas de integración ....................................................................................................... 28
Pruebas de sistema ............................................................................................................. 28
Pruebas de aceptación ........................................................................................................ 28
Tipos de prueba y casos de prueba – Spillner, capítulos 4 y 5 ................................................ 29
Pruebas estáticas................................................................................................................. 29
Técnicas de caja negra ........................................................................................................ 29
Técnicas de caja blanca ....................................................................................................... 30
Gestión de las pruebas ........................................................................................................ 30
Evolución del software ................................................................................................................ 31
Clase 1 – capítulo 9.1 .............................................................................................................. 31
Clase 2 – capítulo 9.2, 9.3........................................................................................................ 31
Gestión de la configuración – capítulo 25 ................................................................................... 32
Gestión de proyectos .................................................................................................................. 33
Clase 1 – capítulos 22 y 23.2 ................................................................................................... 33
Clase 2 – capítulo 23.3 ............................................................................................................ 33
Clase 3 – capítulo 22.1 ............................................................................................................ 33
Clase 4 – capítulo 22.2 ............................................................................................................ 33
3
4

Introducción – capítulo 1
El software profesional se hace para ser usado por alguien que no es el desarrollador y
normalmente se hace en equipos. Es mantenido y cambiado durante su vida. A este tipo de
software se orienta la ingeniería de software, pues las técnicas que usa son irrelevantes para el
software personal. El software incluye no sólo un programa, sino también documentación,
librerías y otras cosas.
La computación, a diferencia de la ingeniería de software, se enfoca en la parte teórica, y ésta
última es parte de la ingeniería de sistemas. El 40% del costo del software es testing.
En los productos genéricos, la especificación la controla la compañía, mientras que en los
personalizados la controla el cliente, y se debe trabajar con ella. En la actualidad, cada vez se
mezclan más estas especificaciones, partiendo de un software genérico y adaptándolo.
La calidad de software incluye el comportamiento, estructura y organización de los
componentes.
Los ingenieros trabajan con restricciones, y no siempre existe un método que puedan aplicar
para resolver un problema. Tienen que dar un resultado de la calidad requerida en tiempo y
bajo el presupuesto, así que no pueden hacer todo perfectamente.
La ingeniería de sistemas involucra varias cosas como hardware y proceso de diseño, además
del software.
El software debe cambiar al ritmo de la sociedad, y algunos métodos viejos son demasiado
lentos.
Los sistemas de recolección de datos suelen encontrarse en un entorno hostil, como dentro de
un motor o en una ubicación remota.
El software de negocios se corre en servidores Web para disminuir costos de actualización y
por la interfaz de usuario. Productos basados en la web ven al software como un servicio. Esto,
más el cloud computing, lleva a que el software de negocio esté muy distribuido y reuse
componentes. Además, se hace de forma incremental.
El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) con la ACM produjo un código de ética
y práctica profesional.

Procesos de software – capítulo 2

Un proceso de software es un conjunto de actividades relacionadas que lleva a la producción
de un sistema de software. Las cuatro etapas son complejas e incluyen subactividades, y el
propio proceso puede tener otras actividades.
5

Los procesos han evolucionado. Para sistemas críticos, se necesita un proceso muy
estructurado con registros detallados (cascada), mientras que para sistemas de negocios
cambiantes es mejor un proceso ágil y flexible.
En el modelo intercalado, cada versión le agrega funcionalidad al sistema. La integración se usa
para sistemas de negocios.
El modelo en cascada es un proceso dirigido por plan. Cada fase da como resultado
documentación, y no debería arrancar hasta terminada la anterior, pero en el desarrollo de
software hay retroalimentación entre las partes. Si hay cambios, hay que cambiar la
documentación de las fases anteriores, lo que lleva a retrasos. Para evitarlo, se puede congelar
la especificación de requerimientos, pero esto lleva a que los problemas se ignoren o haya que
encontrar una forma de arreglarlos durante la programación, lo que puede empeorar la
estructura del sistema.
El modelo cascada es preferible para sistemas embebidos en hardware, ya que éste es
incambiante; sistemas críticos donde se necesita toda la documentación de especificación y
diseño para comenzar la implementación; y sistemas grandes siendo desarrollados por varias
compañías a la vez. Hay una variante de este modelo, llamada desarrollo formal de sistema,
que hace un modelo matemático de una especificación, pero sólo se usa en sistemas críticos.
El modelo de desarrollo incremental se basa en la idea de desarrollar una implementación
inicial, obtener información del usuario, y hacer varias versiones del sistema hasta que se
obtiene el deseado. Es el más común hoy en día, y puede ser dirigido por plan, ágil, o por lo
general, una mezcla de ambos. En el primero, los incrementos se identifican antes de arrancar.
Es un mejor modelo para software cuyos requerimientos probablemente cambien durante el
desarrollo, como es el caso de la mayoría de productos. Los incrementos iniciales tienen las
funcionalidades más importantes o urgentes, permitiendo una temprana evaluación del
sistema por parte del cliente para ver si cumple los requerimientos.
Los problemas del desarrollo incremental se agudizan para sistemas grandes y complejos, pues
hay que definir las responsabilidades de cada uno antes de empezar. No es necesario que el
cliente vea cada incremento.

Actividades del proceso de software

La ingeniería de requerimientos es una etapa crítica del proceso de software, pues los errores
aquí se arrastran a otras etapas. Antes de comenzar, se puede hacer un estudio para
determinar si hay mercado y si es posible hacer el software. El objetivo es hacer un documento
con los requerimientos, con dos niveles de detalle: alto nivel para los clientes y más específico
para el desarrollador.
El relevamiento de los requisitos se puede hacer observando sistemas existentes y hablando
con posibles usuarios, y ayudan a entender el sistema. Luego se escribe un documento con
esos requisitos en dos niveles. Los requisitos deben ser realistas, consistentes y completos.
Nuevos requerimientos se pueden encontrar en las etapas de definición y especificación, por
lo cual estas etapas están intercaladas. En los métodos ágiles, no es una etapa, sino que forma
parte del desarrollo, definiendo informalmente los requerimientos para cada incremento
según las prioridades del usuario.
6

Si el diseño y la implementación se hacen de forma intercalada, como en el modelo

incremental, no se hacen documentos de diseño.
El diseño de software es una descripción de la estructura del software a implementar, los
modelos de datos y estructuras que usa, las interfaces, y a veces los algoritmos. Se desarrolla
en etapas, agregando detalles y modificando cosas. El entorno (de software) en el que operará
el producto es un dato fundamental para este proceso, pues hay que integrarlo. Las
actividades necesarias pueden cambiar.
En los sistemas críticos, la etapa de diseño produce documentación detallada con
descripciones exactas y precisas del sistema. Si es dirigido por modelo, los documentos son
diagramas de diseño.
Las pruebas de sistema buscan errores que suceden cuando las partes interactúan, así como
asegurarse de que los requerimientos se cumplen. Para sistemas muy grandes, se puede hacer
con subsistemas. Los programadores suelen probar los componentes a medida que los
desarrollan.
En desarrollo incremental, cada incremento se prueba según sus requerimientos. En desarrollo
dirigido por pruebas, las mismas se desarrollan junto con los requerimientos antes de
empezar. En desarrollo por plan, se hacen planes de prueba (el modelo en V). El beta testing
consiste en enviar el software a posibles clientes para que reporten problemas.

Cambios
Un prototipo se debe desarrollar de forma rápida e iterativa para que los costos sean
controlados y se pueda experimentar con él de forma temprana. Los prototipos les permiten a
los potenciales usuarios ver si el sistema les sirve, e incluso puede revelar nuevos
requerimientos o errores.

Los prototipos permiten verificar si un requerimiento es realizable. El objetivo de un prototipo

se debe definir desde el principio: desarrollar la interfaz de usuario, un sistema para validar
requerimientos, o mostrar la aplicación. Suelen no ser compatibles. Finalmente, para evaluar
un prototipo, hay que entrenar al usuario, que no está acostumbrado, y puede no dar
resultados correctos.
Las entregas incrementales funcionan con las características del desarrollo incremental. Cada
incremento es probado por el cliente, por lo que pueden experimentar para agregar nuevos
requerimientos. Como las partes más importantes son las que reciben más testing, por ser
hechas primero, tendrán menos errores. Es difícil de implementar cuando se está
reemplazando un sistema existente, pues los usuarios están acostumbrados a tener todas las
7

funcionalidades. No es aplicable para los mismos casos que el modelo en cascada sí lo es; en
estos casos, son mejores los prototipos.

Mejora de procesos
El enfoque de madurez de procesos busca mejorar la calidad del producto y que el proceso sea
predecible. Por otro lado, el enfoque ágil sostiene que los mejores procesos son los que tienen
menores costos generales. El primero se basa en desarrollo dirigido por planes y tiene mayores
costos, mientras que el segundo disminuye la formalidad y documentación, enfocándose en el
código.
El análisis de procesos se puede hacer con características como velocidad y robustez. En el
primer ciclo de cambios hay que recoger información del proceso para poder mejorar. Es una
actividad a largo plazo y continua, dados los cambios del mercado. La madurez de los procesos
refleja la administración y medidas de los mismos, así como el uso de buenas prácticas de
ingeniería de software por parte de la compañía.
En el nivel inicial del modelo de madurez de procesos, los objetivos del área están satisfechos.
En el nivel gestionado, además debe haber documentación de los objetivos, y monitorear los
procesos. En el nivel definido, se estandarizan los procesos, y se obtienen medidas para el
futuro. En el nivel gestionado cuantitativamente, se usan medidas cuantitativas para controlar
subprocesos. En el nivel de optimización, se usan las medidas obtenidas para mejorar los
procesos.
Las dificultades de aplicar este modelo por sus costos en modelos ágiles resultan en que sólo
compañías grandes lo usan.
8

Metodologías ágiles – capítulo 3

A los clientes les cuesta darse cuenta de cuáles son los requerimientos del software que
quieren, por eso es difícil tener requerimientos estables.

En los métodos ágiles, no hay especificación del sistema y la documentación del diseño es
mínima. Los requerimientos de usuario se plantean de forma genérica. Los clientes pueden
sugerir cambios para cada versión. Se hacen incrementos pequeños, donde se hacen nuevos
sistemas para los clientes cada dos o tres semanas. La razón de este involucramiento es para
obtener retroalimentación rápidamente. La comunicación es informal para minimizar la
cantidad de documentación. El diseño e implementación son las actividades centrales, y otras
actividades como el testing se incorporan a las mismas.
Los requerimientos y el diseño se desarrollan juntos. De todos modos, es posible generar
documentación con metodologías ágiles, si así se decidiera. Estas metodologías funcionan bien
cuando es posible tener buena comunicación entre el cliente y los desarrolladores, y al no
haber varios equipos involucrados, la comunicación informal funciona.

Windows XP
En XP, los requerimientos se expresan como historias de usuario, que se implementan
directamente como tareas. Los programadores trabajan de a pares y hacen tests para cada
tarea antes de escribir el código. Los requerimientos se basan en las historias de usuario. El
cliente debe definir las pruebas de aceptación.
A continuación se detallan algunas prácticas de XP.

Historias de usuario
Una historia de usuario es una posibilidad de uso que puede sucederle a un usuario. Esto se
discute entre el cliente y los desarrolladores para generar una “tarjeta de historia” que
describe una historia que contiene las necesidades del cliente. Luego se desarrolla ese uso en
un futuro incremento. Esta es la forma de incorporar los requerimientos al desarrollo.
Las tarjetas de historia se separan en tareas y se estima el esfuerzo y recursos necesarios,
hablando con el cliente para refinar los requerimientos. Luego el cliente elige qué historias son
prioritarias para implementar, aquellas que pueden ser útiles inmediatamente. Se debe
identificar funcionalidades que se pueden implementar en dos semanas, que es el tiempo
hasta el siguiente incremento.
Con los cambios de requerimientos, pueden cambiar o eliminarse historias no implementadas.
Si hay cambios, el cliente debe elegir si éstos tienen prioridad sobre cosas nuevas. Las historias
de usuario facilitan a los mismos sugerir requerimientos, pues les son más comprensibles. Sin
embargo, no son completas. No se sabe si se necesitan más requerimientos, o si se tiene toda
la información de una actividad.

Refactorización
Diseñar para facilitar los cambios suele ser una pérdida de esfuerzo. Para facilitarlos, XP
sugiere que el código debe ser refactorizado. La refactorización significa buscar mejoras al
programa e implementarlas inmediatamente, aún si no son necesarias. Los cambios suelen
degradar la estructura del sistema, y la refactorización evita esto al mejorar la estructura y la
legibilidad.
9

Algunos ejemplos son eliminar código duplicado o reemplazar código similar por llamadas a
una librería. Los IDEs incluyen herramientas para esto. En principio, con la refactorización el
sistema debería ser fácil de entender y cambiar. En la práctica, no siempre hay tiempo para
refactorizar, o hay que hacer algún cambio que requiere cambiar la estructura del sistema.

Desarrollo dirigido por pruebas

Hacer pruebas sin tener una especificación es difícil. Para esto, en XP las pruebas son
automáticas y centrales al proceso de desarrollo, que no puede proceder hasta que todas las
pruebas sean exitosas. Las características clave son:
 Desarrollo dirigido por pruebas
 Desarrollo de tests incrementales por uso
 Involucrar al usuario en el desarrollo y validación de las pruebas
 Uso de frameworks de testeo automático

Al escribir las pruebas antes del código, se pueden hacer mientras se escribe el código y
encontrar problemas. Escribir pruebas define una interfaz y una especificación del
comportamiento de la funcionalidad en cuestión. Hay menos problemas de malos entendidos
de requerimientos o interfaz, y una clara relación entre los primeros y el código que los
implementa, gracias a las tareas. Las personas que implementan las mismas deben entender
bien la especificación para hacer pruebas, por lo que ambigüedades y omisiones se deben
aclarar antes de empezar. Además, evita que el desarrollador se adelante al tester, lo que
puede llevar a la omisión de pruebas para mantener el calendario.
Cada tarea genera tests unitarios que verifican la implementación de la misma. El cliente ayuda
a desarrollar pruebas de aceptación (que el sistema haga lo que necesita). La automatización
de tests es fundamental. Las pruebas se escriben como componentes ejecutables antes de
implementar las tareas, y estas pruebas individualmente simulan una entrada y verifican que la
salida sea correcta. Hay frameworks para esto (por ejemplo Junit). Esta automatización lleva a
que exista un conjunto de pruebas que pueden ser ejecutadas fácilmente al introducir nuevas
funcionalidades al sistema.
Como es lógico, este tipo de desarrollo conlleva la escritura de gran cantidad de pruebas. Sin
embargo, es difícil verificar que sean completas. Los programadores suelen omitir algunas
porque no les gusta el testeo, y algunas pruebas son difíciles de hacer incrementalmente. Por
eso es necesario revisar las pruebas y hacer más cuando el sistema ya ha sido desarrollado.

Pair programming
La pareja de programadores se sienta en la misma computadora para hacer el software. Pero
no siempre son los mismos, sino que van rotando. Esto tiene algunas ventajas: apoya la idea de
propiedad colectiva del software, haciendo que todos sean responsables de los problemas; es
una forma de inspección informal al haber dos personas, que ayuda a encontrar errores sin los
problemas de tiempo de las inspecciones formales; y alienta a la refactorización, pues otros se
benefician inmediatamente de dicho proceso (normalmente los programadores son reacios a
refactorizar porque no se ven los beneficios).
La eficiencia del pair programming aún es cuestionada, dado que dos individuos trabajando
juntos en un período de tiempo producen la mitad de código que si trabajaran separados.
10

Estudios sobre el tema han dado resultados mixtos. En general, la ventaja es que se comparte
conocimiento, lo que reduce los riesgos para el proyecto cuando algún miembro del equipo se
va.

Scrum
La planificación informal y falta de documentación de los métodos ágiles colisionan con la
necesidad de visibilidad de las grandes empresas, que necesitan saber qué está sucediendo. El
desarrollo ágil también requiere gestión para hacer el mejor uso de tiempo y recursos posible.
Para dar un framework para esto se desarrolló el Scrum, que permite dar algo de visibilidad. Es
un método ágil por seguir los principios necesarios, pero no se enfoca en las prácticas, por lo
que puede incorporarse con otras.
Los términos usados en Scrum son:

El proceso o ciclo de sprint del Scrum comienza con el product backlog: la lista de cosas en las
que hay que trabajar, que no son sólo funcionalidades del sistema (pruebas, arquitectura,
documentación). Puede tener distintos niveles de especificidad, lo cual depende del product
owner. Cada ciclo de sprint dura un tiempo fijo, y al principio de cada uno el PO define cuáles
son los elementos del backlog que tienen prioridad ese ciclo. Si no se completan, no se
11

extiende el tiempo. Luego el equipo elige qué elementos de la lista creen que pueden hacer
ese sprint, y estiman el tiempo que les tomará. Para esto, consideran la velocidad lograda en
sprints anteriores. Se hace un backlog para ese sprint particular: qué tareas tienen que hacer.
Al final de cada sprint, hay una reunión de evaluación con todo el equipo, donde se ve cómo se
puede mejorar la forma en que trabajaron y dan datos del producto para hacer el product
backlog del siguiente sprint. El ScrumMaster suele tener que dar reportes a sus superiores, y
pueden tener que gestionar proyectos.
Hoy en día, muchas empresas tienen equipos distribuidos donde los miembros están por todo
el mundo. Se ha desarrollado, entonces, el Scrum distribuido para estos casos. Incluye
comunicación por chat o videoconferencias, un IDE común y ambiente de integración.

Escalamiento
La necesidad de obtener software más rápidamente se aplica a sistemas y empresas grandes, y
por eso se ha intentado evolucionar los métodos ágiles para usarlos en estas circunstancias.
Suele ser necesario escalar hacia arriba y hacia afuera al mismo tiempo, pues software grande
se encarga a empresas grandes. Los métodos ágiles no aportan tanta productividad y
disminución de los efectos en estos casos.
Cuando se hace un contrato, normalmente la documentación de los requerimientos es parte
del mismo, pero esto no existe en los métodos ágiles. En consecuencia, el cliente paga por el
tiempo que toma hacer el sistema y no por los requerimientos solicitados. Esto puede llevar a
disputas sobre quién debe pagar si el sistema se demora.
En la práctica, la documentación formal del sistema no suele ser actualizada, y por eso los
promotores de métodos ágiles sostienen que es innecesaria, y que con código legible y de
calidad es suficiente para que el sistema se pueda mantener. Sin embargo, los requerimientos
de sistema le dicen al ingeniero qué debe hacer el sistema, y sin el mismo el mantenimiento se
hace más difícil. Esto es peor si no se puede garantizar la continuidad del equipo.
Es importante mantener al cliente involucrado, que puede perder interés cuando el sistema
está hecho y no tener interés en el mantenimiento. Si el equipo de desarrollo no se mantiene,
se pierde el conocimiento implícito que sus miembros tenían del sistema y para el cual no
necesitaban documentación. Esto hace que sea difícil para nuevos miembros entender qué
hace el sistema. Es, además, difícil que el equipo de mantenimiento sea continuo, pues a los
programadores no les agrada hacer estas tareas y se van a nuevos proyectos.
Para escalar métodos ágiles, es fundamental integrarlos con enfoques dirigidos por planes,
sobre todo en grandes compañías. Los principios de metodologías ágiles no siempre se pueden
llevar a cabo. Para decidir el balance, hay que hacerse preguntas de carácter técnico, humano
y profesional.
Los sistemas grandes tienen varios aspectos que requieren planeación y documentación.
Cuanto más grande y complejo sea el sistema, más necesario es dirigirse por planes. Además,
si tienen larga vida o están sujetos a regulaciones, requieren documentación.
Los métodos ágiles ponen mucha confianza en el equipo para que se comunique, coopere, y en
las habilidades de cada individuo, pero esto no siempre es así, por lo que se puede requerir
planeación. Los métodos ágiles requieren más habilidad que los de planes, donde el individuo
12

simplemente convierte el diseño en código, y si se tiene gente con poca habilidad, puede ser
necesario poner a los mejores en diseño. Si el equipo está distribuido, es necesario hacer
documentación para comunicarse. Finalmente, los métodos ágiles requieren ciertas
tecnologías para visualizar el diseño y programación. Si no se tienen, se requiere
documentación.
Las organizaciones tienen procedimientos, y puede que los administradores no acepten la falta
de documentación y formalidad. Se puede usar planes para los requerimientos, pero luego
hacer el sistema con métodos ágiles. También sucede que la cultura de un lugar está
acostumbrada a la documentación del enfoque por planes.
Los factores que influencian esta decisión, entonces, son:

Los métodos ágiles tienen que evolucionar para sistemas grandes, ya que son mucho más
complejos que sistemas pequeños o productos de software. Esto se debe a seis factores de los
sistemas grandes:
1. Son sistemas de sistemas, y cada sistema es hecho por un equipo diferente y apartado
del resto. Esto significa que la mayoría no ve el sistema completo, sino sólo su parte.
2. Son sistemas brownfield, es decir, incluyen e interactúan con varios sistemas
existentes. Muchos de los requisitos del sistema se ocupan de esta interacción, y no
dan mucha posibilidad de flexibilidad o desarrollo incremental.
3. Cuando hay varios sistemas integrando uno solo, parte importante del desarrollo es la
configuración de sistema, que tampoco se presta para el desarrollo incremental.
4. Suelen estar limitados por regulaciones y reglas externas que pueden requerir ciertos
tipos de documentación de sistema.
5. Tienen un largo tiempo de procuración y desarrollo, lo cual hace difícil mantener un
equipo de personas que sepan del sistema todo ese tiempo, pues se van.
6. Suelen tener muchas personas interesadas con diferentes objetivos, y es
prácticamente imposible involucrarlos a todos en el desarrollo.

El modelo de escalamiento ágil (ASM) de IBM reconoce que es un proceso en etapas. La

primera es ir de las prácticas ágiles básicas a entregas ágiles disciplinadas, donde se adaptan
las prácticas a un entorno organizado y disciplinado, y se reconoce la importancia de aspectos
como los requerimientos y diseño, no sólo desarrollo. La etapa final es ir a agilidad en escala
donde se reconoce la complejidad de grandes proyectos. Esto implica ser consciente de
13

factores como desarrollo distribuido y regulaciones. Para esto puede ser necesario modificar
las prácticas de la etapa anterior y agregar prácticas dirigidas por planes al proceso.
Para escalar metodologías ágiles hay que tener en cuenta lo siguiente:
1. Un enfoque completamente incremental es imposible; hay que trabajar en los
requerimientos antes de empezar para identificar las diferentes partes del sistema. Sin
embargo, no tiene por qué hacerse en detalle.
2. No puede haber un único product owner o representante del cliente. Varias personas
deben involucrarse en distintas partes del sistema, y comunicarse durante el
desarrollo.
3. No puede enfocarse sólo en el código. Tiene que haber documentación del sistema y
su arquitectura, el diseño y aspectos críticos.
4. Deben diseñarse y usarse métodos de comunicación entre equipos: llamadas,
videoconferencias, emails, según la frecuencia de la comunicación.
5. La integración continua (hacer todo el sistema cada vez que hay algún cambio) es
imposible si tiene muchas partes, pero es importante hacer versiones regularmente.

Para desarrollo a gran escala, existe el multi-team Scrum, cuyas claves son:
1. Repetición de roles: cada equipo tiene un ScrumMaster y un Product Owner para su
componente, y puede haber uno principal para todo el sistema.
2. Arquitectos de producto: cada equipo elige un arquitecto, quienes trabajan juntos
para diseñar y elaborar la arquitectura general del sistema.
3. Alineación de versiones: las fechas para las nuevas versiones de cada equipo se
alinean para tener un sistema completo.
4. Scrum de Scrums: hay un Scrum de Scrums diario donde representantes de cada
equipo se juntan a hablar del progreso y planear el trabajo.

Puede ser difícil introducir metodologías ágiles en organizaciones grandes por varias razones:
 Administradores de proyectos sin experiencia en estos métodos pueden no querer
tomar el riesgo de un nuevo enfoque, al no saber cómo va a afectar sus proyectos.
 Las organizaciones grandes suelen tener procedimientos y estándares de calidad que
todos los proyectos deben seguir y, por naturaleza, son incompatibles con los métodos
ágiles.
 Los métodos ágiles funcionan mejor con gente muy habilidosa, pero en organizaciones
grandes hay muchos niveles de habilidad, y los menos habilidosos pueden ser menos
efectivos en procesos ágiles.
 Resistencia cultural a métodos ágiles.

La administración de los cambios, por ejemplo, entra en conflicto con la refactorización, ya que
la primera requiere que los desarrolladores pidan autorización para hacer un cambio, a
diferencia de la segunda. El testing puede derivarse a un equipo externo, lo que entra en
conflicto con el desarrollo por pruebas. Es difícil introducir estos cambios, pues son culturales,
y lo mejor es hacerlos de a poco, comenzando con un grupo.
14

Ingeniería de requisitos

Clase 1 – capítulo 4 (+ Wiegers)

Los lectores de los requerimientos de usuario no están interesados en cómo se implementará
el sistema y pueden ser administradores. Los lectores de los requerimientos de sistema
necesitan más detalles, porque lo implementarán o les interesa saber cómo apoyará los
procesos de negocio.

Es importante considerar los requisitos a alto nivel antes de comenzar su ingeniería en detalle.
De este modo, se pueden comprender para luego ver si es posible hacer el sistema.

Requerimientos funcionales y no funcionales

La distinción entre requerimientos funcionales y no funcionales puede no ser clara, pues un
requerimiento suele generar o restringir otro. No sólo especifican las características del
sistema, sino también las funcionalidades necesarias para que estos servicios se den
efectivamente.
Los requerimientos funcionales expanden los requerimientos de usuario y se hacen para los
desarrolladores del sistema, agregando funciones, entrada, salida y excepciones. Pueden ser
generales o muy específicos, reflejando la forma de trabajar o un sistema ya existente. Los
requerimientos de información especifican la información necesaria y cómo se va a entregar y
organizar. Se usan cuando los requerimientos funcionales son innecesarios porque se usa
software COTS. No es posible lograr sistemas completos y consistentes si son grandes, debido
a la complejidad y la variedad de usuarios con distintas necesidades.
Se puede encontrar la forma de trabajar con una función que no es la buscada.
Los requerimientos no funcionales no están relacionados con los servicios. Se dan por
restricciones de presupuesto, políticas, interoperabilidad o regulaciones.
15

Algunas formas de medir si el sistema cumple un objetivo de usuario son:

De este modo, se puede verificar que los requerimientos no funcionales se cumplan. Puede ser
muy costoso. Este tipo de requisito puede interactuar e incluso entrar en conflicto con otros,
de cualquier tipo.
16

Procesos de ingeniería de requerimientos

La cantidad de tiempo y esfuerzo dedicados a cada actividad en una iteración dependen del
progreso de todo el proceso, el tipo de sistema y el presupuesto. Al principio, se procura
entender requerimientos de alto nivel y no funcionales, así como de usuario. Más adelante, se
le dará más tiempo a obtener requerimientos no funcionales y requerimientos de sistema
detallados. El modelo espiral permite ser usado en distintos tipos de metodología, con más o
menos detalle de los requerimientos. En casi todos los sistemas, los requerimientos cambian.
El objetivo de la obtención de requisitos es entender el trabajo de los interesados y cómo
podrían usar un sistema para ayudarlos. Estos pueden hacer demandas no realizables, por
ignorancia, o expresarse con un conocimiento implícito que evita que los ingenieros entiendan.
Cada organización tiene su versión de las etapas del proceso de obtención de requerimientos,
pues depende de factores como el conocimiento de los trabajadores y el tipo de sistema. El
proceso entero es iterativo, donde cada actividad les da retroalimentación a otras, y en cada
ciclo mejora la comprensión de los requerimientos, hasta llegar a un documento.
Una forma de agrupar los requerimientos para ayudar a analizarlos es considerar cada grupo
de interesados como un punto de vista y juntar todos los requerimientos de ese grupo en ese
punto de vista. También se puede identificar subsistemas dentro de la arquitectura y agrupar
los requerimientos según esos subsistemas. Es importante tener reuniones frecuentes con los
interesados para que puedan expresar sus inquietudes y lograr compromisos. Para que éstos
entiendan los requisitos, en esta etapa es importante usar lenguaje y diagramas simples.
Se puede complementar la información de la obtención de requisitos con conocimiento de
sistemas existentes y varios tipos de documentos.

Técnicas para obtención de requisitos

Hay que entender cómo trabaja la gente, cómo usa otros sistemas y cómo tienen que cambiar
para adaptarse a un nuevo sistema. Hay dos formas fundamentales de hacer esto: entrevistas,
donde se le habla a la gente de lo que hace, y observación o etnografía, donde se observa a la
gente trabajando. Se deberían mezclar ambas.
Las entrevistas, sean formales o informales, suelen ser parte de los procesos de ingeniería de
requerimientos. Se hacen preguntas tanto del sistema que usan como del que se va a
desarrollar. Las personas suelen no revelar la verdadera estructura de poder de la
organización, por lo que esta información no se podrá obtener. Las entrevistas se usan en
conjunto con descripciones de procesos de negocio o sistemas existentes, y observaciones de
los usuarios, para definir los requerimientos.
17

Clase 2 – capítulo 4.3 y 5

Es importante entender los aspectos sociales y organizacionales que afectan cómo se usa el
sistema, y para esto es la etnografía. El analista se introduce en el entorno donde se usará el
sistema y observa el trabajo día a día, tomando notas de las tareas realizadas. Permite
encontrar requerimientos implícitos que reflejan la forma de trabajo usada realmente.
A las personas les cuesta hablar del trabajo, pues omiten cosas que no creen importantes sin
entender cómo se relacionan con otras áreas. La etnografía, entonces, es muy útil para
descubrir dos tipos de requerimientos: los derivados de la forma en que se trabaja realmente,
en vez de cómo deberían trabajar según los procesos formales, y los derivados de la
cooperación y ser conscientes de las actividades de otros.
La etnografía puede usarse con un prototipo, dando información para que se requieran menos
ciclos. Además permite identificar problemas y preguntas para que el etnógrafo haga luego.

La etnografía es útil para entender sistemas existentes, pero no siempre ayuda a la innovación.
Si bien revela detalles críticos que ninguna otra técnica logra, se enfoca mucho en el usuario y
por lo tanto no encuentra requerimientos de mayor alcance. Por eso se combina con otros
métodos.

Escenarios, casos de uso e historias de usuario

Tanto las historias como los escenarios son una descripción de cómo se puede usar el sistema
para una tarea, explicando qué hace la gente, qué información usan y producen, y qué
sistemas usan para esto. Sin embargo, las historias se escriben de forma narrativa y en alto
nivel, mientras los escenarios son estructurados y tienen información como entradas y salidas.
La ventaja de las historias es que todo el mundo puede entenderlas fácilmente, y luego parte
de éstas se convierten en un escenario específico. Esto son sesiones de interacción del usuario
con el sistema. Las historias de usuario en métodos ágiles como XP son escenarios narrados.
Un escenario comienza con un esquema de la interacción. Durante el proceso de obtención, se
agregan detalles para crear una descripción completa de esa interacción. Los escenarios
pueden usarse para facilitar discusiones con interesados que pueden tener formas diferentes
de lograr el mismo resultado.
La diferencia entre los casos de uso y las historias de usuario:
18

Las historias de usuario dan una idea precisa de las necesidades del usuario. Los casos de uso
van más allá y describen cómo se imagina el usuario interactuando con el sistema.
Los casos de uso permiten al usuario tener una mejor idea de qué esperar, revelar
ambigüedades, designar las funcionalidades necesarias y definir prioridades y objetos
importantes.

Clase 3 (ya no sé qué capítulo porque las ppt están en cualquier orden)
En su especificación, los requerimientos deberían ser claros, no ambiguos, fáciles de entender,
completos y consistentes, cosa que es casi imposible en la práctica. Los interesados entienden
los requerimientos de forma diferente. Los requerimientos de sistema explican cómo el
sistema va a hacer sus funciones.
Crear un formato estándar hace que las omisiones sean menos probables y ayudar a verificar
los requisitos. Al incluir una explicación de un requisito, se debe incluir quién lo sugirió, pues
esa persona será a quien se le hagan consultas del mismo.
Al usar una notación estructurada, la especificación es menos variable, y los requerimientos se
organizan más efectivamente. Las tablas, por otro lado, muestran cómo se da la computación,
cómo cambia el estado del sistema, cómo interactúan los usuarios con el sistema y cómo se
hacen las acciones.
Dos objetivos principales de escribir requerimientos son: que cualquiera que los lea llegue a la
misma interpretación que otro, y que la misma sea lo que el autor quiso comunicar. Hay que
ser claro y conciso, y evitar escribir cosas de la forma A/B. No ser ambiguo a la hora de
especificar valores límite, y usar tablas o árboles de decisión para representar lógica compleja
y asegurarse de que se consideran todos los casos.
19

Clase 4
Los modelos se usan durante el proceso de ingeniería de requerimientos para derivar los
requerimientos detallados del sistema, durante el proceso de diseño para describir el sistema
a implementar, y luego de la implementación para documentar la estructura y operación del
sistema.
Un modelo de sistema no es una representación completa, sino que deja detalles fuera para
ayudar a su comprensión; es una abstracción, que tiene los detalles más importantes (la
representación tiene todo). La notación gráfica de estos modelos es flexible.

Modelos de contexto
Para definir los límites del sistema, hay que trabajar con los stakeholders. Cuando el rango de
usuarios es muy diverso, hay distintas necesidades que satisfacer. En este caso, puede no
definirse el límite, sino definir un sistema configurable para adaptarlo a las distintas
necesidades. La definición del límite es muy subjetiva, pues puede involucrar aspectos no
técnicos, como sociales o de la organización.
Luego de esta etapa, se define el contexto y las dependencias de un sistema respecto de su
entorno. Los modelos de contexto suelen mostrar que el entorno incluye otros sistemas
automatizados. Las relaciones con estos sistemas son importantes, ya que pueden afectar al
sistema en cuestión según sus características, que pueden variar. Por esto, además de los
modelos de contexto se usan otros modelos, como modelos de proceso de negocios.
Un diagrama de actividades UML muestra las actividades y flujo de control de un proceso. El
comienzo se representa con un círculo, el final con un círculo adentro de otro y las actividades
con rectángulos de puntas redondeadas. Se pueden incluir objetos. Las flechas muestran el
flujo de trabajo de una actividad a otra, y una barra muestra coordinación de actividades. Si
varias actividades llegan a una barra, todas deben terminar para poder seguir. Si varias flechas
salen de una barra, pueden hacerse las actividades paralelamente. Las flechas pueden tener
guardas.
20

Modelos de interacción
Los modelos de caso de uso y diagramas de secuencia tienen diferentes niveles de detalle y
pueden ser usados en conjunto.
Los diagramas de secuencia pueden modelar las interacciones entre los objetos. Los
rectángulos en las líneas indican el momento en que ese objeto está involucrado en la
computación, y se leen de arriba hacia abajo. En las flechas se indican llamadas a los objetos,
parámetros y retorno. Por lo general no es necesario incluir todas las interacciones, pues
algunas dependerán de la implementación.

Modelos estructurales
Los modelos estructurales pueden ser de toda la arquitectura o modelos detallados de los
objetos y sus relaciones. Cada clase puede necesitar saber algo de una clase asociada. En la
implementación, los objetos representan datos que son manipulados por el sistema. Los
diagramas incluyen multiplicidades.
UML se parece mucho a un MER: las clases son entidades, los atributos atributos de clase, y las
relaciones asociaciones. Para mostrar sólo las asociaciones, es mejor obviar los atributos. Se
pueden generalizar clases (como la categorización de un MER), con la ventaja de reusar
información y facilitar los cambios. También existe la agregación, una asociación donde un
objeto está compuesto de otros.

Modelos de comportamiento
Muchos sistemas de negocios son sistemas de procesamiento de datos, principalmente
manejados por datos. En cambio, los sistemas de tiempo real son manejados por eventos. Los
modelos dirigidos por datos muestran toda la secuencia de acciones desde la entrada hasta la
salida, por lo que pueden ser usados en el análisis de requerimientos.
Los diagramas de flujo de datos son simples e intuitivos, por lo que los stakeholders los
entienden. En ellos, las actividades se representan como rectángulos redondeados o círculos, y
los datos como rectángulos comunes (objetos).

También se pueden usar diagramas de secuencia en UML si sólo se envían mensajes de

izquierda a derecha.
Los diagramas de estado muestran los estados del sistema y los eventos que generan
transiciones de un estado a otro. No muestran datos. Se representan estados de inicio y fin con
21

círculos. Como la cantidad de estados posibles se vuelve grande, se pueden hacer

“superestados” que contienen una cantidad de estados separados. Esto ayuda a tener menos
detalle en el modelo general, pero se muestra en otro diagrama separado. Por lo general hay
que extender un diagrama de estado con una descripción más detallada de estímulos y
estados.
Los proponentes de la ingeniería dirigida por modelos argumentan que aumenta el nivel de
abstracción, de modo que los ingenieros no tengan que preocuparse por detalles de lenguaje o
plataformas. Se deriva de Arquitectura dirigida por modelos (MDA), la cual sí es aplicada,
aunque se enfoca sólo en el diseño e implementación.

Documento de requerimientos de software

Son esenciales cuando las circunstancias requieren documentación (equipo disperso, sistema
crítico). Si el sistema es crítico o lo hace otra compañía, se necesita ser muy específico. Se
puede incluir información de la evolución esperada del sistema, para ayudar en el
mantenimiento. Toda la información del estándar puede no ser necesaria en sistemas menos
complejos o desarrollados por incrementos, igual que el nivel de detalle. En ese caso, ciertas
cosas se dejan a criterio de los programadores.

Validación de requerimientos
Se superpone con la obtención y análisis, pues busca problemas con los requerimientos. Es una
actividad crítica, pues los errores en requerimientos implican retrabajo (cambiar diseño,
implementación, volver a probar, todo lo cual implica costos). Si al desarrollar pruebas para los
requerimientos, estas son muy difíciles, es probable que implementar el requerimiento
también lo sea.
Es difícil encontrar todos los problemas, y probar que el sistema cumple los requerimientos.
Hay que planear la obtención de los requerimientos, teniendo en cuenta lo siguiente:
 Objetivos: para el proyecto entero y para cada actividad
 Estrategia y técnicas planeadas: pueden combinarse (entrevistas, cuestionarios, etc.)
 Programación y estimación de recursos: identificar a quiénes participarán en las
actividades, el esfuerzo y tiempo necesarios
 Documentos y sistemas necesarios
 Producto esperado
 Riesgos: factores que pueden impedir completar las actividades
22

Diseño de software

Clase 1 - capítulo 7
El diseño y la implementación están muy relacionados, y se deben tener en cuenta aspectos de
implementación cuando se desarrolla un diseño. Para desarrollar un sistema del concepto al
diseño OO, hay que:
1. Entender y definir el contexto y las interacciones externas con el sistema
2. Diseñar la arquitectura del sistema
3. Identificar los objetos principales del sistema
4. Desarrollar modelos de diseño (cuyo nivel de detalle varía según la necesidad)
5. Especificar interfaces

Los modelos de diseño pueden ser estructurales, que describen la estructura estática del
sistema, o dinámicos, que describen cómo se espera que interactúen los objetos del sistema
en ejecución. Para esto, en UML, se usan los modelos de subsistema (objetos agrupados
coherentemente en subsistemas), secuencia y máquina de estados.
Existen patrones de diseño que se pueden aplicar; describen un problema común y su solución
(template de objetos y relaciones, así como el resultado), de forma que se puedan reusar.
En la implementación, es necesario tener en cuenta el reuso, las distintas versiones de
componentes (administración de configuración) y desarrollo anfitrión-objetivo (probar el
sistema en el equipo objetivo, pues se desarrolla en el anfitrión).
Los patrones de diseño o arquitectura son ejemplos de reuso a nivel abstracto. Los
componentes suelen tener que ser adaptados. Para reusar un sistema entero, se puede
agregar y modificar código o usar la interfaz de configuración del sistema. Reusar un software,
sin embargo, tiene sus costos: el tiempo necesario para encontrar COTS y decidir si satisface
las necesidades, pueden ser caro comprarlos, hay que adaptarlos e integrarlos al sistema.

Clase 2 - capítulo 6
Como parte del proceso de ingeniería de requerimientos, puede plantearse una arquitectura
para asociar funciones del sistema con componentes, lo que puede usarse para discutir los
requerimientos. Hay que analizar el sistema para explicitar la arquitectura, y esto afecta si el
sistema puede cumplir requisitos críticos.
Un modelo de arquitectura es el siguiente (cajas dentro de cajas indican que el componente
tiene subcomponentes, y las flechas representan el pasaje de datos o señales de control):
23

Son de alto nivel y fáciles de entender.

Un modelo arquitectónico puede usarse de dos modos: para generar discusiones sobre el
diseño del sistema, pues es más comprensible para los interesados al no tener mucho detalle y
enfocarse en componentes clave, y para documentar la arquitectura diseñada, en cuyo caso se
muestran más detalles, y simplifica la comprensión del sistema.

Decisiones de diseño
Hay que preguntarse cómo se estructurará el sistema y qué estrategia se usará para controlar
sus operaciones. Las decisiones en el proceso de diseño deben depender de: performance
(operaciones críticas en pocos componentes), seguridad (estructura en capas con los
elementos más críticos protegidos en las capas interiores), validación (elementos cercanos),
disponibilidad (componentes redundantes en caso de falla) y mantenibilidad (componentes
separados y autónomos).

Patrones de diseño
En una arquitectura de repositorio, por la organización de las herramientas, es eficiente
compartir grandes cantidades de datos, pues no es necesario enviarlos de un componente a
otro. Sin embargo, las herramientas tienen diferentes necesidades, por lo que es necesario un
compromiso, y puede ser necesario tener varias copias de los datos, lo que agrega overead.
Una arquitectura cliente-servidor se compone de: un conjunto de servidores que ofrecen
servicios a otros componentes, un conjunto de clientes que solicitan los servicios, y una red
que permite a los clientes acceder a estos servicios. Los servidores no necesitan conocer la
identidad o cantidad de sus clientes.
24

Clase 3 – capítulos 16 y 17
Ingeniería de software basada en componentes
Los componentes son definidos por sus interfaces, más grandes que objetos individuales, y los
detalles de implementación se ocultan. La ingeniería de software basada en componentes es el
proceso de definir, implementar e integrar estos componentes en sistemas. Es útil para
sistemas de gran escala, con requerimientos de seguridad y performance.
Tiene que haber una separación clara entre la interfaz y la implementación. Los estándares
definen, al menos, cómo especificar las interfaces e integrar los componentes, y permiten que
la operación sea independiente del lenguaje. El middleware maneja la comunicación entre
componentes, problemas de bajo nivel, y otras posibles adiciones. El proceso debe permitir
que los requerimientos evolucionen.
Los servicios estándar reducen la cantidad de código nuevo a desarrollar. Si el componente es
implementable, puede operar solo y no tiene que ser compilado antes de usar. Si es
independiente, no necesita de otros componentes (LO DE LAS PPT ESTÁ MAL). Para que sea
componible, todas las interacciones externas se deben hacer mediante interfaces. El
componente es definido por sus interfaces, que permiten ofrecer servicios. Las interfaces
provistas son la API.

Modelos de componentes
Los estándares permiten asegurarse de que los componentes pueden interoperar, y para que
los proveedores de middleware puedan apoyar la operación del componente. Los metadatos
del componente se refieren al propio componente. Un componente debe ser empaquetado
con todo el software que el mismo no provee. Para adaptarse a cambios, se pueden definir
reglas sobre el reemplazo de componentes. El middleware implementa los servicios comunes a
los componentes y provee interfaces.

Desarrollo para/con reuso

Los procesos básicos de CBSE con y para reuso tienen procesos de adquisición (para reusar o
convertir en reusable), administración y certificación de componentes.
En el desarrollo para reuso, la adaptación de un componente para ser reusable tiene un costo
que hay que considerar. Si un componente es reusable o no depende de su dominio de
aplicación, funcionalidad y generalidad. Los sistemas heredados (sistemas que tienen una
función importante pero están hechos con tecnología obsoleta) se pueden empaquetar,
escondiendo su complejidad. Hay que administrar el componente: clasificarlo, documentarlo,
subirlo a algún lado.
En el desarrollo con reuso, es importante el diseño de la arquitectura, pues debe ser robusta
para que el reuso sea exitoso. Hay que validar los componentes encontrados con casos de
prueba, y asegurarse de que no haya funcionalidades que no se usen, pues pueden causar
comportamientos inesperados.
La composición de componentes es el proceso de integrar componentes con otros, y escribir
“código pegamento” para juntarlos. En la composición jerárquica, puede ser necesario hacer
una conversión entre las interfaces. En la aditiva, los componentes no dependen uno de otro.
25

Puede haber problemas de incompatibilidad de parámetros, operaciones (nombres) o

incompletitud de las operaciones.

Sistemas distribuidos
La administración de este tipo de sistema suele ser difícil, pues hay que lograr acuerdos sobre
las políticas a usar, y suele ser lo que más limita cuánto se puede escalar un sistema. El scaling-
out suele ser más efectivo que el scaling-up, pero sólo si hay concurrencia. Es importante que
un sistema pueda defenderse de intercepción de comunicaciones, interrupción de servicios,
modificaciones o creación de información falsa. Es difícil establecer una política de seguridad
que se pueda aplicar a todos los componentes del sistema, pues distintas organizaciones
pueden ser propietarias.
Idealmente, los requisitos de calidad de servicio se especifican por adelantado y el sistema se
desarrolla para cumplirlos, pero esto no siempre sucede, pues pueden ser contradictorios, y
puede ser costoso mantener una alta calidad en todo momento.
En RPC tanto el que llama como el que es llamado deben estar disponibles y saber cómo
referenciarse el uno al otro, cosa que no sucede en la interacción por mensajes.

Patrones arquitectónicos para sistemas distribuidos

Los sistemas cliente-servidor dependen de que haya una clara separación entre la
presentación de información y las computaciones que la crean y procesan. Para esto, la
arquitectura de estos sistemas se divide en cuatro capas: presentación, manejo de datos,
procesamiento de aplicación y base de datos.
La arquitectura de cliente pesado aprovecha la capacidad de procesamiento del equipo del
cliente, distribuyendo mejor la carga; el servidor sólo se encarga de la base de datos. Por otro
lado, usar un modelo distribuido tiene la ventaja de poder reconfigurar el sistema (LA PPT
ESTÁ MAL, DE NUEVO).
En la arquitectura p2p, cada nodo debe tener una copia de la aplicación. Estos sistemas no se
usan mucho en los negocios porque son más difíciles de monitorear, al no haber un servidor
central, lo que también causa problemas de seguridad. En la arquitectura semicentralizada, el
rol del servidor es ayudar a establecer contacto entre dos nodos.

Software as a service
Para quienes compran el servicio, el beneficio de esto es que el costo de administrar el
software y arreglar problemas pasa al proveedor, quien tiene que manejar los cambios y el
hardware. Pero como se transfieren datos con un servicio remoto, puede demorar mucho si
éstos son muchos. Tampoco se puede controlar la evolución del software, o puede tener
problemas con leyes locales al cliente.
El desarrollo de servicios es parecido al de otros tipos de software, pero en vez de tener
requerimientos del cliente, el proveedor asume lo que necesitan los usuarios, y luego de
obtener retroalimentación de los mismos sobre el sistema puede cambiar (metodologías ágiles
e incrementales). El Saas es genérico, pero si se quiere hacer para una empresa, hay que tener
en cuenta configurabilidad, muchos dueños y escalabilidad (número desconocido de usuarios).
Cuando muchas personas comparten el software, debe parecer que cada uno de ellos es el
26

único usuario, lo cual crea un problema con el mantenimiento de datos. Se puede aislar a cada
uno en una misma base de datos.

Construcción
Clase 1 – Swebok
El área de construcción de software se relaciona sobre todo con el diseño y la verificación,
pues se hace el primero y se usa como ayuda para desarrollar pruebas. También se producen
elementos de configuración y código.
Algunas técnicas que soportan la construcción para la verificación son estándares de código
que soportan revisiones de código y pruebas unitarias, organizar el código para soportar
pruebas automatizadas, y restringir el uso de estructuras difíciles de entender. El reuso debe
ser sistemático, con un proceso claro y repetible, para mejorar la calidad y costos. Los
estándares permiten lograr objetivos de eficiencia, calidad, y costo. Pueden ser métodos de
comunicación, lenguajes, estándares de código, plataformas o herramientas.
La gestión de la construcción involucra considerar el ciclo de vida a usar, la planificación y la
medición de la misma, para verificar la calidad. En general, la construcción de software es más
que nada hacer código y debuguear, pero también planificación de la construcción, diseño
detallado, pruebas unitarias y de integración, y otras actividades.

Consideraciones prácticas
Son muy importantes en la construcción, debido a las restricciones del mundo real. El diseño
en la construcción es como el diseño en el proceso de software, pero a menor escala
(algoritmos, interfaces). Los lenguajes de construcción, que permiten especificar la solución,
pueden afectar aspectos de calidad de software como rendimiento o seguridad. Estos
incluyen: lenguajes de configuración (elegir de un conjunto de opciones predefinidas para
crear nuevas instalaciones de software), lenguajes toolkit (construir una aplicación a partir de
un toolkit, juego de partes reusables) y lenguajes de scripting (programar aplicaciones).
Un lenguaje de programación puede tener: notación lingüística, que es la más fácil de
entender y usa cadenas de texto para representar las construcciones, similar a una oración;
notación formal, que se basa en definiciones formales o matemáticas, y es menos ambiguo; y
notación visual, que usa interpretación visual (íconos), que puede ser difícil para representar
instrucciones complejas.
En la construcción para el reuso, hay que implementar la variabilidad, encapsularla para que el
software sea fácil de configurar, testearla y describir y publicar el software reusable. La calidad
de construcción puede verse afectada por las fallas. La técnica a usar depende del tipo de
software y de las habilidades del programador, y se centra en el código.
En la integración hay que considerar la planificación la secuencia en la que se hará y el trabajo
hecho sobre los componentes antes de integrarlos, entre otras cosas. La integración “big bang”
no se hace hasta que todos los componentes estén listos. La integración integral tiene varias
ventajas, como mayor facilidad para encontrar errores y monitorear el progreso, y entregar el
producto antes. Se escribe un programa de prueba en partes pequeñas y se van integrando de
a una.
27

Tecnologías de construcción
El diseño de una API debería hacerla fácil de usar y memorizar, lograr código legible, ser fácil
de entender, completa y mantener la compatibilidad hacia atrás. Su uso tiene las implicaciones
de una construcción con reuso. En los tipos genéricos, los tipos no especificados se pasan
como parámetros al ser usados. Se piensa que el diseño por contrato puede mejorar la calidad
de construcción de software, al proveer una especificación precisa de la semántica de una
rutina.

El manejo de excepciones debe diseñarse siguiendo principios comunes como incluir en el

mensaje de excepción la información necesaria, y evitar bloques catch vacíos. En la tolerancia
a fallas, si no se puede recuperar de un error, se intenta contener sus efectos, por ejemplo
retrocediendo y reintentando o usando código auxiliar.

La programación basada en estados usa los grafos de transición de una máquina de estados
en todas las etapas del desarrollo, buscando construir un programa de forma más
automatizada. El código basado en tablas puede ser más fácil de entender y modificar que la
lógica. Se considera qué información guardar y cómo acceder a ella eficientemente. El
procesamiento de entradas basado en gramática involucra la creación de un árbol sintáctico
que se recorre para obtener la expresión y variables de una tabla. Esto se usa como entrada.

El análisis de desempeño busca identificar puntos en el programa que pueden ser mejorados.
La puesta a punto del código implica hacer cambios pequeños en un único elemento que ya es
correcto. Los estándares de plataforma requieren que la plataforma compatible implemente
algún servicio o API.

Respecto a las herramientas de construcción, los constructores de GUIs suelen generar el

código para un elemento visual, o asistir en esta tarea. Las pruebas unitarias verifican el
funcionamiento de módulos aislados. También hay herramientas para analizar el rendimiento
(como herramientas que hacen un perfil del programa), y ejecutar un conjunto particular de
sentencias que pueden afectar el valor de ciertas variables, para buscar errores.
28

Verificación y validación

Verificación y validación – capítulo 8 (apenas) + Spillner capítulos 2 y 3

El testing es necesario porque como el software no es un producto físico, no puede examinarse
directamente. Leer la documentación o el código no sirve para probar el comportamiento
dinámico. Se necesita documentación, y disminuye el riesgo de usar el software al encontrar
defectos. Un problema es que la falta y la falla que causó pueden estar muy lejos una de otra.
Los problemas de entendimiento del software pueden causar errores del programador.

Las pruebas pueden hacerse para obtener información del producto, permitiendo tomar
decisiones. Planearlas y diseñarlas es parte del proceso. Tienen condiciones, y pueden
combinarse una tras otra para crear escenarios. El nivel de una prueba se refiere a si es una
prueba de sistema, de integración o unitaria.

El objetivo del testing es la verificación y validación. En ambas se puede hacer inspección y

revisión de código. Las inspecciones pueden encontrar varios errores, temas de calidad y
hacerse sobre versiones incompletas. La confianza que se debe tener para el sistema depende
de su propósito (cuanto más crítico, más seguro debe ser), las expectativas de los usuarios y el
mercado.

Pruebas de integración
Las pruebas de integración suelen tener problemas con las interfaces, ya sea porque no se
usan bien, no se entienden o hay diferencias en la velocidad de operación. La arquitectura de
sistema determina los componentes y cómo se relacionan entre sí, y el plan de proyecto
determina en qué momento se desarrollan las partes del sistema y cuándo están listas para ser
probadas. Las pruebas top-down y bottom-up tienen ventajas y desventajas opuestas con
respecto al uso y complejidad de stubs y drivers. Ad hoc requiere ambas cosas, lo cual es un
problema, si bien ahorra tiempo. En el esqueleto, se arma el esqueleto al que se le irán
agregando componentes, pero esto lleva tiempo.

Pruebas de sistema
Las pruebas de sistema se ejecutan desde el punto de vista del usuario final, y consideran
interacciones de todos los componentes (que pueden no haber sido contempladas en las
pruebas de integración).

Pruebas de aceptación
Las pruebas de aceptación contractuales se basan en contratos donde se definen los criterios
de aceptación, que se usan para las pruebas. Se hace en software específico para el cliente. Las
pruebas de aceptación del usuario se hacen porque el cliente y el usuario final pueden ser
diferentes, y los usuarios tienen diferentes expectativas del software. Las pruebas de
aceptación operacionales se hacen con los administradores del sistema.

Las pruebas de campo se hacen cuando el software debe correr en muchos entornos
diferentes y no se puede probar en todos. De este modo se pueden buscar problemas con
ciertos entornos. El alpha/beta testing consiste en enviar versiones previas y estables a clientes
para que las prueben y reporten problemas. El dogfood testing consiste en que otros
miembros de la compañía desarrolladora lo prueben.
29

Tipos de prueba y casos de prueba – Spillner, capítulos 4 y 5

Pruebas estáticas
El análisis en las pruebas estáticas se puede hacer en todos los documentos, y su objetivo es
encontrar defectos lo antes posible. La preparación individual se hace estudiando el objeto
intensivamente, comparándolo con la documentación y considerando la experiencia propia. El
líder no participa de la reunión de revisión porque puede cohibir a los demás participantes, o
no tener el conocimiento necesario. Las revisiones pueden fallar por problemas como falta de
habilidades, tiempo o documentación insuficientes, o no tener apoyo de la administración, que
limita los recursos.

Otras formas de pruebas estáticas son: revisiones técnicas, donde el enfoque es en la

concordancia del código con la especificación y estándares, los revisores deben estar
calificados y algunos no pertenecer al proyecto, y se deben lograr decisiones unánimes; y
revisiones informales, parecidas a las formales, donde el autor elige revisores para ver el
código, se intercambia información e involucra poco costo y esfuerzo. La técnica a usar
depende del tiempo, conocimiento y apoyo de la administración disponibles, y de la
formalidad del objeto. Se aplican por caso.

Una anomalía es una inconsistencia que puede llevar a una falla pero no necesariamente, por
ejemplo leer una variable no definida (de datos), o saltos fuera de un loop (de control). El
análisis estático permite obtener métricas para la calidad.

En las pruebas dinámicas es importante la trazabilidad de los casos de prueba, pues se pueden
tener muchos. Los tipos de estas pruebas son los siguientes.

Técnicas de caja negra

Los casos de uso se derivan de la especificación. La partición de las clases de equivalencia
permite evitar casos innecesarios, aunque es algo limitada en cuanto a entradas y salidas e
ignora relaciones entre condiciones. Si no hay un verdadero valor límite, se puede probar un
caso que esté en la clase y otro que no lo esté. Esta técnica lidia con el problema de límites
ambiguos.

Las pruebas de transición de estados se hacen ya que el historial de la ejecución tiene

influencia en la salida. Se basa en diagramas de estados. El sistema u objeto de prueba tiene
un estado inicial, y luego tiene diferentes estados causados por eventos. También se tiene un
estado final, con lo que se pueden obtener máquinas de estados finitos. Cuando el historial de
entradas cambia el comportamiento, se debe hacer una prueba de transición de estado, la cual
debe ejecutar todas las funciones de un estado. Para identificar casos de prueba, se convierte
la máquina en un árbol de transiciones, eliminando ciclos potencialmente infinitos y
alcanzando todos los estados y transiciones. Se debe tener claro el estado inicial, entrada,
salida esperada, estado final y secuencia de transiciones.

Hay varios tipos de pruebas basadas en la lógica. En los grafos de causa-efecto, se tiene en
cuenta las dependencias entre entradas. Cada causa es una condición compuesta por valores
de entrada. Las condiciones se conectan con operadores lógicos, por lo que cada una, y su
causa, puede ser verdadera o falsa. Los efectos son similares, y se transforman en una tabla de
30

decisiones de la cual se sacan los casos de prueba. Para esto se elige un efecto, se ve qué
combinaciones de causas lo provocan y cuáles no, se incluyen en la tabla en una columna y se
eliminan repeticiones. Cada columna es un caso de prueba.

El pairwise testing se usa para examinar interacciones desconocidas entre parámetros que son,
en principio, independientes, buscando interacciones destructivas. Partiendo de las clases de
equivalencia, para cada una se elige un valor representativo y se combina con el representante
de cada una de las otras clases.

Técnicas de caja blanca

En el cubrimiento de sentencias, cada caso de prueba debe ejecutar un mínimo de ellas. Se
hace un grafo de flujo de control para ver cómo se pasa de una sentencia a otra, y de allí se
derivan los casos de prueba. Se puede detectar código inalcanzable. No puede encontrar
sentencias faltantes, a diferencia del cubrimiento de decisión. Ninguno es adecuado para
sistemas orientados a objetos, donde las funciones de cada clase son cortas y simples.

Gestión de las pruebas

Es necesario priorizar las pruebas, pues puede no ser posible ejecutar todos los casos de uso.
Esto se puede hacer siguiendo criterios como frecuencia de uso de la función, riesgo de falla o
prioridad del requerimiento. También hay que definir las entradas. Si no se hacen pruebas, hay
costos de defectos directos e indirectos, así como el costo de corregir.
31

Evolución del software

Clase 1 – capítulo 9.1

La evolución del software es particularmente costosa en sistemas de sistemas, pues un cambio
afecta a todos. El modelo en espiral es aplicable si la misma empresa se encarga siempre de la
evolución. Esto no suele suceder, en cuyo caso se dan discontinuidades en el proceso
evolutivo. El pasaje de evolución a servicio se da cuando la implementación de nuevas
funcionalidades ya no es eficiente.

No hay un proceso estándar de evolución; puede ser formal o informal, dependiendo del tipo
de sistema. Si hay documentación, la misma debería ser actualizada junto con el sistema.
Luego de una reparación de emergencia, se debería refactorizar el código para mejorarlo.
Técnicas ágiles como desarrollo basado en planes son útiles para hacer cambios en el sistema,
pero pueden tener que ser modificados para mantener un programa. No se puede involucrar a
los usuarios en el equipo porque puede haber muchos stakeholders, o puede tener que
interrumpirse un ciclo para hacer una reparación de emergencia.

Clase 2 – capítulo 9.2, 9.3

Las razones por las cuales un cambio en una capa puede cambiar las de arriba y las de abajo
son tres: pueden introducirse nuevas características que las capas superiores pueden
aprovechar, se puede enlentecer el sistema, por lo que se necesita nuevo hardware, y es a
menudo imposible mantener interfaces de hardware.

Los sistemas de bajo valor empresarial y alta calidad no aportan mucho al negocio, pero no son
caros de mantener. Se puede seguir usando siempre que los cambios no se vuelvan muy
costosos, en cuyo caso hay que desecharlo. El entorno es importante porque los cambios en él
afectan al sistema. Hay que evaluar interoperabilidad, confiabilidad de proveedores, entre
otros. En cuanto a la aplicación, se puede evaluar facilidad de comprensión, documentación,
rendimiento, entre otros.

En la práctica, los tipos de mantenimiento no están perfectamente distinguidos. En teoría, si se

hace software que sea fácil de mantener, a la larga se ahorrará dinero, pero esto es difícil de
probar. Además, las compañías quieren reducir sus gastos en el corto plazo, y los
desarrolladores no ven el beneficio de hacer algo mantenible, pues no serán ellos quienes lo
hagan. Por eso hay que integrar el desarrollo y mantenimiento.

Puede no ser necesario hacer todos los pasos del proceso de reingeniería. Tiene sus
limitaciones prácticas (no se puede cambiar de paradigma, por ejemplo). La refactorización es
efectiva para reducir los costos de mantenimiento si se hace durante el desarrollo, pero si se
toma un programa con una estructura muy degradada, puede ser casi imposible refactorizar
sólo el código. Puede ser necesario refactorizar el diseño, lo que es más caro y complejo.
32

Gestión de la configuración – capítulo 25

La gestión de versiones es fundamental en los equipos de desarrollo distribuidos y en
desarrollo ágil. Para esto se usan herramientas de diversos tipos. En los sistemas grandes,
siempre hay varias versiones en desarrollo, y la gestión de configuración es parte de la gestión
de calidad. Uno de los términos usados es repositorio, una base de datos de versiones y
metadata. El control de versiones buscar controlar lo que sucede cuando los desarrolladores
toman componentes del repositorio común, los modifican en su workspace privado y luego los
vuelven a poner.

Un sistema VC distribuido es Git. Este modelo tiene ciertas ventajas: provee un respaldo,
permite trabajar offline y cada uno puede probar el sistema entero en su máquina. Este tipo de
sistema es fundamental cuando varias personas trabajan sobre un mismo sistema. Se pueden
crear varias ramas a partir del mismo código, luego hay que hacer merge. Para ahorrar espacio
y no tener que almacenar varias copias de lo mismo, se pueden guardar deltas, que son las
diferencias entre una versión y otra.

El tamaño y tipo de software influyen en el proceso de gestión de cambios (por ejemplo: quién
sugiere los cambios, el cliente en software particular), pero todos tienen que comprobar,
calcular costo y verificar los cambios. Hay que verificar que una solicitud de cambio sea válida
(no puede hacerse si ya existe o es inválida). Luego se evalúa el impacto en el resto del sistema
y el costo para ver si vale la pena. Esto lo hace el comité.

Por el tema de las diferentes versiones y de dónde provienen sus componentes, es importante
que haya documentación para poder recrear el sistema. Hay que guardar la versión de todo lo
usado.
33

Gestión de proyectos

Clase 1 – capítulos 22 y 23.2

Para calcular el costo de un proyecto, se usan tres parámetros: costo de esfuerzo (salarios),
costo de hardware y software y costos de entrenamiento y viajes. El primero suele ser el
mayor. El proyecto siempre cambia durante el desarrollo. Si se usa un método ágil, igual se
necesita un plan para comenzar, pero no es tan detallado. Para determinar el precio, se puede
hacer en base a un precio que la compañía supone que el cliente espera pagar.

Un plan de proyecto incluye la organización del mismo, análisis de riesgo, recursos, división del
trabajo y tiempos, entre otros. Al hacer el plan, hay que tener en cuenta restricciones de
tiempo y recursos. Las estimaciones deben ser realistas, considerando que siempre surgen
problemas, y tener planes de contingencia. Hay que ir revisando el progreso con las metas
logradas. Si hay problemas serios que pueden provocar muchos retrasos, hay que replanificar
el proyecto, que puede implicar una nueva negociación con el cliente, e incluso una
cancelación del proyecto si no se logra un acuerdo.

Clase 2 – capítulo 23.3

Al aumentar la complejidad del software, aumentan los costos. Los puntos de aplicación en
COCOMO se calculan a partir de la cantidad de pantallas separadas que se muestran, la
cantidad de reportes producidos, la cantidad de módulos en lenguajes imperativos y la
cantidad de líneas de lenguaje de scripting o programación de base de datos. En cuanto al
reuso, se consideran elementos de caja negra (se puede usar sin entender cómo se
implementa) y blanca (hay que hacer cambios). Se mide el esfuerzo de decidir si un
componente puede ser reusado, entender el código y modificarlo. En el post-arquitectura, se
vuelven a evaluar las líneas de código.

Clase 3 – capítulo 22.1

Las categorías de los riesgos pueden superponerse. Los riesgos dependen del tipo de proyecto
y del entorno. Algunos ejemplos comunes de riesgos son cambios de personal o de
administradores, de requerimientos, de tecnología o retrasos en la especificación. La gestión
de administración de riesgos debe ser documentada en grandes proyectos. El proceso es
menos formal en desarrollo ágil. La probabilidad e impacto de un riesgo pueden cambiar. Lo
preferible sería evitar el riesgo, pero como no siempre es posible, se tiene que recurrir a una
de las otras estrategias.

Clase 4 – capítulo 22.2

En la jerarquía de Maslow, los administradores deben satisfacer las necesidades superiores de
sus empleados: sociales (dar oportunidad de conocer a sus colegas), estima (mostrar que su
trabajo se valora) y autorrealización (responsabilidades de trabajo para que puedan mejorar
sus habilidades). Las personas orientadas a la interacción prefieren trabajar en equipo, a
diferencia de las orientadas a tareas o sí mismas, que prefieren trabajar solas. Se puede tener
varias de estas motivaciones, pero siempre hay una dominante.