Diagramas Entidad-Relación

¿Qué es un diagrama entidad-relación?

Es una herramienta para el modelado de datos que permite representar las entidades de un sistema de información así como sus interrelaciones y propiedades. Los diagramas ER emplean un conjunto definido de símbolos, tales como rectángulos, diamantes, óvalos y líneas de conexión para representar la interconexión de entidades, relaciones y sus atributos, además en ellos se definen conceptos tales como diagrama, entidad relación, atributo, relación, conjunto de relaciones, otros.

Usos de los diagramas ER

- Diseñar bases de datos: se usan para modelar y diseñar bases de datos relacionales, en términos de reglas de negocio y lógicas y en términos de la tecnología específica que se implementará. Es a menudo el primer paso para determinar los requisitos de un proyecto de sistemas de información.

- Solución de problemas de bases de datos: se usan para analizar las bases de datos existentes con el fin de hallar y resolver problemas de lógica o implementación.

- Sistemas de información empresarial: se usan para diseñar o analizar las bases de datos relacionales empleadas en procesos de negocio. 

- Reingeniería de procesos de negocio: ayudan a analizar las bases de datos empleadas en la reingeniería de procesos de negocio y en el modelado de la configuración de una nueva base de datos.

- Educación: son el método actual de almacenamiento de información relacional para propósitos educativos y la posterior recuperación.

- Investigación: como hay muchas investigaciones centradas en los datos estructurados, los diagramas ER pueden desempeñar un papel fundamental en la configuración de la base de datos útiles para analizar datos.

El modelo entidad-relación se basa en los conceptos que se describirán a continuación para representar un modelo de la vida real.

Entidad

Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus características llamadas atributos.

Atributos

Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.

Relación

Es una asociación o relación matemática entre varias entidades. 

Conjunto de relaciones

Es una colección o conjunto de relaciones de la misma naturaleza.

Correspondencia de cardinalidades

Indica el número de entidades con las que puede estar relacionada una entidad dada.

Uno a Uno (1:1) cada registro de la tabla A sólo puede tener un registro coincidente en la tabla B y viceversa.

Uno a Muchos(1:N) cada registro de la tabla A puede tener muchos registros en la tabla B, pero un registro de la tabla B solo puede tener un registro en la tabla A.

Muchos a Uno (N:1) un registro de la tabla A solo puede tener un registro en la tabla B, pero un registro en la tabla B puede tener muchos registros en la tabla A.

Muchos a Muchos (N:M) un registro de la tabla A puede tener muchos registros en la tabla B y viceversa.

Claves

Superclave es un subconjunto de atributos que permiten distinguir univocamente cada una de las entidades de un conjunto de entidades.

Llave candidata son todos los atributos que pueden ser una llave primaria pero no lo son.

Llave primaria es un atributo elegido por el diseñador de la base de datos para identificar univocamente las entidades en un conjunto de entidades.

Los elementos que se utilizan en el diagrama ER para su representación son los siguientes:

Los diagramas ER son muy efectivos para crear bases de datos y siempre que se desee crear una nueva es recomendable crear el modelo o diagrama previamente para así saber que lo que se está creando es correcto y es exactamente lo que se está buscando.

http://tramullas.com/documatica/2-7.html
http://www.duiops.net/manuales/access/access10.htm
http://www.cs.us.es/cursos/bd-2001/temas/diseno.html

DevOps

¿Por qué DevOps?

Negocio => Cualquier persona o empresa que tenga un problema. El negocio trata temas de tiempo y presupuesto.

Se divide en dos partes:

Desarrollo: los involucrados en el mantenimiento o desarrollo del sistema.

Operaciones: mantienen en funcionamiento un sistema.

Pared confusión: 

Desarrolladores              |               Operaciones

                                        |

construyen                      |             mantiene la estabilidad

codifican                         |             adaptan los cambios en poco tiempo

crean cambios               |

Una transacción

Un problema específico

Sin impacto en usuarios reales

Sprint (duran días o semanas)

Cientos o miles de transacciones

No conocen causas

Impacto real en usuarios

SLA (duran horas o minutos)

¿Qué es DevOps?

DevOps es un conjunto de herramientos => MITO

DevOps es solo para empresas unicornio => MITO

Es una transformación organizacional diferente a cualquier otra => MITO

DevOps es una cultura donde todos tienen un objetivo. => Realidad

Un movimiento profesional emergente que impulsa una relación de trabajo colaborativo entre desarrolladores y operaciones de TI, que resulta en el flujo rápido de trabajo planificado.

- Gene Kim

Los procesos de DevOps son:

¿Cómo implementar DevOps?

Tres pasos hacia DevOps:

- Pensamiento de sistemas.

- Ciclos de retroalimentación.

- Cultura de experimentación y aprendizaje continuo.

Pensamiento de sistemas

Flujo == Visiblidad

