PROCESOS DE SOFTWARE

Un conjunto estructurado de actividades necesarias para desarrollar un sistema de software. Muchos de los procesos de
software son diferentes, pero todos implican:

● Especificación - la definición de lo que el sistema debe hacer; entender cuáles son los servicios que tiene que proveer
nuestro sistema (ingeniería de requerimientos: descubre cuáles son las necesidades del usuario final)
● Diseño e implementación - la definición de la organización del sistema y la implementación del sistema;
● Validación - la comprobación de que hace lo que quiere el cliente.

Validación! = verificación (que haga lo que nos propusimos)

● Evolución - el cambio del sistema en respuesta a las necesidades cambiantes de los clientes. Cuando el producto
entra en operación, pero no nos asegura que esté 100% libre de errores.

Un modelo de proceso de software es una representación abstracta de un proceso, genera las metodologías de desarrollo.
Se presenta una descripción de un proceso a partir de una perspectiva particular.

Descripciones de procesos de Software

Prototipo, ayuda a mejorar la comunicación con el cliente sin perjudicar el proceso…

Cuando describimos y discutimos los procesos, por lo general hablamos de las actividades en estos procesos, como la
especificación de un modelo de datos, el diseño de una interfaz de usuario, etc., y el ordenamiento de estas actividades.

Descripciones de proceso también pueden incluir:

● Productos, que son los resultados de una actividad del proceso (cada producto es un proyecto);
● Roles, que reflejan las responsabilidades de las personas involucradas en el proceso;

Pre-y post-condiciones, que son declaraciones que son verdaderas antes y después de una actividad de proceso se ha
promulgado o elaborado un producto.

Proceso dirigido por Plan y procesos ágiles.

● En un desarrollo dirigido por plan todas las actividades (están puestas en fases) del proceso se planifican con
antelación y el progreso se mide en contra de este plan. No se puede avanzar a la siguiente fase si no terminé con la
anterior y se realiza en determinado orden.
● En los procesos ágiles, la planificación es gradual y es más fácil para cambiar el proceso para reflejar los requisitos
cambiantes de los clientes.
● En la práctica, la mayoría de los procesos prácticos incluyen elementos de ambos enfoques el dirigido por plan y el
ágil.
● No hay procesos de software correctos o incorrectos.

Importante el tiempo en el que se realiza el proyecto $$$

Modelos de procesos de SW

• El modelo de cascada: Modelo dirigido por Plan. Fases separadas y distintas de especificación y desarrollo.
• El desarrollo incremental: Especificación, desarrollo y validación se intercalan. Puede ser el dirigido por plan o ágil.
• Ingeniería de software orientado a reutilización: El sistema se ensambla a partir de componentes existentes Puede
ser el dirigido por plan o ágil.
En la práctica, la mayoría de los grandes sistemas se desarrollan mediante un proceso que incorpora elementos de
todos estos modelos.
1
 • Requerimiento: son las necesidades y funcionalidades que debe brindar un sistema y sus limitaciones (memoria,
cantidad de usuarios conectados de manera concurrente)

Modelo de cascada

1. Implica ver el sistema de manera completa, como un todo. Entrevistas a usuarios finales, a los roles que utilizaran el
sistema, ver las necesidades y como se negocian los requerimientos. (si el proceso es grande puede llevar hasta 6
meses). Una vez definidos y controlados paso al siguiente ->
2. Diseño de SW: Modelado del sistema y la estructura.
3. Empiezo a generar el código. Voy haciendo pruebas de desarrollo para ver que todo ande OK pero no es el testing final
4. Si está todo bien se integra y se hace un testing general por otro equipo
5. Finalmente, si todo anda bien se empieza a operación, pero puede haber errores, ahí entra mantenimiento. Los
cambios que impactan en los requerimientos. Y volvemos al paso 1

Fases del modelo cascada

Hay fases identificadas por separado en el modelo de cascada:

● El análisis de requerimientos y su definición

● El diseño del sistema y del software
● Implementación y prueba de unidades
● Integración y pruebas del sistema
● Operación y mantenimiento
● El principal inconveniente del modelo de la cascada es la dificultad de acomodar el cambio después de que está en
marcha el proceso. En principio, una fase tiene que ser completa antes de pasar a la siguiente fase.

Problemas del modelo cascada

● Inflexible, la división del proyecto en fases estructuradas hace difícil responder a las necesidades cambiantes de los
clientes. Por lo tanto, este modelo sólo es apropiado cuando los requisitos son bien entendidos y los cambios serán
bastante limitados durante el proceso de diseño.

POCOS SISTEMAS tienen requisitos estables.

2
 ● El modelo de cascada se utiliza sobre todo para los grandes proyectos de ingeniería de sistemas especialmente si
un sistema se desarrolla en varios lugares. En estas circunstancias el modelo de cascada ayuda a coordinar el trabajo
● El cliente no recibe nada funcional hasta que se terminó toda la cascada.
● Proceso crítico, después de que el producto está en operación, no se pueden hacer errores sin tener que volver a
arrancar el proyecto de 0.

Ventajas

● Documentación (quedan establecidos los límites del sistema)

● Asegurarnos que funciona todo

El desarrollo incremental

Beneficios

● El costo de atender las necesidades cambiantes de los clientes se reduce: la cantidad de análisis y la documentación
que tiene hacerse de nuevo es mucho menor que la que se requiere con el modelo de cascada.
● Es más fácil obtener retroalimentación de los clientes en el trabajo de desarrollo: los clientes pueden hacer
comentarios sobre el avance del desarrollo del software y probar lo que se ha implementado.
● Más rápida entrega y despliegue de software de utilidad para el cliente: los clientes pueden usar y obtener valor a
partir del software más rápidamente de lo que es posible con un proceso de cascada.
● Podemos corregir a tiempo los problemas que se presenten en funcionalidades críticas.

Problemas

● El proceso no es visible. Problema con la gestión de proyectos: los gerentes necesitan entregas regulares para medir
el progreso. No es rentable producir documentos que reflejen todas las versiones del sistema.
● Estructura del sistema tiende a degradarse (el SW y la documentación) a medida que se añaden nuevos incrementos:
se gasta menos tiempo y dinero en la refactorización para mejorar el software, lo que tiende a corromper su
estructura (SW de menor calidad). La incorporación de nuevos cambios se vuelve cada vez más difícil y costoso.
● Si no se pregunta no hay orden de prioridad. No se sabe cuál es la funcionalidad critica.

Ingeniería de SW orientada a la reutilización

Se basa en la reutilización sistemática de código, los sistemas se integran a partir de componentes o sistemas existentes.

Etapas del proceso

● Análisis de requerimiento;
● Análisis de los componentes;
3
 ● Modificación de requerimientos; pero cubriendo las mismas necesidades y lograr las mismas funcionalidades, incluso
maximizarlas.
● Configuración del sistema con la reutilización;
● Desarrollo e integración. Es difícil integrar todo

La reutilización es ahora el enfoque estándar para la construcción de muchos tipos de sistemas.

Tipos de componentes de SW

● Los servicios Web que se desarrollan de acuerdo a los estándares de servicio y que están disponibles para la
invocación remota.
● Colecciones de objetos que se desarrollan como un paquete para ser integrado con un marco de componentes
tales como. NET o J2EE.
● Sistemas autónomos de software (COTS) que están configurados para su uso en un entorno particular.
● Ya no se desarrollan más, solo se configuran para poder trabajar con ellos.

Actividades de Proceso

● Procesos de software reales son secuencias intercalados de actividades técnicas, de colaboración y de gestión con
el objetivo general de la especificación, diseño, implementación y prueba de un sistema de software.
● Las cuatro actividades básicas del proceso son: especificación, desarrollo, validación y evolución y están
organizados de manera diferente según el proceso de desarrollo. En el modelo de cascada, se organizan en
secuencia, mientras que en el desarrollo incremental son intercalados.

Especificaciones de SW

El proceso de establecer qué servicios son necesarios y las limitaciones de funcionamiento (cant de usuarios sin que se
rompa todo) y desarrollo (usar determinados lenguajes, DB, calidad) del sistema.

Ingeniería de Requisitos o Requerimientos

● Estudio de factibilidad: ¿Con la tecnología, presupuesto y tiempo, puedo o no? Hacer una lista general para ver si
se lleva a cabo o no.
○ ¿Es técnicamente y financieramente factible para construir el sistema?
● Requerimientos, obtención y análisis (se realiza si el anterior paso es posible), ver incoherencias, contradicciones,
etc. y se va documentando hasta tener la documentación definida.
○ ¿Que requieren los diferentes actores del sistema o esperan del sistema?
● Especificación de Requerimientos (documentación definida)
○ Definición de los requisitos en detalle. Si o si verificable
● Validación de Requerimientos
○ Comprobación de la validez de los requisitos. Volver a leer con el interesado para ver si es lo que necesitan
o no.

4
Proceso de ingeniería de requerimientos

Diseño de SW y la implementación

● Proceso de conversión entre la especificación del sistema en un sistema ejecutable.

● El diseño de software
○ Diseñar una estructura de software que da cuenta de la especificación;
● Implementación
○ Traducir esta estructura en un programa ejecutable;
● Las actividades de diseño e implementación están estrechamente relacionadas y pueden ser intercaladas.

Modelo general del proceso de diseño

Actividades de diseño

● Diseño arquitectónico, donde se identifica la estructura general del sistema, los componentes principales (a veces
llamados subsistemas o módulos), sus relaciones y la forma en que se distribuyen.
● Diseño de la interfaz, donde se definen las interfaces entre los componentes del sistema.
● Diseño de componentes, donde se toma cada componente del sistema y el diseño de cómo se va a operar.
● Diseño de base de datos, donde se diseña la estructura de datos del sistema y de cómo éstos han de estar
representados en una base de datos.

Validación del SW

● Verificación y validación (V & V) está destinado a demostrar que un sistema cumple con su especificación y cumple
con los requisitos del cliente.
● Involucra procesos de control, revisión y prueba del sistema.
5
 ● Las pruebas del sistema implican ejecutar el sistema con casos de prueba que se derivan de la especificación
utilizando datos reales.
● La prueba es la actividad de V & V más utilizada.

Etapas de prueba

Pruebas de Desarrollo o componente. (de caja blanca, porque las hace el que hizo el código)

● Los componentes individuales se prueban de forma independiente;

● Los componentes pueden ser funciones, objetos o agrupaciones coherentes de estas entidades.

Las pruebas del sistema (de caja negra)

● Pruebas del sistema como un todo. El ensayo de las propiedades emergentes es particularmente importante. Se
realiza por un equipo de testing.

Las pruebas de aceptación

● Las pruebas realizadas por el cliente para verificar que el sistema cumple con sus necesidades.

Fases de prueba en un proceso de SW

Evolución o mantenimiento del SW (no es testing)

● Se hace sobre un producto en operación. No sobre uno en desarrollo (testing)

● El software es inherentemente flexible y puede cambiar.
● Las circunstancias cambiantes de negocios hacen que el software que soporta la empresa también deba
evolucionar y cambiar.
● Si bien se habla de desarrollo y evolución (mantenimiento) como etapas diferentes, la diferencia es cada vez más
irrelevante, cada vez son menos los sistemas completamente nuevos.

6
Problema del cambio