Proceso y debilidades

Se invierte mucho tiempo realizando el mismo proceso una y otra vez al realizar pruebas solitarias.

Ciclos de retroalimentación

Se usan ciclos de retroalimentación cortos y de mayor alcance.

Se trabaja la calidad desde la fuente para evitar retrabajo.

Cultura de experimentación y aprendizaje continuo

Es un aprendizaje a partir de los fallos o de lo que pudo llegar a fallar.

Se utiliza la formula: 

Se crea una cultura para el trabajo colaborativo lo que aumenta la eficacia del mismo, se busca la automatización para una mayor eficacia, se utilizan métricas para evaluar el desarrollo y se comparte con las personas pertenecientes al proyecto.

Tomado de la charla sobre DevOps realizada por Avantica en el ITCR.

Prototipado

En el desarrollo del software existe un método de validación, el cual consiste en la creación de una maqueta o versión del producto final, con el fin de comprobar la correctitud y completitud del ERS.

Pero, ¿qué es un prototipo?, un prototipo es un modelo a escala, pero no tan funcional como para ser evaluado como el producto final, ya que a pesar de tener funciones del sistema, éste no tiene la totalidad de las funciones que se verán en el producto final. Los prototipos suelen utilizarse mayormente en dos fases del proyecto:

-Etapa de análisis: se utilizan prototipos para obtener los requerimientos del usuario, como principal objetivo tienen obtener y validar los requerimientos esenciales, manteniendo abiertas las opciones de  implementación.

-Etapa de diseño: se utilizan para evaluar aspectos de la implementación realizada, el propósito que tienen es, basándose en los requerimientos obtenidos previamente, mostrar las ventanas, navegación, interacción, controles y botones al usuario y de esta forma obtener una retroalimentación que permita mejorar el diseño de la interfaz del producto.

Existen muchos tipos de prototipos, algunos de ellos son:

Cada tipo de prototipo necesita de tiempo para su construcción, por lo que la respuesta para saber cuál es recomendable construir consta de dos factores:

-Recursos y tiempo disponibles: cuanto más limitados sean estos recursos, más conveniente será crear prototipos sencillos.

-Fidelidad deseada: si el usuario no logra entender el prototipo por tener una fidelidad muy baja, se deberá pasar a construir prototipos de una fidelidad mayor con la intención de que el usuario o cliente logre entender de qué trata el prototipo realmente.

Algunas ventajas que contiene la creación de prototipos son:

-Modificación del sistema en etapas tempranas de su desarrollo: los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se realizaran en etapas tardías del proyecto.

-Eliminación de requerimientos indeseables: durante la creación de prototipos y la evaluación de éstos con el cliente se pueden encontrar requerimientos que quizás no lleguen a ser como el cliente pensó que serían cuando los solicitó.

-Diseño de sistemas acorde a las necesidades del cliente: al igual que el punto anterior, durante la revisión de los prototipos con el cliente se pueden cambiar los requerimientos que se encontraron en un principio por otros que sean acorde a los que el cliente espera.

Algunas desventajas son:

-Adoptarlo como el sistema final: los usuarios pueden considerar el prototipo como si fuera el sistema final aun cuando está incompleto o es inadecuado para su uso.

Es importante saber el tipo de prototipo que se desea implementar de acuerdo a la fidelidad que busca el cliente en éste, además es necesario utilizar correctamente el tiempo del que se dispone para la creación de los prototipos, ya que es tiempo valioso en el desarrollo del sistema.

BURCH J. G. y GRUDNITSKI G.,1997, Diseño de Sistemas de Información. Megabyte Noriega Asociados.

KENDALL, K. E. y KENDALL J. E.,1991, Análisis y Diseño de Sistema. Prentice –Hall Hispanoamericana S.A.

Elicitación de Requerimientos

¿Qué es la elicitación de requerimientos? Es la parte principal en el desarrollo de proyectos de software y tiene un impacto alto en el diseño y en las demás fases del ciclo de vida del producto que se piensa desarrollar. La elicitación se considera como la primera etapa en el proceso de abstraer una idea o comprensión mas acertada del problema que se desea resolver con el software.

Existen varias técnicas para la elicitación de requerimientos, algunas son:

- Entrevistas

Son reuniones normalmente entre dos personas, pero se pueden realizar con más personas, en las que se plantean una serie de preguntas para obtener respuestas que ayuden a entender el contexto de un determinado dominio de problemas.

Las entrevistas deben planificarse, determinando su duración, los temas a tratar y seleccionando el número mínimo de personas a entrevistar dentro de la organización en función de su perfil profesional.

- Estudio de documentación

Consiste en realizar una lectura profunda basada en documentos que ayuden a encontrar una solución a un problema especifico.

- Observación in situ

Consiste en la observación directa de las prácticas que se realizan en la organización para la que se va a desarrollar el software.