El cambio es inevitable en todos los grandes proyectos de software.

● Cambios en el negocio conducen a requisitos nuevos y modificaciones del sistema

● Las nuevas tecnologías abren nuevas posibilidades de mejorar las implementaciones
● Cambio de plataformas requieren cambios en las aplicaciones
● Los costos del cambio incluyen tanto la reelaboración (por ejemplo, requisitos de re-analizar), como los costos de
implementación de nuevas funcionalidades

Reducción de los costos de rehacer

Evitar el Cambio, donde el proceso de software incluye actividades que pueden anticipar posibles cambios para evitar
repetir el trabajo. Por ejemplo, un prototipo del sistema puede ser desarrollado para mostrar algunas de las características
clave del sistema para los clientes.

Tolerancia al Cambio, en el que el proceso está diseñado de modo que los cambios pueden afrontarse con un costo
relativamente bajo. Esto implica alguna forma de desarrollo incremental. Los cambios propuestos pueden implementarse
en incrementos que aún no se han desarrollado. Sólo un único incremento (una pequeña parte del sistema) debe ser
alterado para incorporar el cambio.

SW prototipado

Un prototipo es una versión inicial de un sistema que se utiliza para demostrar conceptos y probar opciones de diseño. Un
prototipo se puede utilizar en:

● El proceso de ingeniería de requerimientos para ayudar con la obtención de requisitos y validación;

● En los procesos de diseño para explorar opciones y desarrollar un diseño de interfaz de usuario;
● En el proceso de pruebas.

Beneficios

● Mejora de la usabilidad del sistema.

● Una aproximación más exacta a las necesidades reales de los usuarios.
● Mejora de la calidad del diseño.
● Mejora de la capacidad de mantenimiento.
● Reduce del esfuerzo de desarrollo.

Proceso de desarrollo de prototipos

Desarrollo de prototipos

● Prototipo debe centrarse en las áreas del producto que no se conocen bien
● La comprobación de errores y recuperación pueden no estar incluidos en el prototipo
● Centrarse en los requisitos funcionales y no en los no funcionales tales como la fiabilidad y la seguridad.

7
Prototipos desechables

Los prototipos deben desecharse después de desarrollo ya que no son una buena base para un sistema de producción:

● Puede ser imposible para ajustar el sistema para cumplir con los requisitos no funcionales;
● Los prototipos son normalmente indocumentados;
● La estructura del prototipo se suele degradarse a través de un cambio rápido;
● El prototipo probablemente no va a cumplir con los estándares de calidad normal de la organización.

Entrega incremental

● En lugar de entregar el sistema en una sola vez, el desarrollo y la entrega se desglosan en incrementos, con cada
incremento se entrega de parte de la funcionalidad requerida.
● Requisitos de usuario se priorizan y se incluyen los requisitos de más alta prioridad en incrementos tempranos.
● Una vez que se inicia el desarrollo de un incremento, los requisitos están congelados, aunque los requisitos para
incrementos posteriores pueden seguir evolucionando.

DESARROLLO AGIL DE SW

Desarrollo rápido de SW

El rápido desarrollo y la entrega son ahora los requisitos más importantes para los sistemas de software

● Los requisitos de las empresas cambian rápidamente y es prácticamente imposible producir un conjunto de
requerimientos de software estable.
● El Software tiene que evolucionar rápido para reflejar los cambios en las necesidades del negocio.
● Especificación, diseño e implementación están intercalados
● El sistema está desarrollado como una serie de versiones con las partes interesadas involucradas en la evaluación
de versiones
● Las interfaces del usuario se desarrollan a menudo utilizando un IDE y herramientas gráficas.

Métodos agiles

Las insatisfacciones con los gastos involucrados en los métodos de diseño de software de los años 1980 y 1990 dieron lugar
a la creación de métodos ágiles. Estos métodos:

● Se enfocan en el código en lugar del diseño

● Se basan en un enfoque iterativo para el desarrollo de software
● Tienen la intención de ofrecer software de trabajo de forma rápida y evolucionar rápidamente para satisfacer las
cambiantes necesidades.

El objetivo de los métodos agiles es reducir los gastos generales del proceso de SW (por ejemplo, limitando la
documentación) y ser capaces de responder rápidamente a las necesidades cambiantes sin rehacer trabajo de manera
excesiva.

Manifiesto Ágil

Estamos descubriendo mejores formas para desarrollar software, al hacerlo y al ayudar a otros a hacerlo. Gracias a este
trabajo llegamos a valorar:

● A los individuos y las interacciones sobre los procesos y las herramientas

● Al software operativo sobre la documentación exhaustiva
● La colaboración con el cliente sobre la negociación del contrato
● La respuesta al cambio sobre el seguimiento de un plan
8
Aplicabilidad del método ágil

● Desarrollo de productos, donde una compañía de software está desarrollando un producto de pequeño o mediano
tamaño para la venta.
● El desarrollo de sistemas a medida para una organización, donde hay un claro compromiso por parte del cliente
para participar en el proceso de desarrollo y donde no hay muchas reglas y regulaciones externas que afectarán el
software.
● Enfoque en pequeños equipos, bien integrados, hay problemas en la ampliación de los métodos ágiles a grandes
sistemas

Problemas con métodos ágiles

● Puede ser difícil mantener el interés de los clientes que están involucrados en el proceso.
● Los miembros del equipo pueden ser inadecuados para la intensa participación que caracteriza a los métodos ágiles.
● Priorizar cambios puede ser difícil donde hay múltiples partes interesadas.
● Mantener simplicidad requiere un trabajo extra
● Los contratos pueden ser un problema

Métodos agiles y el mantenimiento de SW

La mayoría de las organizaciones gastan más en el mantenimiento del software existente que en el desarrollo de nuevo
software. Los métodos ágiles deben facilitar tanto el mantenimiento como el desarrollo inicial.

Dos problemas fundamentales:

● ¿Son los sistemas que se desarrollan utilizando un enfoque ágil mantenibles, haciendo énfasis en la minimización
de la documentación formal?
● ¿se pueden utilizar los métodos ágiles con eficacia para la evolución de un sistema?

Pueden surgir problemas si el equipo de desarrollo original no puede mantenerse.

Desarrollo guiado por plan y el desarrollo ágil

Desarrollo guiado por plan:

● Identifica etapas separadas en el proceso de software con salidas asociadas a cada etapa.
9
 ● Las salidas de una etapa se usan como base para planear la siguiente actividad del proceso.
● Las iteraciones se producen dentro de las actividades.
● Desarrollo Ágil
● Especificación, diseño, implementación y pruebas están intercalados.

La mayoría de los proyectos de software incluyen prácticas de los enfoques ágil y basado en un plan

Cuestiones técnicas, humanas y organizacionales

La mayoría de los proyectos incluyen elementos del plan guiado y procesos ágil. La decisión sobre el equilibrio depende de:

● ¿Es importante contar con una especificación y diseño muy detallado antes de pasar a la implementación? Si es así,
es probable que tenga que utilizar un enfoque guiado por plan.

Puede realizarse una estrategia de entrega incremental, donde se entrega el software a los clientes y se obtiene una
rápida retroalimentación de ellos, Si es así, considere el uso de los métodos ágiles.

● ¿Qué tan grande es el sistema que se está desarrollando?

Los métodos ágiles son más eficaces cuando el sistema se puede desarrollar con un equipo pequeño que pueda
comunicarse de manera informal. Esto puede no ser posible para los grandes sistemas que requieren equipos de
desarrollo grandes y distribuidos.

● ¿Qué tipo de sistema se está desarrollando?

Los enfoques del plan guiado pueden ser necesarios para los sistemas que requieren una gran cantidad de análisis
antes de la aplicación (por ejemplo, sistema en tiempo real con el complejo Requisitos de temporización).

● ¿Cuál es la expectativa de vida del sistema?

Los sistemas de larga vida tal vez requieran más documentación de diseño para comunicar las intenciones originales
de los desarrolladores del sistema al equipo de soporte.

● ¿Qué tecnologías están disponibles para apoyar el desarrollo del sistema?

Los métodos ágiles se basan en buenas herramientas para realizar un seguimiento de la evolución de un diseño

10
 ● ¿Cómo se organiza el equipo de desarrollo?

Si el equipo de desarrollo se distribuye o si parte del desarrollo se subcontrata, entonces puede que tenga que
desarrollar los documentos de diseño para comunicarse a través de los equipos de desarrollo.

● ¿Hay cuestiones culturales o de organización que puedan afectar al desarrollo del sistema?

Las organizaciones tradicionales de ingeniería tienen una cultura basada en el plan de desarrollo, ya que esta es la
norma en la ingeniería.

● ¿Qué tan buenos son los diseñadores y programadores del equipo de desarrollo?

A veces se argumenta que los métodos ágiles requieren niveles más altos de capacitación que los enfoques basados
en planes, en el que los programadores simplemente traducen un diseño detallado en código.

● ¿El sistema está sujeto a regulación externa?

Si un sistema tiene que ser aprobado por un regulador externo (por ejemplo, que el FAA aprueba el software, es
crítico para el funcionamiento de una aeronave) entonces usted probablemente tendrá que producir detallada
documentación como parte de la justificación de la seguridad del sistema.

Programación extrema

● Tal vez el más conocido y más utilizado método ágil.

● Extreme Programming (XP) toma un ‘extremo’ enfoque para el desarrollo iterativo.
● Las nuevas versiones se pueden construir varias veces al día;
● Los incrementos se entregan a los clientes cada 2 semanas;
● Todas las pruebas se deben ejecutar para cada construcción y la acumulación es sólo aceptada si las pruebas
resultan satisfactorias.

XP y principios ágiles

● Participación del cliente: un compromiso a tiempo completo del cliente con el equipo
● Entrega incremental: el desarrollo incremental es apoyado a través de pequeños sistemas de comunicación
frecuentes.
● Personas no procesos: a través de la programación en pares y propiedad colectiva.
● Adoptar el cambio: Cambios soportados a través sistemas regulares de comunicación. Se toma el cambio en el
próximo incremento
● Mantener la simplicidad: refactorización constante de código.

El ciclo de liberación de la programación extrema

11
Prácticas de Extreme programming

Escenarios de los requerimientos

● En XP, el cliente o el usuario es parte del equipo de XP y es responsable de tomar decisiones sobre los requisitos
● Las solicitudes de los usuarios se expresan como escenarios o historias del usuario.
● Estas se han escrito en los historiales y el equipo de desarrollo las plasma en tareas de ejecución. Estas tareas son
la base del calendario y los costos estimados.
● El cliente elige las historias para su inclusión en el próximo lanzamiento en base a sus prioridades y
● calendario de estimaciones.

XP y el cambio

● La sabiduría convencional en la ingeniería de software es diseñar para el cambio. Vale la pena el gasto de tiempo y
esfuerzo anticipando los cambios ya que esto reduce costos más tarde.
● XP sostiene que no vale la pena anticipar los cambios ya que cambios no se pueden prever de forma fiable
● Propone la mejora constante de código (refactorización) para poder realizar cambios más fácilmente.
12
Refactorización

Aprovechar oportunidades de mejora donde sean posibles.

● El equipo de programación busca posibles mejoras de código y realiza las mejoras aunque no sean de inmediata
necesidad.
● Esto mejora la comprensibilidad del software y reduce la necesidad de documentación.
● Los cambios son más fáciles de hacer ya que el código es bien estructurado y claro.
● Sin embargo, algunos cambios requieren reconstrucción de la arquitectura y esto es mucho más caro

Ejemplos: jerarquía de clases, renombramiento de atributos y métodos, comentarios, biblioteca de programas.

Pruebas en XP

Las pruebas son fundamentales para XP y XP ha desarrollado un enfoque en el que el programa se comprueba después de
que cada cambio se ha realizado.

Funciones de prueba de XP

● Desarrollo de las pruebas en primer lugar

● Desarrollo de pruebas incrementales de escenarios.
● Participación de los usuarios en el desarrollo de la prueba y validación.
● Juego de pruebas automatizadas que se utilizan para ejecutar todas las pruebas de componentes cada vez que una
nueva versión está construida.

Las pruebas de desarrollo son pruebas de defecto, se busca el error.

En XP se trabaja por incrementos, por lo que existe la posibilidad de que lo nuevo rompa lo que ya estaba andando, se
necesitan pruebas de regresión para probar que lo de antes siga funcionando.

Desarrollo de las pruebas primero

● Escribir pruebas antes del código aclara los requisitos para ser implementados.
● Las pruebas se escriben como programas en lugar de datos de manera que se pueden ejecutar de forma
automática. La prueba incluye una comprobación de que se ha ejecutado correctamente. Por lo general, se basa
en un marco de pruebas tales como Junit.
● Todas las pruebas anteriores y las nuevas se ejecutan automáticamente cuando se añade una nueva funcionalidad,
comprobando así que la nueva funcionalidad no ha introducido errores.

XP realiza el desarrollo de pruebas antes del código.

Participación de los clientes

● El papel del cliente en el proceso de pruebas es ayudar a desarrollar pruebas de aceptación de las historias que han
de ser implementadas en la próxima versión del sistema.
● El cliente que es parte del equipo de pruebas, escribe pruebas simultáneamente al desarrollo. Por consiguiente,
todo nuevo código es validado para asegurarse de que es lo que necesita el cliente.
● Problemas: las personas que adoptan el papel de clientes disponen de tiempo limitado. Ellos pueden sentir que la
presentación de los requisitos era suficiente contribución y por tanto pueden ser reacios a involucrarse en el
proceso de prueba.

13
La automatización de pruebas

La automatización de pruebas significa que las pruebas se escriben como componentes ejecutables antes de que la tarea
se implemente. Estos componentes de prueba deben ser independientes, deberían simular la presentación de la entrada
para ser probado y debe comprobar que el resultado cumple con las especificaciones de salida. Un marco de prueba
automatizada (por ejemplo Junit) es un sistema que hace que sea fácil de escribir pruebas ejecutables y presentar un
conjunto de pruebas para su ejecución.

Cuando se automatizan las pruebas, siempre hay un conjunto de pruebas que puede ser rápida y fácilmente ejecutado.
Siempre que se agrega alguna funcionalidad al sistema, las pruebas se pueden corren y los problemas que ha introducido
el nuevo código puede ser atrapadas inmediatamente

Dificultades en pruebas XP

● Los programadores prefieren programación a las pruebas y a veces se toman atajos al escribir pruebas. Por ejemplo,
pueden escribir ensayos incompletos que no comprueben todas las posibles excepciones que puedan ocurrir.
● Algunas pruebas pueden ser muy difíciles de escribir de forma incremental. Por ejemplo, en una interfaz de usuario
compleja, es a menudo difícil de escribir pruebas unitarias para el código que implementa la “lógica de
visualización” y flujo de trabajo entre las pantallas.
● Es difícil juzgar la integridad de un conjunto de pruebas. Aunque se tengan muchas pruebas del sistema, la prueba
de conjunto puede no proporcionar una cobertura completa.

Programación en pares

● En XP, los programadores trabajan en parejas, sentados juntos a desarrollar código.

● Esto ayuda a desarrollar la propiedad común de código y difunde el conocimiento a través del equipo.
● Sirve como un proceso de revisión informal, ya que cada línea de código es vista por más de 1 persona.
● Alienta a la refactorización.
● Las mediciones muestran que la productividad de desarrollo con la programación par es similar a la de dos personas
trabajando de forma independiente
● En la programación en pares, los programadores se sientan juntos en la misma estación de trabajo para desarrollar
el software.
● Las parejas se crean dinámicamente para que todos los miembros del equipo trabajen unos con otros durante el
proceso de desarrollo.
● El intercambio de conocimientos que sucede entre la pareja durante la programación es muy importante, ya que
reduce en general riesgos para un proyecto cuando los miembros del equipo se van.
● La programación en parejas no es necesariamente ineficiente y no evidencia que trabajar juntos es más eficiente
que 2 programadores de trabajo por separado

Ventajas de la programación en parejas

● Apoya la idea de la propiedad colectiva y responsabilidad para el sistema.

● Los individuos no son responsables de los problemas con el código. En su lugar, el equipo tiene la responsabilidad
colectiva para resolver estos problemas
● Actúa como un proceso de revisión informal, ya que cada línea de código se mira por al menos dos personas.
● Ayuda apoyando a la refactorización, que es un proceso de mejora de software.
● Cuando se utiliza la programación en pares y la propiedad colectiva, otros se benefician inmediatamente de la
refactorización de modo que es probable que apoyen el proceso.
14
Gestión de proyectos ágil

● La principal responsabilidad de los directores de proyectos de software es la gestión del proyecto para que el
software se entregue a tiempo y dentro del presupuesto previsto para el proyecto
● El enfoque estándar para la gestión de proyectos es el plan direccionado. Gerentes elaboran un plan para el
proyecto mostrando qué debería ser entregado, cuándo debería ser entregado y quién trabajará en el desarrollo
del proyecto
● La gestión de proyectos ágil requiere un enfoque diferente, que está adaptado para desarrollo incremental y las
fortalezas particulares de los métodos ágiles.

Scrum

El enfoque de Scrum es un método ágil general, pero su atención se centra en la gestión del desarrollo iterativo en lugar
de prácticas ágiles específicas. Tiene 3 FASES

● La fase inicial es una fase en fase de anteproyecto, donde se establecen los objetivos generales del proyecto y se
diseña la arquitectura de software.
● Esto es seguido por una serie de ciclos, donde cada ciclo desarrolla un incremento del sistema.
● La fase de cierre del proyecto concluye el proyecto, completa documentación requerida, tales como marcos de
ayuda del sistema y manuales de usuario y evalúa las lecciones aprendidas del proyecto.

El scrum master aísla al cliente de quienes desarrollan y transmite sus devoluciones a los desarrolladores.

El ciclo de Sprint

● Una vez que éstos están de acuerdo, el equipo se organizan para desarrollar el software. Durante esta etapa, el
equipo está aislado del cliente y la organización, con toda comunicaciones canalizadas a través del denominado
'Scrum Master‘.
● El papel del Scrum Master es proteger el equipo de desarrollo de las distracciones externas.
● Al final del sprint, el trabajo realizado es revisado y se presenta a las partes interesadas. El siguiente ciclo de sprint
comienza entonces.

Trabajo en equipo en Scrum

El 'Scrum Master' es un facilitador que organiza reuniones diarias, rastrea la acumulación de trabajo por hacer, registra las
decisiones, mide el progreso y se comunica con los clientes y la gestión fuera del equipo.

Todo el equipo asiste a las reuniones diarias cortas donde todos los miembros del equipo comparten información, describen
su progreso desde la última reunión, los problemas que han surgido y que se ha previsto para el día siguiente.

Esto significa que todos en el equipo saben lo que está pasando y, si surgen problemas, puede volver a planear el trabajo a
corto plazo para hacer frente a ellos.
15
Beneficios de Scrum

● El producto se divide en un conjunto de fragmentos manejables y comprensibles.

● Requisitos inestables no sostienen el progreso.
● Todo el equipo tiene visibilidad de todo y por lo tanto se mejora la comunicación del equipo.
● Los clientes ven la entrega a tiempo y se obtiene retroalimentación sobre cómo funciona el producto.
● Se genera confianza entre los clientes y los desarrolladores. Se crea una cultura positiva en la que todos esperan
que el proyecto tenga éxito.

Escala Métodos Ágiles

● Los métodos ágiles han demostrado ser un éxito para los proyectos pequeños y medianos que pueden ser
desarrolladas por un equipo pequeño co-ubicado.
● A veces se argumenta que el éxito de estos métodos viene a causa de la mejora de las comunicaciones, que es
posible cuando todos trabajan juntos.
● La ampliación de los métodos ágiles implica el cambio de éstos para hacer frente a grandes proyectos, más largos
en los que hay varios equipos de desarrollo, tal vez trabajar en diferentes lugares.

Desarrollo de sistemas de grandes

● Los grandes sistemas suelen ser colecciones de sistemas de independientes en los que equipos separados
desarrollan cada sistema. Con frecuencia, estos equipos están trabajando en diferentes lugares, a veces en
diferentes zonas horarias.
● Los sistemas grandes son "sistemas abandonados”, que interactúan con una serie de sistemas existentes. Muchos
de los requisitos del sistema tienen que ver con esta interacción por lo que no se prestan realmente a la flexibilidad
y el desarrollo incremental.
● Si varios sistemas se integran para crear un sistema, una parte importante del desarrollo tiene que ver con la
configuración del sistema en lugar de desarrollo de código inicial.
● Grandes sistemas y sus procesos de desarrollo están a menudo limitados por las reglas y regulaciones externas que
limitan la forma en que se pueden desarrollar.
● Los sistemas grandes tienen un tiempo de desarrollo largo. Es difícil mantener equipos coherentes que conocen el
sistema a lo largo de ese período ya que, inevitablemente, la gente se mueve a otros trabajos y proyectos.
● Los sistemas grandes suelen tener un conjunto diverso de partes interesadas. Es prácticamente imposible incluir
todas estas diferentes partes interesadas en el proceso de desarrollo.

El escalado horizontal y la ampliación

La "expansión" tiene que ver con el uso de los métodos ágiles de desarrollo de sistemas de software grandes que no pueden
ser desarrollados por un equipo pequeño.

La "ampliación” se refiere a cómo los métodos ágiles pueden introducirse a través de una gran organización con muchos
años de experiencia en desarrollo de software.

Al escalar los métodos ágiles es esencial para mantener los fundamentos ágiles. Planificación flexible, versiones frecuentes
del sistema, integración continua, desarrollo basado en pruebas y las buenas comunicaciones del equipo.

La expansión para los grandes sistemas

● Para el desarrollo de grandes sistemas, no es posible centrarse únicamente en el código del sistema. Se tiene que
hacer más por adelantado de diseño y documentación del sistema

16
● Los mecanismos de comunicación entre los equipos tienen que ser diseñados y utilizados. Este procedimiento incluirá
conferencias telefónicas y de vídeo regulares entre los miembros del equipo y las reuniones electrónicas cortas
frecuentes donde los equipos se actualizan entre sí sobre los progresos.
● La integración continua, donde se revisa cada vez cualquier desarrollador realiza un cambio es prácticamente
imposible.

La ampliación a grandes empresas