Existen algunas variantes de la observación in situ como son la inmersión dentro de la organización para la que se va a desarrollar el software o la realización de periodos de aprendizaje por parte de los ingenieros de requisitos, en las que la observación pasiva se cambia por una participación en los procesos a observar como si fuera un miembro más del personal de la organización bajo estudio.

- Joint Application Development

Se basa en realizar reuniones integradas por miembros del equipos de desarrollo y miembros de la organización a la que se le desarrollará el software. Durante la reunión el coordinador planea los puntos a discutir para determinar los objetivos y requisitos generales del sistema a desarrollar.

- Tormenta de ideas

Es una técnica de reuniones en grupo, cuyo objetivo es la generación de ideas en un ambiente libre de criticas o juicios.

- Talleres de trabajo

Son reuniones integradas por clientes y usuarios y parte del equipo de desarrollo. Se trata de reuniones en las que se exploran distintos casos de uso sin llegar a un nivel profundo del caso de uso, evitando de esa forma un nivel excesivo de detalle, lo que alargaría las reuniones más tiempo del necesario.

Existen muchas formas para la elicitación de requerimientos y todas funcionan de diferente forma de acuerdo al grupo con el que se desean obtener requerimientos para un sistema que se desea desarrollar. Antes de escoger una técnica, se debe analizar la organización y el sistema que se quiere realizar para de esta forma poder escoger la técnica que permita obtener requerimientos de una forma mas sencilla y mas detallada o con una mejor compresión.

M. G. Christel & K C. Kang. “Issues in Requirements Elicitation”. Technical Report CMU/SEI-92-TR-012, ESCTR-92-012. Software Engineering Institute, Carnegie Mellon University, 1992.

I. Sommerville & P. Sawyer. “Requirements Engineering: A Good Practice Guide”. John Wiley & Sons, 1997.  

Modelo de casos de uso

¿Qué es un caso de uso?. Son una descripción de los pasos o actividades que se deben realizar para llevar a cabo algún proceso. Es una secuencia de interacciones que se desarrollan entre un sistema y los actores en respuesta a un evento que inicia un actor principal en el propio sistema. 

Los diagramas de caso de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante la interacción con usuarios u otros sistemas. El uso de éstos es muy común para la obtención de requisitos funcionales en el desarrollo de un sistema. 

La idea de utilizar casos de uso es evitar el lenguaje técnico, prefiriendo así la lengua que utilice el usuario final, facilitando el entendimiento de éstos. Los casos de uso son a menudo elaborados en colaboración con el cliente junto con los analistas de requerimientos.

Un caso de uso se centra en describir como alcanzar una meta o tarea única, esto significa que a veces es necesario especificar decenas o centenares de casos de uso para un solo proyecto. 

Un caso de uso debe:

• Describir una tarea del negocio que sirva a una meta
• Tener un nivel apropiado de detalle
• Ser bastante sencillo

Durante la creación de un caso de uso se pueden dar algunas situaciones como:

• Un actor se comunica con un caso de uso
• Un caso de uso extiende de otro caso de uso
• Un caso de uso incluye otro caso de uso

Utilizar casos de uso tiene mucho éxito en sistemas interactivos, ya que permite ver observar la intención que tiene el actor al hacer uso del sistema.

Una limitación que tienen los casos de uso es que aunque son útiles para establecer los requisitos de comportamiento de un sistema, no permiten establecer completamente los requisitos funcionales ni determinan los requisitos no funcionales.

A pesar de ésto último, es muy importante desarrollar casos de uso para poder entender el comportamiento que tendrá el sistema durante su ejecución de acuerdo a las acciones que realice el usuario.

Jacobson, I., P. Jonsson, M. Christerson and G. Overgaard, Ingeniería de Software Orientada a Objetos - Un acercamiento a través de los casos de uso. Addison Wesley Longman, Upper Saddle River, N.J., 1992.

ERS

El ERS o Especificación de Requerimientos de Software es un documento que va dirigido tanto a clientes como al equipo encargado del desarrollo de software, debe de estar escrito en un lenguaje de fácil entendimiento para ambas partes, su principal objetivo es  que pretende describir completamente el comportamiento de un sistema que se piensa desarrollar. En él se incluyen casos de uso o requisitos funcionales que describen o explican las interacciones entre usuarios y el software, además de los requisitos funcionales se encuentran también los requisitos no funcionales, éstos son los que dan las restricciones de diseño o implementación en el software.

Las características para un buen documento ERS son definidas por el estándar IEEE 830-1998, que son:

• Completo: Todos los requerimientos deben estar reflejados y todas las referencias  bien definidas.
• Consistente: Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
• Inequívoco: La redacción debe ser clara de modo que no haya ambigüedad.
• Correcto: El software debe cumplir con los requisitos de la especificación.
• Trazable: Posibilidad de verificar la historia, ubicación o aplicación de un requerimiento a través de su identificación almacenada y documentada.
• Priorizable: Los requisitos deben organizarse jerarquicamente según la importancia para el negocio.
• Modificable: Debe ser fácilmente modificable.
• Verificable: Debe existir un método finito sin costo para poder probarlo.

Aunque existen muchas plantillas para crear un ERS, se debe de escoger la que mas se ajuste al proyecto que se desea implementar ya que no todas cubren la misma cantidad de campos del ERS y algunas se enfocan más en un sector especifico. 

https://www.ctr.unican.es/asignaturas/is1/IEEE830_esp.pdf

Proceso de Ingeniería de Requisitos

En la Ingeniería de Software, la Ingeniería de Requisitos,  comprende las tareas relacionadas con la obtención de las necesidades o de las condiciones para la elaboración o modificación de un software, ésto tomando en cuenta los diversos requerimientos de las partes interesadas. El propósito de ésta, es hacer que los requerimientos o requisitos sean óptimos antes de llegar al diseño del sistema. La ingeniería de requisitos tienen como objetivo:

• Definir las características de un sistema de software que satisfaga las necesidades de negocio de clientes y usuarios.
• Gestionar las lineas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos.

Éste proceso, como se muestra en la anterior imagen, comprende cuatro actividades de alto nivel:

1. Estudio de factibilidad 
2. Obtención y análisis de requerimientos
3. Especificación de requerimientos
4. Validación de requerimientos

1- Estudio de factibilidad: es de corto plazo y está orientado a resolver si el sistema:

• Contribuye a los objetivos de la organización
• Se puede implementar con tecnología actual dentro del tiempo y costo establecido
• Puede integrarse a otros sistemas existentes en la organización

2- Obtención y análisis de requerimientos: es un proceso difícil ya que:

• Los interesados no conocen con exactitud qué es lo que desean, solo saben términos muy generales
• Los interesados explican los requerimientos con sus propios términos utilizando lenguaje de su propio trabajo que el analista quizás no conoce
• El entorno es dinámico, puede cambiar la importancia de los requerimientos, pueden aparecer nuevos requerimientos.

Durante el proceso se deben realizar las siguientes actividades:

• Comprensión del dominio
• Recolección de requerimientos
• Clasificación de los requerimientos
• Resolución de conflictos
• Priorizar los requerimientos importantes
• Verificación de los requerimientos (completos, consistentes y acordes)

3- Especificación de requerimientos: en ésta etapa se describen los requerimientos que tanto el cliente como el contratista crean necesarios para el software. Algunos puntos importantes son:

• Los requerimientos de sistemas grandes son siempre cambiantes
• Surgirán nuevos requerimientos debido a:
• Comunidad de usuarios diversos
• El que paga es raramente el que utiliza el sistema
• Entorno de negocios y técnico cambiante

4- Validación de requerimientos

• Es similar al análisis pero con un bosquejo completo del documento en lugar de requerimientos incompletos
• Es importante porque los errores en los requerimientos pueden inducir a costos excesivos si se descubren durante el desarrollo o después de la implementación
• Es difícil demostrar que un conjunto de requerimientos cumplen con las necesidades del usuario desde la primera vez que se describen.

En esta etapa se deben llevar a cabo diferentes tipos de verificación:

• Verificación de validez
• Verificación de consistencia
• Verificación de integridad
• Verificación de realismo

Algunas técnicas para la verificación de requerimientos son:

• Revisiones de requerimientos con el cliente
• Construcción de prototipos
• Generación de casos de prueba
• Análisis de consistencia automático

4.1- Revisiones de requerimientos

• Proceso manual que involucra a varios lectores tanto del cliente como del contratista
• Puede ser formal o informal
• Los conflictos, contradicciones, errores y omisiones deben señalarse durante la revisión y registrarse formalmente

Durante éstas revisiones se comprueba:

• Consistencia
• Integridad
• Verificabilidad
• Comprensibilidad
• Rastreabilidad
• Adaptabilidad

El proceso de obtención de requisitos es un poco complicado según el cliente y el software que se desee desarrollar, ya que no siempre los clientes tienen claro qué es lo que desean, sino que dan ideas de lo que le gustaría tener, es por ésto que muchas veces se deben de cambiar los requerimientos incluso después de haber empezado el desarrollo del sistema, por esa razón se debe tomar en cuenta el tipo de cliente y el sistema que éste desea e intentar descifrar correctamente qué es lo que él desea con tal de evitar la mayor cantidad de cambios.

Indefinido. (2013). ¿Requisitos o Requerimientos?. noviembre 2, 2013, de Investigación IT Sitio web: http://web.archive.org/web/20160310011046/http://investigacionit.com.ar/es/requisitos-o-requerimientos/

http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/ingenieria-requisitos