● Los administradores de proyectos que no cuentan con experiencia en métodos ágiles pueden ser reacios a aceptar el
riesgo de un nuevo enfoque.
● Las grandes organizaciones suelen tener procedimientos y normas de calidad que se espera que todos los proyectos
sigan y, por su carácter burocrático, éstos tienden a ser incompatibles con los métodos ágiles.
● Los métodos ágiles parecen funcionar mejor cuando los miembros del equipo tienen un nivel relativamente alto de
habilidad. Sin embargo, dentro de las grandes organizaciones, lo más probable es que se tenga una amplia gama de
habilidades y capacidades.
● Existe resistencia cultural a los métodos ágiles, especialmente en aquellas organizaciones que tienen una larga historia
de uso de los procesos de ingeniería de sistemas convencionales.

INGENIERÍA DE REQUERIMIENTOS

El proceso de establecimiento de los servicios que el cliente necesita de un sistema y las limitaciones con las que opera y
desarrolla. Con requisitos que son las descripciones de los servicios del sistema y las limitaciones que se generan durante
el proceso de ingeniería de requerimientos.

Requerimiento: declaración abstracta de un servicio o de una restricción de un sistema a una especificación funcional
matemática detallada. Los requerimientos pueden ser ambiguos, por lo que: deben estar abiertos a la interpretación y
deben estar definidos con detalle

Tipos de requerimientos, depende de cuanto se lo analizo:

● Requerimiento del usuario: ser escritos en lenguaje natural, más los diagramas de los servicios que proporciona el
sistema y sus limitaciones operacionales. Es el que nos da el usuario, será ambiguo y que cuando se analice por el
ing de requerimientos se convertirá en requerimientos del sistema
● Requerimiento del sistema: Es un documento estructurado que establece las descripciones detalladas de las
funciones del sistema, servicios y limitaciones operativas. Deben estar completos, ser verificables, sin conflictos
entre ellos, son formados a partir de los del usuario, por el Ing. en requerimientos para transformarlos en uno de
sistema.

Imprecisión de requerimientos: Surgen problemas cuando los requerimientos no se expresan con precisión. Los requisitos
ambiguos se pueden interpretar de distintas maneras.

Los requisitos deben ser:

● Completos: incluir una descripción de todos los servicios requeridos

● Coherentes: sin conflictos o contradicciones en las descripciones de los servicios del sistema

Requerimientos funcionales

● Describe una funcionalidad que el cliente requiere del producto del software que estamos desarrollando, puede
ser de usuario o de sistema.
● Depende del tipo de software, los usuarios esperados y el tipo de sistema en el que se utiliza el software.
● Cómo debería actuar en cada situación particular.

17
Requerimiento no funcional

● Las propiedades y limitaciones que va a tener el producto de software durante su operación, son transversales a
los del sistema. Ej-> necesidad de tiempo de respuesta, cantidad de usuarios que van acceder.
● Pueden especificar un mandato a un IDE en particular, lenguaje de programación o método de desarrollo
● Pueden afectar a una arquitectura general de un sistema en lugar de los componentes individuales
● Puede generar una serie de requerimientos funcionales relacionados que definen los servicios de sistema que se
requieren, o generar requerimientos que restrinjan a otros existentes.

Son propiedades transversales, y son más críticos que los funcionales, características que debe cumplir el producto de
acuerdo al producto que es, por ejemplo, si es una página como mercado libre, deberá poder soportar cierta cantidad de
usuarios.

Tipos:

● Requerimiento del producto: especificación de que el producto entregado debe comportarse de una manera
particular, ejemplo velocidad de ejecución.
● Requerimientos organizacionales: consecuencia de las políticas y procedimientos de la organización.
● Requerimientos externos: surgen de factores externos al sistema, ejemplo: legislativos

Objetivos: es una declaración general de lo que el cliente quiere, son útiles para los desarrolladores ya que transmiten las
intenciones del usuario con el sistema

Requerimiento no funcional verificable: declaración mediante una cierta medida que se puede probar de forma objetiva.

Requerimiento de usabilidad: el sistema debe ser fácil de usar por el usuario luego de entrenamiento y organizado para
que los errores de usuario se reduzcan al mínimo.

Métrica para la especificación de requisitos no funcionales

18
Requerimientos de dominio:

● Restricciones en el sistema según el dominio de operación

● Generan nuevos requisitos funcionales, limitaciones sobre los requisitos existentes o definir cálculos específicos.
● Si estos no están satisfechos el sistema puede ser inutilizable.

Problemas de requerimientos de dominio:

● Compresibilidad: si se expresan en lenguaje del dominio de la aplicación, a veces los ingenieros no lo entienden.
● Implícito: los especialistas del dominio entienden tan bien el problema que no explican las especificaciones.

Documento de requerimientos

Declaración oficial de lo que se requiere de los desarrolladores del sistema. Debe incluir tanto una definición de los
requisitos del usuario y una especificación de los requisitos del sistema. No es un documento de diseño, establece lo que
el sistema debe hacer y no cómo hacerlo. Siempre tiene que estar actualizado.

La información del documento depende del tipo de sistema y el enfoque de desarrollo utilizado. Los sistemas desarrollados
por incrementos, suelen tener menos detalle en el documento.

Las normas para documentos son diseñadas por estándar IEEE. Aplicables a los registros para los grandes proyectos de Ing
de sistemas.

Métodos ágiles y requerimientos

- Algunos métodos ágiles dicen que no sirve por que los requerimientos cambian mucho
- Métodos como XP, usan historias de usuario. Practico para los sistemas de negocios, pero problemático para los
que requieren de mucho analisis antes de la entrega o sistemas desarrollados por varios equipos.

Los usuarios de un documento de requerimientos

19
La estructura de un documento de requerimientos

La estructura de un documento de requerimientos

Especificación de requerimientos: proceso de escribir los requerimientos del sistema del usuario y en un documento de
requisitos.

- Los requerimientos de usuario tienen que ser comprensibles por los usuarios finales y los clientes quienes no tienen
una formación técnica.
- Los requerimientos del sistema son requerimientos más detallados y pueden incluir más información técnica.
- Los requerimientos pueden ser parte de un contrato para el desarrollo del sistema, deben ser lo más completo
posible.

20
Maneras de escribir una especificación de requerimientos del sistema

Diseño y requerimientos

- En principio, los requerimientos deberán establecer lo que el sistema debe hacer y el diseño debe describir cómo
se hace esto.

En práctica, los requerimientos y el diseño están unidos:

- Una arquitectura de sistema puede ser diseñada para estructurar los requisitos.
- El sistema puede interoperar con otros sistemas que generan requisitos de diseño;
- El uso de una arquitectura específica para satisfacer los requisitos no funcionales puede ser un requisito de
dominio.
- Esta puede ser la consecuencia de un requisito reglamentario.

Especificación en lenguaje natural

- Los requerimientos se escriben como sentencias en lenguaje natural complementados con diagramas y tablas.
- Se utiliza para la escritura de los requisitos, ya que es expresiva, intuitiva y universal. Esto significa que los requisitos
pueden ser entendidos por los usuarios y clientes.

Guías para la redacción de los requerimientos

- Generar un formato estándar y utilizarlo para todas las necesidades.

- Utilizar el lenguaje de manera clara para distinguir entre requerimientos obligatorios y deseables.
- Usar texto resaltado (negrilla, cursiva o color) para seleccionar partes clave del requerimiento.
- Evitar el uso de lenguaje informático.
- Incluir una explicación (lógica) de por qué un requisito es necesario.

Problemas con el lenguaje natural

- Falta de claridad, la precisión es difícil sin hacer que el documento sea difícil de leer.
- Confusión de requerimientos, requisitos funcionales y no funcionales tienden a ser confusos.
- Fusión de requerimientos, Varios requerimientos diferentes pueden expresarse juntos
21
Especificación estructurada

- La libertad del escritor de los requerimientos es limitada y los requerimientos están escritos de una manera
estándar.
- Esto funciona bien para algunos tipos de requerimientos, por ejemplo, requerimientos para el sistema de control
embebido, pero a veces es demasiado rígido para la escritura de requerimientos del sistema de negocios.

Especificación estructurada:

- Definición de la función o entidad.

- Descripción de las entradas y de dónde vienen.
- Descripción de las salidas y donde van.
- Información acerca de la información necesaria para el cálculo y otras entidades usadas.
- Descripción de la acción a tomar.
- Pre y post condiciones (si son apropiadas).
- Los efectos secundarios (si existen) de la función.

Ejemplo: Bomba de insulina

● Acción no se puede explicar en lenguaje natural porque pueden implementarse cosas erróneas y es peligroso,
entonces uso la especificación tabular (abajo)
● Todo requerimiento deberá tener su porqué!!!! Es importante para el que haga la implementación

Especificación tabular

Se utiliza para complementar el lenguaje natural.

Es particularmente útil cuando se tiene que definir una serie de posibles cursos de acción alternativos.
Por ejemplo, el sistema de la bomba de insulina basa sus cálculos de la tasa de cambio del nivel de azúcar en la sangre y la
especificación tabular explica cómo realizar el cálculo para los diferentes escenarios.

22
Procesos de ingeniería de requerimientos

Los procesos utilizados para IR varían ampliamente dependiendo del dominio de la aplicación, las personas involucradas y
la organización el desarrollo de los requisitos.
Sin embargo, hay una serie de actividades genéricas comunes a todos los procesos:
- Obtención de requerimientos;
- El análisis de requerimientos;
- La validación de requerimientos ;
- La gestión de requerimientos. involucra poder observar el cambio de los requerimientos(modificaciones), también
las relaciones entre sí (uno puede generar otro requerimiento), tambien pueden contraponerse requerimientos
distintos
En la práctica, IR es una actividad iterativa en el que se intercalan estos procesos.

Proceso de obtencion y analisis de requerimientos

Entrevistas

Las entrevistas formales o informales con las partes interesadas son parte de la mayoría de los procesos de la IR.

Tipos de entrevistas

• Entrevistas cerradas a base de pre-determinada lista de preguntas

• Entrevistas abiertas donde varios temas se exploran con las partes interesadas.

Entrevistas efectivas

• Tener la mente abierta, evitar las ideas preconcebidas acerca de los requerimientos y están dispuestos a escuchar a las
partes interesadas.
• Preguntar al entrevistado y obtener discusiones usando una pregunta clave, una propuesta de requerimientos, o si
trabajan juntos en un sistema prototipo.

Entrevistas en la práctica

Normalmente, una mezcla de la entrevista cerrada y abierta.

• Las entrevistas son buenas para conseguir una comprensión global de lo que los actores hacen y cómo podrían
interactuar con el sistema.
• Las entrevistas no son buenas para la comprensión de los requerimientos de dominio
23
• Los técnicos pueden no entender la terminología de dominio específico;
• Algunos dominios del conocimiento pueden ser tan familiares que la gente encuentra difícil dar detalles o piensan que
no es necesario hacerlo.

Escenarios (es una especie de relato). Los escenarios son ejemplos reales de cómo se puede utilizar un sistema.

Estos deberían incluir

● Una descripción de la situación de partida;
● Una descripción del flujo normal de los acontecimientos;
● Una descripción de lo que puede salir mal;
● Información sobre otras actividades concurrentes;
● Una descripción de la situación cuando el escenario termina
Ejemplo:

Casos de uso
Es una funcionalidad provista por un sistema.

Un diagrama de casos de uso es (lo de abajo) y me permite relacionar los roles con las funcionalidades, me permite ver que
tiene que hacer cada uno y que permisos tienen.
24
Personitas = actores ->Definen perfiles o roles

Etnografía

La etnografía es una técnica de observación que se usa para entender los procesos operacionales y ayudar a derivar
requerimientos de apoyo para dichos procesos.

• Es necesario observar y analizar cómo las personas trabajan realmente.

• Pueden ser observados los factores sociales y organizacionales de importancia.
• Los estudios etnográficos han demostrado que el trabajo suele ser más rico y complejo de lo que sugieren los
modelos de sistemas simples.

Ámbito de aplicación de la etnografía

• Los requerimientos que se derivan de la forma en que las personas trabajan realmente en vez de la forma en la cual las
definiciones del proceso indican que debería trabajar.
• Los requerimientos que se derivan de la cooperación y el conocimiento de las actividades de otras personas.
• Los estudios etnográficos pueden revelar detalles críticos de procesos, que con frecuencia se pierden con otras técnicas
de adquisición de requerimientos.

Validación de requerimientos

Proceso de verificar que los requerimientos definen realmente el sistema que quiere el cliente.
Falta de validación de requerimientos implica costos altos:

• La solución de un error de los requerimientos después de entrega puede llegar a costar hasta 100 veces el costo de
arreglar un error de ejecución.
• Que no sea útil
• Que no sea lo que el cliente necesite
¡Ya no sirve si es a nivel de un producto funcional, si o si hacerlo a nivel de requerimientos!

25
Comprobación

Validez. ¿El sistema provee las funciones que mejor ayudan a las necesidades del cliente?
Consistencia. ¿Existen conflictos de los requerimientos?
Integridad. ¿Están todas las funciones requeridas por el cliente incluidas? Tiene que estar todo
Realismo. ¿Pueden implementarse los requerimientos dado el presupuesto y la tecnología disponible? Tiene que ser
factible de implementar
La verificabilidad. ¿Se pueden comprobar los requisitos? Ningún requerimiento tiene sentido si no puede ser verificado

Técnicas de validación

• Críticas de requerimientos: Análisis manual sistemático de los requerimientos.

• Prototipado -> (nunca tienen en cuenta los requerimientos no funcionales). Son sumamente útiles para interfaces de
usuario, le dan una idea al usuario de cómo va a funcionar su sistema. Utilizando un modelo ejecutable del sistema
para comprobar requerimientos. (Mockup)
• Generación de test: El desarrollo de las pruebas de requerimientos para comprobar la capacidad de prueba.

Críticas de requerimientos

• Las revisiones periódicas deben ser sostenidas mientras la definición de requerimientos se formula.
• Tanto el cliente como el personal del proyecto deben participar en las revisiones.
• Las revisiones pueden ser formales (con documentos completos) o informales. Buenas comunicaciones entre los
desarrolladores, clientes y usuarios pueden resolver problemas en una etapa temprana

Requerimientos

La verificabilidad: Los requerimientos son verificables

Comprensibilidad: Los requerimientos fueron entendidos correctamente
Trazabilidad: El origen de la obligación se declaró con claridad
Adaptabilidad: El requerimiento puede cambiar sin un gran impacto en otros requerimientos

Gestión de requerimientos

La gestión de requerimientos es el proceso de gestión de requerimientos cambiantes durante el proceso de ingeniería de

requerimientos y desarrollo del sistema.

● Nuevos requerimientos surgen como un sistema y están siendo desarrollados después de que haya entrado en uso.

Es necesario hacer un seguimiento de las necesidades individuales y mantener vínculos entre necesidades dependientes
para que pueda evaluar el impacto de los cambios de requisitos. Es necesario establecer un proceso formal para hacer
propuestas de cambio y que los vinculen con los requisitos del sistema.

Cambio en los requerimientos

El entorno empresarial técnico del sistema siempre cambia después de la instalación.

El nuevo hardware se puede introducir, puede ser necesario para interconectar el sistema con otros sistemas, las
prioridades de negocio pueden cambiar (con los consiguientes cambios en el apoyo al sistema es necesario), y la nueva
legislación y los reglamentos se pueden introducir tal que el sistema debe cumplirlos necesariamente.

Las personas que pagan por un sistema y los usuarios de dicho sistema rara vez son las mismas personas. Los clientes del
sistema imponen requerimientos debido a las limitaciones organizativas y presupuestarias. Estos pueden estar en conflicto
con los requisitos de los usuarios finales y, después de la entrega, las nuevas características pueden tener que ser añadidas
para el soporte al usuario si el sistema quiere cumplir sus objetivos.

26
 USABILIDAD

Facilidad con que las personas pueden utilizar una herramienta particular u otro objeto fabricado por humanos con el fin
de alcanzar un objetivo concreto

La usabilidad es la cualidad que tiene un sistema por la cual permite a sus usuarios alcanzar objetivos específicos con:
efectividad, eficiencia y satisfacción. El concepto en torno al cual gravita la usabilidad es la calidad de uso. La usabilidad se
considera como un requerimiento

El grado de usabilidad de un sistema es una medida empírica y relativa de su usabilidad. Se mide a partir de pruebas
empíricas y relativas:

Empírica: porque no se basa en opiniones o sensaciones, sino en pruebas de usabilidad realizadas en laboratorio u
observadas mediante trabajo de campo.

Relativa: porque el resultado no es ni bueno ni malo, sino que depende de las metas planteadas

Principios

Facilidad de aprendizaje

Facilidad con la que nuevos usuarios desarrollan una interacción efectiva con el sistema o producto Está relacionada con:

● La predicibilidad
● La sintetización
● La familiaridad
● La generalización de los conocimientos previos
● La consistencia (organización)

Facilidad de uso

Facilidad con la que el usuario hace uso de la herramienta, con menos pasos o más naturales a su formación específica.
Está relacionada con:

● La eficacia

● La eficiencia

Flexibilidad

Relativa a la variedad de posibilidades con las que el usuario y el sistema pueden intercambiar información. Abarca la
posibilidad de diálogo, la multiplicidad de vías para realizar la tarea, similitud con tareas anteriores y la optimización entre
el usuario y el sistema.

Robustez

Es el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos. Está relacionado con la capacidad de
observación del usuario, de recuperación de información y de ajuste de la tarea al usuario.

27
La usabilidad

Es un atributo de calidad que, dependiendo de los usuarios, las tareas y el contexto, mide:

● la facilidad de aprendizaje
● La eficiencia motriz y cognitiva
● La capacidad de recordar lo aprendido
● El manejo de errores
● La satisfacción subjetiva

DCU - Diseño Centrado en el Usuario

28
DCU - Objetivos
● Satisfacer las necesidades de todos sus usuarios potenciales
● Adaptar la tecnología utilizada a las expectativas de los usuarios
● Crear interfaces que faciliten la consecución de los objetivos de los usuarios
DCU - FASES
● Entender y especificar el contexto de uso: identificar a las personas a las que se dirige el producto, para qué lo
usarán y en qué condiciones.
● Especificar requisitos: identificar los objetivos del usuario y del proveedor del producto a satisfacer.
● Producir soluciones de diseño: esta fase se puede subdividir en diferentes etapas secuenciales, desde las primeras
soluciones conceptuales hasta la solución final de diseño; generalmente utilizando técnicas de prototipado.
● Evaluar: es la fase más importante del proceso, en la que se validan las soluciones de diseño (el sistema satisface
los requisitos), o por el contrario se detectan problemas de usabilidad, normalmente a través de pruebas con
usuarios.

DCU - BENEFICIOS

● Aumento de la productividad: un sistema diseñado siguiendo los principios de usabilidad, y adaptado de manera de
trabajar del usuario, permitirá más efectividad en lugar de perder el tiempo luchando con un complejo conjunto de
funciones. Un sistema usable permitirá al usuario concentrarse en la tarea en lugar de la herramienta.
● Reducción de errores: una significativa proporción de error humano a menudo se le puede atribuir a una interfaz de
usuario mal diseñada. Evitar incoherencias, ambigüedades u otras faltas del diseño de la interfaz generan menor
cantidad de errores del usuario.
● Menor capacitación y entrenamiento: un sistema bien diseñado y usable puede reforzar el aprendizaje, reduciendo
así el tiempo de formación y la necesidad de apoyo humano.
● Aceptación: mejorar la aceptación del usuario es a menudo una medida de resultado indirecta del diseño de un sistema
utilizable. La mayoría de los usuarios prefieren utilizar, un sistema bien diseñado que proporcione información que
pueda ser fácilmente accedida y que se presenta en un formato que sea fácil de asimilar y utilizar.

29
DCU - PRINCIPIOS BÁSICOS

● Participación activa de los usuarios: entendimiento de estos y de las tareas que requieren. Al incorporar a los usuarios
finales al proceso desde el inicio, me mejora además la aceptación y el compromiso con el sistema, al sentir que ha
sido diseñado teniendo en cuenta sus necesidades y no ha sido impuesto.
● Iteración en el diseño: esto implica recibir realimentación por parte de los usuarios finales después de su uso en varias
etapas, las cuales pueden ir desde simples maquetas con papel hasta prototipos de software con mayor grado de
fidelidad. La respuesta de cada ciclo de iteración se utiliza para desarrollar el siguiente diseño. Se intenta además lograr
las condiciones más similares al mundo real en el cual se desenvolverán los usuarios con el sistema.
● Utilizar un equipo multidisciplinario: el DCU es un proceso de colaboración que se beneficia de la participación activa
de diversas partes cada una de las cuales tiene conocimiento y experiencia específicos para compartir con el resto. El
equipo podría incluir gerentes, especialistas en usabilidad, usuarios finales, ingenieros de software, diseñadores
gráficos, diseñadores de interacción y personal de capacitación y apoyo.

Metodologías y técnicas del DCU

Identificación de los usuarios

● Usuarios primarios: las personas que usarán el producto

● Final para realizar una tarea.
● Usuarios secundarios: los que ocasionalmente pueden usar el producto, o aquellos que lo consumen a través de
un intermediario.
● Usuarios terciarios: los que se verán afectados por el uso del producto, o pueden tomar decisiones sobre el mismo

Para que el diseño de un producto sea exitoso se deben tener en cuenta los tres niveles de usuarios

Prototipado

Una vez que las partes interesadas han sido identificadas y se ha hecho una investigación completa de sus necesidades, los
diseñadores pueden desarrollar soluciones con diseños alternativos, los cuales pueden ser evaluados por los usuarios.
Estas alternativas pueden ser simples dibujos en lápiz y papel en la fase inicial del proceso.
También es posible escuchar a los usuarios discutir sobre los diseños alternativos presentados, lo cual posibilita amplificar
la comprensión de los diseñadores y pueden proporcionar información que no se obtuvo en las entrevistas iniciales, en
otras palabras las observaciones y el análisis de necesidades ya realizado.

Proceso de evaluación

A medida que avanza el ciclo del diseño, los prototipos (versiones iniciales y limitadas del producto) pueden ser producidos
y luego probados por los usuarios.

Las evaluaciones ayudarán a identificar criterios medibles de usabilidad:

● Eficacia: ¿Cuántas veces los usuarios logran terminar las tareas? ¿Lograron terminar las tareas sin dificultad?
● Facilidad de Aprendizaje (Learnability):¿Cuán fácil resulta para los usuarios llevar a cabo tareas básicas la primera vez
que se enfrentan al diseño?

30
● Eficiencia: Una vez que los usuarios han aprendido el funcionamiento básico del diseño, ¿cuánto tardan en la
realización de tareas?
● Cualidad de ser recordado (Memorability): Cuando los usuarios vuelven a usar el diseño después de un periodo sin
hacerlo, ¿cuánto tardan en volver a adquirir el conocimiento necesario para usarlo eficientemente?
● Tasa de errores de usuario: Durante la realización de una tarea, ¿cuántos errores comete el usuario?, ¿Qué tan graves
son las consecuencias de esos errores?, ¿Qué tan rápido puede el usuario deshacer las consecuencias de sus propios
errores?
● Satisfacción subjetiva: ¿Cuán agradable y sencillo le ha parecido al usuario la realización de las tareas?

Las evaluaciones también revelarán la satisfacción de los usuarios con el producto. Esto se logra solamente a través de
comentarios recogidos en un procesointeractivo e iterativo con la participación de los usuarios
PRUEBAS DE USABILIDAD

● Se utilizan metodologías que requieren la participación de usuarios reales o de personas que concuerdan con el perfil
de los futuros usuarios.
● Valiosa la observación con un equipo multidisciplinario (más valiosa que encuestas con valoración)
● La Investigación Etnográfica: se observa a los usuarios en el lugar donde normalmente se utiliza el sistema (por
ejemplo, trabajo, hogar, etc.) para recopilar datos sobre quiénes son sus usuarios, cuáles son las tareas y metas que
se han relacionado con el sistema, y el contexto en el que trabajan para lograr sus objetivos. A partir de esta
investigación cualitativa, se puede desarrollar perfiles de usuario, personajes arquetípicos (los usuarios), los escenarios
y descripciones de tareas
● El Diseño Participativo: si bien no se considera una técnica en sí misma, es más bien una forma de realización del DCU,
el diseño participativo emplea a uno o más usuarios representativos durante todo el proceso de desarrollo. Este
enfoque posiciona al usuario final en el corazón del proceso de diseño, desde el inicio mismo del proyecto,
aprovechando el conocimiento del usuario, habilidades, e incluso las reacciones emocionales en el diseño.
● Los Grupos Focales (Focus Group): son utilizados en las primeras etapas de un proyecto para evaluar conceptos
preliminares con usuarios representativos. El objetivo es identificar si los conceptos principales, son satisfactorios o
no, y cómo podrían ser más aceptables y útiles Se explora sobre cómo los usuarios finales piensan y sienten. Un grupo
focal es bueno para la información general, cualitativa, pero no para aprender sobre los problemas de rendimiento y
los comportamientos reales del sistema. Las pruebas de usabilidad se consideran mejores para la observación de los
comportamientos y la medición de los problemas de rendimiento
● Las entrevistas: con usuarios son una poderosa herramienta cualitativa, pero no para evaluar la usabilidad de un
diseño, sino para descubrir deseos, motivaciones, valores y experiencias de nuestros usuarios. Durante estas
entrevistas, el entrevistador debe mostrarse neutral y no dirigir o condicionar las respuestas del entrevistado. Lo que
se pretende es descubrir información que oriente en el diseño, no confirmar creencias sobre cómo son los usuarios.
● Las encuestas: también son una herramienta útil y se pueden utilizar en cualquier momento del ciclo de vida, pero se
utiliza con mayor frecuencia en las primeras etapas para comprender mejor el potencial usuario. Son una herramienta
de investigación cuantitativa que complementan a las entrevistas, y permiten medir con validez estadística los
conceptos hallados con técnicas cualitativas
● Card sorting: consiste en solicitar a un grupo de participantes (los cuales deben tener un perfil acorde con la audiencia
a la que se dirige el producto) que agrupen los conceptos representados en tarjetas por su similitud semántica. Con el
objetivo de identificar qué conceptos, de los representados en cada tarjeta, tienen relación semántica entre sí, e
incluso cuál es el grado de esa relación.
El card sorting es una prueba destinada a comprender la forma en que los usuarios estructuran la información para
asegurar que será comprendida fácilmente, por tanto tiene lugar en etapas tempranas del proyecto

Usability Testing -> Emplea técnicas para recoger datos empíricos mediante la observación de usuarios finales que utilizan
el sistema para realizar tareas en tiempo real.

Las pruebas se dividen en dos enfoques principales

1. Pruebas formales realizadas como verdaderos experimentos, con el fin de confirmar o refutar hipótesis específicas.

31
2. Menos formal, pero riguroso, emplea a un ciclo repetitivo de pruebas destinadas a exponer las deficiencias de
usabilidad y moldear el producto

"think-aloud“ (pensamiento en voz alta), consiste en solicitar al participante que exprese verbalmente durante la prueba
qué está pensando, qué no entiende, por qué lleva a cabo una acción o duda.

Los Estudios de Seguimiento

Se realizan después de la liberación formal del sistema. La idea es recoger datos que se utilizarán para la próxima versión,
a través de encuestas, entrevistas y observaciones. Una vez estructurados, los estudios de seguimiento son,
probablemente, las apreciaciones más adecuadas y más precisas de la facilidad de uso de un sistema.

La Evaluación Heurística

Se realiza por inspección, varios expertos inspeccionan y analizan el diseño en busca de potenciales problemas de
usabilidad, comprobando para ello el cumplimiento de principios de diseño usable (principios heurísticos) previamente
establecidos

Las ocho reglas de oro de Shneiderman

1. Consistencia: Es importante el uso de iconos, colores, botones, etc. que sean familiares aprovechando el conocimiento
previo que tiene el usuario. Los usuarios usan algo nuevo. Esto ayuda a que los usuarios puedan realizar lo que desean
más rápidamente.
2. Permitir que los usuarios frecuentes usen atajos: Con el constante uso de un producto o servicio, se demandan formas
más rápidas para realizar las tareas. Como ejemplo, secuencias del teclado para copiar, pegar, etc. mientras el usuario
va adquiriendo experiencia, pueden navegar y utilizar el interfaz más rápido y sin esfuerzo.
3. Retroalimentación informativa: Los usuarios deben saber en dónde están y qué es lo que está pasando todo el tiempo.
Cada acción, debe tener una retroalimentación legible y razonable. Un mal ejemplo son los mensajes de alerta que
muestran códigos de error incomprensibles para el usuario.
4. Diseñar textos de diálogo para cerrar procesos: Los usuarios deben saber cuál ha sido el resultado de sus acciones o
actos. Por ejemplo, cuando se completa una transacción en línea es necesario que sea informado todo lo relativo a la
operación apenas concluida.
5. Manejo de errores: Ofrecer una forma sencilla de corregir errores. Los sistemas deben diseñarse para evitar que los
usuarios cometan errores, pero, cuando esto suceda, deben recibir una solución simple para resolverlo. Por ejemplo,
si hay campos obligatorios en un formulario, pueden resaltarse para mejorar la identificación.
6. Permitir deshacer operaciones: Se deben ofrecer formas obvias y sencillas de retroceder o revertir acciones. Esto debe
de permitirse en varios puntos, ya sea después de una acción, una captura de datos o una secuencia de acciones. “Esta
función libera ansiedad, como el usuario se da cuenta que el error puede corregirse, le da el valor para explorar
opciones, funciones o características desconocidas”
7. Fomentar la sensación de control: Permitir que el usuario sea el que inicia las cosas. Es importante que tenga la
sensación de que están en completo control de los eventos que ocurren en el espacio digital.
8. Reducir la carga de memoria a corto plazo: La atención humana es limitada. La interfaz debe ser lo más sencilla posible
y con una jerarquía de información evidente. Elegir reconocimiento en vez de recuerdo. Reconocer es más fácil que
recordar, el reconocimiento incluye claves que ayudan a recordar objetos almacenados en la memoria.

Los diez Principios Heurísticos de Nielsen

1. Visibilidad del estado del sistema: El sistema siempre debe mantener a los usuarios informados sobre lo que ocurre, a
través de una retroalimentación apropiada en un tiempo razonable.
2. Consistencia entre el sistema y el mundo real: El sistema debe hablar en el lenguaje del usuario, con palabras, frases y
conceptos familiares para él. Utilizar convenciones del mundo real, haciendo que la información aparezca en un orden
natural y lógico.
32
3. Control y libertad del usuario: es frecuente que los usuarios elijan funcionalidades por error y necesitan un modo fácil
para resolver la situación. Es importante ofrecer soporte para deshacer y rehacer acciones.

4. Consistencia y estándares: Los usuarios no deben tener que preguntarse si las diversas palabras, situaciones, o
acciones significan las misma cosa. Que se sigan las normas y convenciones de la plataforma sobre la que está
implementando el sistema.

33
5. Prevención de errores: Antes que diseñar buenos mensajes de error, es mejor evitar que el problema ocurra.
6. Reconocer es mejor que recordar: Minimizar la carga de memoria del usuario haciendo que los objetos, las acciones y
las opciones estén visibles. El usuario no debería tener que recordar la información de una parte del diálogo a otra.
7. Flexibilidad y eficiencia de uso: Los aceleradores, no vistos por el usuario principiante, mejoran la interacción para el
usuario experto de tal manera que el sistema puede servir para usuarios inexpertos y experimentados. Es importante
que el sistema permita personalizar acciones frecuentes.
8. Diseño estético y minimalista: Los diálogos no deberían contener información irrelevante. Cada unidad extra de
información en un diálogo compite con la información importante, disminuyendo su visibilidad relativa.
9. Ayudar a reconocer, diagnosticar y recuperarse de errores: Los mensajes de error deben estar expresados en lenguaje
simple (sin códigos), indicando con precisión el problema y sugiriendo una solución.
10. Ayuda y documentación: Aunque es mejor que se pueda usar el sistema sin documentación, es necesario proveer al
usuario de ayuda y documentación. Esta tiene que ser fácil de buscar y entender, centrada en la tareas del usuario,
con información de las etapas a realizar y no muy extensa.

Agregados por PIEROTTI

11. Habilidades: El sistema debe tener en cuenta, extender, suplementar e incentivar las habilidades del usuario, sus
conocimientos y su experiencia.
12. Interacción placentera respetuosa: Las interacciones de los usuarios con el sistema deben favorecer su calidad de vida,
presentando un diseño estético, en donde los valores artísticos se igualen a los funcionales.
13. Privacidad: El sistema debe ayudar al usuario a proteger la información personal o privada, tanto la del propio usuario
como la que pertenece a los clientes del usuario.

MODELADO DE SISTEMAS

La modelación de sistemas

La modelación de sistemas es el proceso de elaboración de modelos abstractos de un sistema, con cada modelo que
presenta una vista o perspectiva diferente de ese sistema. Se representa mediante algún tipo de notación gráfica, casi
siempre basada en anotaciones en el Lenguaje Unificado de Modelado (UML). Ayuda al analista a entender la funcionalidad
del sistema y se pueden utilizar modelos para comunicarse con los clientes.

Modelos de sistemas

Se utilizan durante la ingeniería de requisitos para ayudar a explicar los requisitos propuestos a otros actores del sistema.
Los ingenieros utilizan estos modelos para discutir las propuestas de diseño y documentar el sistema de aplicación.

En un proceso de ingeniería basado en modelos, es posible generar una implementación completa o parcial del sistema
desde el modelo del Sistema

Perspectivas del sistema

• Externa, donde se modela el contexto o el entorno del sistema.

• De interacción, donde se modelan las interacciones entre un sistema y su entorno, o entre los componentes de un
sistema.
• Estructural, donde se modela la organización de un sistema o de la estructura de los datos que son procesados por el
sistema.
• Conductual, en la que se modela el comportamiento dinámico del sistema y la forma en que responde a los eventos.

Tipos de diagramas UML

• Los diagramas de actividades, que muestran las actividades involucradas en un proceso o en el procesamiento de datos.
34
• Diagramas de casos de uso, los cuales muestran las interacciones entre un sistema y su entorno.
• Los diagramas de secuencia, que muestran las interacciones entre los actores y el sistema y entre los componentes del
sistema.
• Los diagramas de clases, que muestran las clases de objetos en el sistema y las asociaciones entre estas clases.
• Diagramas de estado, que muestran cómo el sistema reacciona a los acontecimientos internos y externos.

El uso de modelos gráficos

• Como una forma de facilitar el debate sobre un sistema

• Como una manera de documentar un modelo de sistema debe ser una representación exacta del sistema, pero no
tiene que ser completa.
• Como una descripción detallada del sistema en ese caso debe ser correcta y completa.

Los modelos de contexto

Se utilizan modelos de contexto para ilustrar el contexto operativo de un sistema, muestran lo que se encuentra fuera de
los límites del sistema. Las cuestiones organizacionales pueden influir en la decisión sobre dónde situar los límites del
sistema.

Los modelos de contexto muestran el sistema y su relación con otros sistemas.

Límites del sistema

Se establecen para definir lo que está dentro y lo que está fuera del sistema, muestran otros sistemas que se utilizan o
dependen del sistema que está siendo desarrollado. La posición de los límites del sistema tiene un efecto profundo en los
requisitos del sistema.

La definición del límite del sistema es fundamental Si los límites del sistema aumentan y / o disminuyen cambia la carga de
trabajo de las diferentes partes de una organización.

El contexto del MHC – PMS

Perspectiva del proceso

• Los modelos de contexto, simplemente muestran los otros sistemas en ambiente, no cómo se utiliza el sistema que
está siendo desarrollado en ese entorno.
• Los modelos de proceso revelan cómo se utiliza el sistema en desarrollo en los procesos de negocio
• Diagramas de actividades de UML se pueden utilizar para definir los modelos de procesos de negocio.

35
Modelos de interacción

• El modelado de la interacción de usuario es importante ya que ayuda a identificar las necesidades de los usuarios.
• El modelado de interacción de sistema a sistema resalta los problemas de comunicación que puedan surgir.
• El modelo de interacción de componentes ayuda a comprender si la estructura del sistema propuesto es adecuada para
ofrecer el rendimiento y la fiabilidad del sistema necesario.
• Los diagramas de casos y diagramas de secuencia se pueden utilizar para el modelado de la interacción.

Modelado de casos de uso

Los casos de uso se desarrollaron originalmente para apoyar la obtención de requisitos y están incorporadas en el UML.
Cada caso de uso representa una tarea discreta que implica la interacción externa con un sistema.

Los actores de un caso de uso pueden ser personas u otros sistemas.

• Representación esquemática para proporcionar una visión general de los casos de uso
• Representación textual para proporcionar una visión detallada

Los casos de uso en el MHC – PMS que implica el papel “Medico Recepcionista”

Los diagramas de secuencia

Los diagramas de secuencia son parte de UML y se utilizan para modelar las interacciones entre los actores y los objetos
dentro de un sistema.

Un diagrama de secuencia muestra la secuencia de interacciones que tienen lugar durante un caso de uso en particular.
Los objetos y los actores involucrados están listados en la parte superior del diagrama, con una línea de puntos trazada
verticalmente a partir de estos y las interacciones entre los objetos se indican mediante flechas anotadas.

Diagrama de secuencia para ver la información del paciente

36
Diagrama de secuencia para la transferencia de datos

Los modelos estructurales

Muestran la organización de un sistema en función de los componentes que conforman este sistema y sus relaciones. Son
modelos estáticos, que muestran la estructura del sistema.

Los diagramas de clases

Se utilizan en el desarrollo de un modelo de sistema orientado a objetos para mostrar las clases de un sistema y las
asociaciones entre estas clases.

• Una clase de objeto es una definición general de un tipo de objeto del sistema.
• Una asociación es una relación entre clases.
• Los objetos representan algo en el mundo real, tal como un paciente, una prescripción, médico, etc.

Clases UML y asociación

37
Clases y asociaciones en el MHC – PMS

La clase de consulta

Generalización

Es una técnica que utilizamos para gestionar la complejidad. En lugar de definir las características detalladas de cada
entidad, ponemos estas características en las clases mas generales (animales, coches, casas, etc.). Esto nos permite inferir
que los diferentes miembros de estas clases tienen algunas características comunes.

En los sistemas de modelado, a menudo es útil examinar las clases de un sistema para ver si hay posibilidades de
generalización. En lenguajes orientados a objetos, la generalización se realiza utilizando los mecanismos de herencia.

En una generalización, los atributos y las operaciones asociadas a las clases de nivel superior también están asociadas a las
clases de menor nivel. Las clases de nivel inferior son subclases que heredan los atributos y operaciones de sus superclases.
Estas clases de nivel inferior son mas especificas y pueden añadir atributos y operaciones.

Jerarquía de generalización

38
Jerarquía de generalización con características agregadas

Agregación

Un modelo de agregación muestra como las clases se componen de otras clases. Estos modelos son similares a la parte de
la relación en las modelos de datos semánticos.

Modelos de comportamiento

Son los modelos del comportamiento dinámico de un sistema, cuando se esta ejecutando. Muestran lo que ocurre cuando
un sistema responde a un estímulo de su entorno.

Los estímulos pueden ser de 2 tipos: Datos o Eventos.

Modelado impulsado por datos

Muchos sistemas empresariales son sistemas de procesamiento de datos. Son controlados por la entrada de datos al
sistema, con relativamente poco procesamiento de eventos externos.

Estos modelos muestran la secuencia de las acciones involucradas en el procesamiento de datos de entrada y la salida
asociada. Son particularmente útiles durante el análisis de los requisitos, ya que pueden ser utilizados para mostrar el
procesamiento de extremo a extremo en un sistema.

Un modelo de actividad de la operación de la bomba de insulina

39
Procesamiento de pedidos

Modelado impulsado por eventos

Sistemas de tiempo real son a menudo gestionados por eventos, con un procesamiento de datos mínimo.

Modelado por eventos muestra cómo un sistema responde a acontecimientos externos e internos. Se basa en la suposición
de que un sistema tiene un número finito de estados y que los acontecimientos (estímulos) puede causar una transición de
un estado a otro.

Modelos de máquina del Estado

Estos modelan el comportamiento del sistema en respuesta a eventos externos e internos. Muestran las respuestas del
sistema a los estímulos tan a menudo se utilizan para el modelado de sistemas de tiempo real.

Modelos de máquinas de estado muestran los estados del sistema como nodos y eventos como arcos entre estos nodos.
Cuando ocurre un evento, el sistema pasa de un estado a otro.

Diagrama de estado de un horno de microondas

40
Los estados y los estímulos para el horno de microondas(a)

El funcionamiento del horno de microondas

41
 DIAGRAMAS UML

• Especifica un comportamiento deseado del sistema.

• Representa los requisitos funcionales del sistema.
• Describe qué hace el sistema, no cómo lo hace.

Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y
que produce un resultado observable de valor para un particular actor.

Es un diagrama de comportamiento

• Se utiliza para representar los actores externos que interactúan con el sistema de información
• Muestra de manera visual las distintas funciones que puede realizar un usuario (más bien un tipo de usuario) de un
Sistema de Información.

Finalidad

• Representar los requisitos funcionales.

• Representar los actores que se comunican con el sistema.
• Representar las relaciones entre requisitos funcionales y actores.
• Guiar el desarrollo del sistema.
• Comunicarse de forma precisa entre cliente y desarrollador.

Elementos

Actores: un actor es algo o alguien externo al sistema que interactúa de forma directa con el sistema.

Casos de uso: Es una secuencia de acciones que hace el sistema y que producen un resultado que puede percibir un usuario.

Relaciones: Conectan los casos de uso con los actores o los casos de uso entre sí.

Cuando conectan un actor con un caso de uso representa que ese actor interactúa de alguna manera con ese caso de uso
y se representa con una línea continua

Cuando conectan casos de uso entre sí se pueden diferenciar dos tipos de relaciones: <<include>> o <<extend>>.

<<include>>: Se utiliza para representar que un caso de uso utiliza siempre a otro caso de uso.

42
Descripción de requisitos

Se describe cada caso de uso junto con la secuencia de pasos necesaria para completarlo y las posibles excepciones.

Esta descripción sirve de guía para el desarrollo

• Identificador y nombre descriptivo

• Versión
• Autores
• Objetivos asociados
• Requisitos asociados
• Descripción
• Precondición
• Secuencia normal
• Postcondición
• Excepciones
• Importancia
• Urgencia
• Comentarios

Diseño de una aplicación que gestione los tramites a realizar en una clínica veterinaria

• Se deben almacenar los datos de contacto de los clientes: Nombre, Apellidos, DNI, Fecha de nacimiento, Teléfono o
Email.
• Se debe almacenar la información de las mascotas. Cada cliente puede tener más de una mascota, una mascota
pertenece a un único cliente.
• Es posible cambiar el dueño de una mascota por otro.
• Estos datos son introducidos y gestionados por los auxiliares.
• Al dar de alta un nuevo animal, se comprobará en el registro del REIAC (Red Española de Identificación de Animales de
Compañía) si el animal está correctamente dado de alta. Este proceso únicamente se hará en animales que tengan la
obligación de estar identificados.
• Para toda consulta debe registrar Tiempo de consulta, Profesional, Animal tratado, Importe, Resolución, Recetas.
• Si el animal queda internado, el cliente podrá acceder a su estado en tiempo real y podrá comunicarse con una cámara
para ver su situación actual. La gestión de estas cámaras no corresponde al sistema.
43
• Las recetas y otros documentos relacionados con el servicio se incluirán en un gestor de contenidos que ya está en
funcionamiento en la clínica veterinaria.
• El cliente podrá realizar el pago mediante la aplicación. Si el pago tarda más de una semana se efectuará un recargo
sobre el precio inicial.
• El cliente podrá obtener un histórico de todas las consultas que se han realizado para sus mascotas.

Diagrama de casos de uso del actor Auxiliar

Diagrama de casos de uso del actor Cliente

44
 Diagrama de casos de uso del actor Veterinario

Diagrama de clases

Es un diagrama de estructura

• Se utiliza para representar los elementos que componen un sistema de información desde un punto de vista estático.
• No incluye la forma en la que se comportan los distintos elementos a lo largo de la ejecución

Es un diagrama puramente orientado al modelo de programación orientado a objetos

• Define las clases que se utilizarán en la fase de construcción y la manera en que se relacionan las mismas.
Muestra:
o La representación de datos y su interacción.
o El modelo lógico de los datos de un sistema.

Elementos:

Clases: elemento principal del diagrama y representa una clase dentro del paradigma de la orientación a objetos. Define
un grupo de objetos que comparten características, condiciones y significado. Una clase está compuesta por tres
elementos: nombre de la clase, atributos, funciones.

(+) Pública. Representa que se puede acceder al atributo o función desde cualquier lugar de la aplicación.

(-) Privada. Representa que se puede acceder al atributo o función únicamente desde la misma clase.

(#) Protegida. Representa que el atributo o función puede ser accedida únicamente desde la misma clase o desde las clases
que hereden de ella (clases derivadas).

Relaciones

• Una relación identifica una dependencia.

45
 • Las relaciones se representan con una línea que une las clases

Propiedades :

• Multiplicidad. Es decir, el número de elementos de una clase que participan en una relación. Se puede indicar un
número, un rango y se utiliza n o * para identificar un número cualquiera.
• Nombre de la asociación. En ocasiones se escribe una indicación de la asociación que ayuda a entender la relación
que tienen dos clases. Suelen utilizarse verbos.

Tipos de relaciones

• Asociación
• Agregación
• Composición
• Herencia

Asociación

Este tipo de relación es el más común y se utiliza para representar dependencia semántica. Se representa con una simple
línea continua que une las clases que están incluidas en la asociación.

Ej.: Una mascota pertenece a una persona

Agregación

Es una representación jerárquica que indica a un objeto y las partes que componen ese objeto. Representa relaciones en
las que un objeto es parte de otro, pero tiene existencia en sí mismo. Se representa con una línea que tiene un rombo en
la clase que es una agregación de la otra (en la clase que contiene las otras).

46
Composición

Representa una relación jerárquica entre un objeto y las partes que lo componen de una forma más fuerte que en la
agregación. Cuando el elemento contenedor desaparece, desaparecen todos los contenidos. No tienen sentido por sí
mismos.

Contenedor y contenidos tienen los mismos tiempos de vida. Se representa con una línea continua con un rombo relleno
en la clase que es compuesta.

Herencia

Este tipo de relaciones permiten que una clase (clase hija o subclase) reciba los atributos y métodos de otra clase (clase
padre o superclase). Estos atributos y métodos recibidos se suman a los que la clase tiene por sí misma. Se utiliza en
relaciones “es un”.

Diagrama de clases – Clínica Veterinaria

47
Diagrama de secuencia

Es un diagrama de interacción. Permite:

• Representar el intercambio de mensajes entre los distintos objetos del sistema para cumplir con una funcionalidad.
• Definir el comportamiento dinámico del sistema de información.
• Definir como se realiza un caso de uso.
• Comprender el diagrama de clases.

Muestra como las instancias de clases interactúan mediante el intercambio de mensajes.

Está construido a partir de dos dimensiones:

• Horizontal: Representa los objetos que participan en la secuencia.

• Vertical: Representa la línea de tiempo sobre la que los elementos actúan.

Objeto

• Representa a un participante en la interacción.

• Puede ser instancia de una clase, un módulo, un grupo de clases, es decir un componente software que tiene una
funcionalidad específica
• Cada objeto representa solamente una instancia.
• Se representa mediante un rectángulo que incluye un identificador en su interior
• De cada uno sale una línea vertical hacia abajo que representa el tiempo en el que está presente.

Mensaje

• Representa el paso de un mensaje entre dos objetos o entre un objeto y sí mismo.

• Flecha con el nombre del mensaje y los argumentos y que va desde el objeto que envía hacia el objeto que recibe.

48
Ejemplo:

Sistema de gestión para un puesto de alquiler de películas.

Diagrama de casos de uso

Diagrama de clases

49
Proceso de alquiler de Películas

1. El empleado ingresa al sistema

2. Selecciona la opción "Alquilar película".
3. Se debe completar un formulario con cabecera y cuerpo
4. En la cabecera inserta datos del cliente.
5. En el cuerpo inserta los ejemplares que alquila.
6. Se oprime el botón "calcular pago" y se espera la respuesta.
7. Se oprime el botón "registrar" para finalizar el registro del alquiler.
8. El sistema muestra un mensaje diciendo que el alquiler se ha registrado satisfactoriamente

Diagrama de secuencia

DISEÑO ARQUITECTONICO

ARQUITECTURA DE SOFTWARE

El l diseño arquitectónico es un proceso de diseño que permite la identificación de los sub-sistemas que componen un
sistema y su comunicación. El resultado de este proceso de diseño es una descripción de la arquitectura de software.

Diseño arquitectónico

• Una fase temprana del proceso de diseño del sistema.

• Representa el vínculo entre los procesos de especificación y diseño.
50
• Suelen llevarse a cabo en paralelo con las actividades de algunas especificaciones.
• Se trata de identificar los principales componentes del sistema y sus comunicaciones.

Ventajas de la arquitectura explicita

• Comunicación entre los stakeholders

o La arquitectura puede ser utilizada como un foco de discusión del sistema por los stakeholders.
• Análisis del sistema
o Significa que el análisis de si el sistema puede hacer frente a sus requerimientos no funcionales es posible.
• Reutilización a gran escala
o La arquitectura puede ser reutilizable a través de una variedad de sistemas.

Arquitectura y características del sistema

• Rendimiento
o Reducir al mínimo las operaciones de comunicaciones. Uso de grano grueso en lugar de componentes de
grano fino.
• Seguridad
o Una arquitectura con los procesos críticos en las capas interiores.
• Disponibilidad
o Incluir componentes redundantes y los mecanismos de tolerancia a fallos.
• Mantenibilidad
o Uso de grano fino, los componentes reemplazables.

Estructura del sistema

Concerniente a la descomposición del sistema en sub-sistemas. El diseño arquitectónico se expresa normalmente como un
diagrama de bloques que presentan un panorama general de la estructura del sistema.

Modelos más específicos muestran cómo los sub-sistemas comparten los datos, se distribuyen y la interfaz con los demás
también pueden ser desarrollados.

Sistema de control de robot de embalaje

51
Box y diagramas

Muy abstracto - que no muestran la naturaleza de los componentes ni las relaciones de las propiedades visibles
externamente de los sub-sistemas. Sin embargo, útil para la comunicación con las partes interesadas y para la planificación
de proyectos.

Decisiones de diseño arquitectónico

Diseño arquitectónico es un proceso creativo, por lo que el proceso es diferente dependiendo del tipo de sistema que se
está desarrollado. Sin embargo, es común una serie de decisiones, en todos los procesos de diseño.

• ¿Existe una arquitectura de aplicaciones genéricas que se pueden utilizar?

• ¿Cómo se distribuirá el sistema?
• ¿Qué estilos arquitectónicos son apropiados?
• ¿Qué enfoque se utilizará para la estructura del sistema?
• ¿Cómo el sistema se descompone en módulos?
• ¿Qué estrategia de control se debe utilizar?
• ¿Cómo el diseño arquitectónico se evaluará?
• ¿Cómo debe ser documentada la arquitectura?

Reutilización de la arquitectura

• Sistemas en el mismo dominio a menudo tienen arquitecturas similares que reflejan conceptos del dominio.
• La aplicación de líneas de producción se construye en torno a un núcleo con arquitectura particular, con variantes que
satisfagan las necesidades del cliente.

Estilos arquitectónicos

• El modelo arquitectónico de un sistema puede ajustarse a un modelo genérico o estilo arquitectónico.

• La conciencia de estos estilos puede simplificar el problema de la definición de arquitecturas de sistemas.
• Sin embargo, la mayoría de los grandes sistemas son heterogéneos y no siguen un mismo estilo arquitectónico.

Modelos arquitectónicos

• Utilizarse para documentar un diseño arquitectónico.

• Modelo estructural estático, que muestra los principales componentes del sistema.
• Modelo de proceso dinámico que muestra el modelo de proceso de la estructura del sistema.
• Modelo de interfaz que define las interfaces de sub-sistemas.
• Modelo de relaciones, como un modelo de flujo de datos que muestra las relaciones de sub-sistemas.
• Modelo de distribución que muestra cómo los sub-sistemas se distribuyen a través de computadoras.

Modelo Vista – Controlador

52
Aplicación Web con arquitectura MVC

Modelo repositorio

• Sub-sistemas de intercambio de datos. Esto puede hacerse de dos maneras:

o Datos compartidos se lleva a cabo en un repositorio o base de datos central y puede ser visitada por todos
los sub-sistemas;
o Cada sub-sistema mantiene su propia base de datos y pasa datos explícitamente a otros subsistemas.
• Cuando grandes cantidades de datos sean compartidos, el modelo de repositorio compartido es más comúnmente
utilizado.

Características:

Ventajas

• Manera eficaz de compartir grandes cantidades de datos;

• Sub-sistemas no tienen por qué preocuparse de cómo los datos se producen, por ejemplo, la gestión centralizada copia
de seguridad, seguridad, etc.
• Un modelo a compartir se publica como el esquema del repositorio.

Desventajas

• Sub-sistemas deben ponerse de acuerdo sobre un modelo repositorio de datos. Inevitablemente, un compromiso;
• La evolución de datos es difícil y costosa;
• No hay lugar para las políticas de gestión específicas;
• Difícil de distribuir de manera eficiente.

Arquitectura de repositorio IDE

53
Modelo Cliente – Servidor

• Sistema distribuido que muestra cómo el modelo de datos y procesamiento se distribuye a través de una gama de
componentes.
• Conjunto de servidores independientes que ofrecen servicios específicos, tales como la impresión, gestión de datos,
etc.
• Conjunto de clientes que piden a éstos los servicios.
• Red que permite a los clientes acceder a los servidores.

Características:

Ventajas

• Distribución de datos es sencilla;

• Hace un uso eficaz de los sistemas en red. Puede requerir hardware más barato;
• Fácil añadir nuevos servidores o actualizar los servidores existentes.

Desventajas

• No hay un modelo de datos compartidos, así que los sub-sistemas utilizan diferentes datos de la organización.
Intercambio de datos puede ser ineficaz;
• Redundantes en la gestión de cada servidor;
• No hay registro central de nombres y servicios - que puede ser difícil de averiguar qué servidores y servicios están
disponibles.

Biblioteca de imágenes y películas

Modelo de capas

• Se utiliza para modelar la interacción de sub-sistemas.

• Organiza el sistema en un conjunto de capas (o máquinas abstractas) cada uno de los cuales provee un conjunto de
servicios.
• Apoya el desarrollo gradual de sub-sistemas en diferentes capas. Cuando una capa cambia, sólo la capa adyacente se
ve afectada.

Sistema de Gestión

54
Sistema de biblioteca

Modelo de tubería y filtro

Cada componente de procesamiento (filtro) es discreto y realiza un tipo de transformación de datos. Los datos fluyen
(como en una tubería) de un componente a otro para su procesamiento.

• Se utiliza en aplicaciones de procesamiento de datos (tanto basadas en lotes como en transacciones)

La estructura de las aplicaciones del procesamiento de transacciones

La arquitectura de SW de un sistema ATM

55
Arquitectura del sistema de información por capas

La arquitectura de MHC – PMS

La arquitectura de un sistema de procesamiento de lenguaje

56
Arquitectura de compilador de tuberías y filtros

Arquitectura de repositorio para un sistema de procesamiento de lenguaje

57