Diagrama de nodos

Calidad

Introducción

Conocer el significado de “calidad” y su respectiva aplicación en el software representa un asunto de vital importancia para cualquier desarrollador. La calidad conlleva una serie de aspectos que deben de ser revisados, bajo distintos  estándares, que garantizan que el software desarrollado es lo suficientemente bueno como para poder ganar una certificación.

¿Qué es calidad?

Es un conjunto de propiedades que una cosa posee y por medio de las cuales es posible caracterizarla y compararla con otras cosas similares, ya sea para bien o para mal de ésta. En el software se aplica la misma definición.

Modelos de calidad

·         Calidad del producto

·         Calidad del proceso

Ø  Se busca analizar las cualidades del proceso que más influyen en la calidad del producto.

Ø  Se modela el proceso para analizarlo mejor.

·         Calidad de uso

ISO 9126

Es un estándar internacional para la evaluación del software, originalmente desarrollado en 1991 para proporcionar un esquema de evaluación de la calidad del software.

La normativa define seis características de la aplicación, las cuales a su vez están divididas en un número de sub-características que representan un modelo detallado para la evaluación de cualquier sistema informático.

Funcionalidad

Capacidad del software de proveer los servicios necesarios para cumplir con los requisitos funcionales.

Confiabilidad

Capacidad del software de mantener las prestaciones requeridas del sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.

Usabilidad

Esfuerzo requerido por el usuario para utilizar el producto satisfactoriamente.

Eficiencia

Relación entre las prestaciones del software y los requisitos necesarios para su utilización.

Mantenibilidad

Esfuerzo necesario para adaptarse a las nuevas especificaciones y requisitos del software.

Portabilidad

Capacidad del software ser transferido de un entorno a otro.

Conclusión

Antes, durante y después del desarrollo de un software, se debe de prestar atención a los aspectos que las distintas normativas y estándares evalúan en éste, para poder estar preparados para recibir una certificación, y no solo eso, sino para estar seguros de que nuestro software es competente y merece un lugar en el mercado.

Bibliografía

Desconocido. (1 de 09 de 2011). smartsys. Recuperado el 31 de 09 de 2014, de Norma ISO-9126 para análisis de software: http://bemuserp.blogspot.mx/2011/09/norma-iso-9126-para-analisis-de.html

Definiciones. Primer tarea

Introducción

Antes de que un determinado software sea distribuido de manera oficial, debe de pasar por una serie de pruebas que garanticen que tiene un funcionamiento óptimo, corrigiendo en la medida de lo posible, los distintos errores que pudiesen generarse.

Ingeniería de pruebas

La ingeniería de pruebas en el software consiste en revisar y probar un proyecto, desde la especificación de los requerimientos, hasta el código fuente y el desempeño del mismo, con el objetivo de encontrar errores para después notificar de estos a los responsables del proyecto.

“…En cuanto al objetivo de las pruebas, en la definición de Kaner no se reduce exclusivamente a detectar fallos sino que se amplia a ofrecer información, datos, relacionados con la calidad de lo que se está probando…” (Fanjul, 2011)

Ciclo de vida de un software

El ciclo de vida de un software se refiere a una serie de fases en el desarrollo de un software. En cada una de las fases existe una revisión con el objetivo de evitar que los posibles errores existentes se acumulen, para que de esta manera, en la última fase, la de implementación, la cantidad de errores sea mínima, y así evitar gastos mayores corrigiéndolos a esas alturas.

Prueba

Una prueba es un análisis o examen de un proyecto, que se realiza con el objetivo de rectificar que éste cumpla con sus especificaciones, y para  garantizar que tiene la menor cantidad de errores posible.

Tipos de prueba

Pruebas Unitarias

Consisten en probar de manera individual cada método o función de un proyecto, revisando únicamente la lógica existente en su código.

Pruebas de Aceptación de Usuario

Sirven para mostrarle al usuario (ajeno al desarrollo del software) el progreso que se ha tenido en el proyecto.

Pruebas Funcionales

Similares a la pruebas de aceptación, con la diferencia de que no van dirigidas a un público no especializado. Consisten en revisar el funcionamiento del software y verificar que cumpla con sus requerimientos funcionales. Deben de hacerse bajo un amiente controlado.

Pruebas de Integración

Se asemejan a las pruebas funcionales, con la diferencia de que se utilizan datos reales y no datos de prueba, con el fin de garantizar que el software ha sido implementado correctamente.

Pruebas No Funcionales

Se utilizan para verificar que un software cumpla con sus requerimientos no funcionales.

Pruebas de Stress

Su objetivo es garantizar que la aplicación puede recibir muchas peticiones sin que su rendimiento se vea afectado.

Pruebas de Calidad de Código

Este tipo de pruebas sirven para garantizar que la calidad del código es realmente óptima y que la probabilidad de tener errores o bugs en la codificación es mínima (nunca dejarán de existir los bugs pero al menos podemos hacer lo pertinente para disminuir la probabilidad).

Conclusión

Conocer el ciclo de vida del software, y realizar las pruebas correspondientes a cada etapa (conociendo a que tipo de pruebas pertenece cada una) es un asunto de vital importancia para nosotros como futuros desarrolladores. Contar con estos conocimientos nos permite evaluar de manera progresiva la calidad de nuestros programas y aplicaciones, y poder estar seguros de que su funcionamiento es óptimo antes de dar por finalizado un proyecto.

Bibliografía

Definición de. (s.f.). Definición de prueba. Recuperado el 24 de 08 de 2014, de Definición de: http://definicion.de/prueba/

emontoya. (11 de 05 de 2012). Tipo de Pruebas para Desarrollo de Software. Recuperado el 24 de 08 de 2014, de JavaMéxico: http://www.javamexico.org/blogs/emontoya/tipo_de_pruebas_para_desarrollo_de_software

Fanjul, J. G. (15 de 06 de 2011). ¿Qué es probar software? Recuperado el 24 de 08 de 2014, de Isof. Ingeniería y Software: http://isof.wordpress.com/2011/06/15/%C2%BFque-es-probar-software/

Kioskea.net. (07 de 2014). Ciclo de vida del software. Recuperado el 24 de 08 de 2014, de Kioskea: http://es.kioskea.net/contents/223-ciclo-de-vida-del-software

Diccionario de datos

Introducción

Cuando se hace una base de datos, puede suceder que lleguemos a confundirnos con los atributos declarados, es decir, que no sepamos que contiene exactamente cada atributo.
Para esto se crea un diccionario de datos, para saber mejor que información se colocará dentro de cada campo.

Ejercicio1

Ejercicio2

 

Ejercicio3

 

Ejercicio4

 

Ejercicio5

 

Ejercicio6

 

Ejercicio7

 

Ejercicio8

 

Ejercicio9

 

Ejercicio10   

Conclusiones

El diccionario de datos nos ayuda a tener una mejor organizacion para no cometer errores al momento de leer nuestras tablas, y en general, nuestra base de datos, facilitando el manejo y optimizando los tiempos de trabajo.

 

Ejercicios - Bases de datos en MySQL

Introducción

Cuando se realiza el modelado de una base de datos, suelen cometerse algunos errores como caer en la redundancia de información. Estos errores perjudican a futuro la base de datos, pues si ésta no se planifica correctamente, ocurrirán problemas cuando se intente eliminar una tupla, pues se puede eliminar información adicional. Es por eso que una vez que se tiene el modelo relacional, se debe de seguir el proceso de normalización.

EJERCICIO1

EJERCICIO2

EJERCICIO3

EJERCICIO4

EJERCICIO5

EJERCICIO6

EJERCICIO7

EJERCICIO8

EJERCICIO9

EJERCICIO10

Conclusión

La normalización de las relaciones que se dan en una base de datos permite optimizar éstas, eliminando redundancias y otros problemas que pueden ser perjudiciales en determinado momento. Una vez que el modelado de la base de datos se encuentra normalizado, dicha base puede comenzar a ser creada.

Bibliografía

Hispano, M. (29 de 05 de 2003). Recuperado el 23 de 03 de 2014, de http://www.eet2mdp.edu.ar/alumnos/MATERIAL/MATERIAL/info/infonorma.pdf

Marabini, R. (s.f.). Recuperado el 23 de 03 de 2014, de http://biocomp.cnb.csic.es/~roberto/II/Docencia/SI1/Clase/Reserved/Formas_Normales.pdf

Mora, E. (s.f.). Universidad de Cantabria. Recuperado el 23 de 03 de 2014, de http://personales.unican.es/zorrillm/PDFs/Docencia/BasesDatos/Formas%20Normales.pdf

Normalizacion (2)

Introducción

Cuando se realiza el modelado de una base de datos, suelen cometerse algunos errores como caer en la redundancia de información. Estos errores perjudican a futuro la base de datos, pues si ésta no se planifica correctamente, ocurrirán problemas cuando se intente eliminar una tupla, pues se puede eliminar información adicional. Es por eso que una vez que se tiene el modelo relacional, se debe de seguir el proceso de normalización.

Primera forma normal (1FN)

Esta forma consiste en verificar la atomicidad de los distintos atributos de las relaciones. (Marabini) Un atributo es atómico cuando es indivisible. Los atributos que se deben de verificar son aquellos que sean compuestos o multivaluados.

Primeramente, y de manera importante, se debe de tener contemplado el propósito de cada atributo, es decir, que usos futuros se le darán. Esto determinara si el atributo debe ser dividido en otros o dejarese intacto. El ejemplo más común es el atributo Nombre, el cual puede ser tomado como un solo atributo indivisible o separarse en sus componentes Nombres, ApellidoPaterno y ApellidoPaterno. Hacer una u otra opción depende de la finalidad del atributo.

Segunda forma normal (2FN)

Para que en una relación se cumpla la 2FN, tiene que cumplirse de manera obligatoria la 1FN. Esta forma consiste en asegurar que en la relación, todos los atributos no clave dependan de la clave maestra, y no de ningún subconjunto de ella (Mora).

                En caso de que algún atributo no cumpla dicha dependencia, se procede a separarlo en una nueva tabla (Hispano, 2003), dentro de la cual si pueda mantener una dependencia con la clave maestra de dicha tabla.

Tercera forma normal (3FN)

Aun cuando un atributo dependa de la clave maestra, puede depender simultáneamente de otro atributo. Estas dependencias se llaman dependencias transitivas. Para que una relación se encuentre en 3FN, además de tener que encontrarse antes en 2FN, debe de eliminar las dependencias transitivas. (Mora)

                Nuevamente se procede a separar los atributos que se encuentren en dependencia transitiva, creando nuevas tablas en las que los atributos mantengan una dependencia exclusivamente con la clave maestra de la nueva tabla.

Ejercicios

Ejercicio 1

Cliente(ID_cliente, Nombre)

Coche(ID_coche, Accidentes registrados, ID_cliente)

Ejercicio2

Usuario(DNI, Nombres, Apellidos)

Cliente(DNI, Nombres, Apellidos, Direccion, Telefono, Matricula)

Mecanico(DNI, Nombres, Apellidos, Fecha de contratacion, Salario, Matricula, FechaDeReparacion, Horas)

Coche(Matricula, Modelo, Color, Marca)

Coche_Nuevo(Matricula, Modelo, Color, Marca # de unidades existentes)

Coche_Usado(Matricula, Modelo, Color, Marca # de km recorridos)

Ejercicio3

Jugador(ID_Jugador, Estadisticas)

Partido(ID_Partido, Resultado, ID_Jugador)

Ejercicio4

Cliente(No. de cliente, Limite, Descuento, Saldo, Direccion de envio)

Pedido(ID_Pedido, Cabecera, Cuerpo, No.de articulo, ID_CLiente)

Artículo(No. de articulo, Descripcion, # de existencia,Fabricas que lo distribuyen)

Fábrica(No. de fabrica, # de productos que provee, Telefono, No. De articulo)

Ejercicio5

Usuario(RUT, Nombre, Direccion)

Cliente(RUT, Nombre, Direccion , Telefono, ID_Compra)

Proveedor(RUT, Nombre, Direccion , Sitio web, Telefono, ID_Venta)

Adquiere(ID_Compra, ID_Producto, Monto total, Precio, Cantidad)

Venta(ID_Venta, ID_Producto, Fecha, Nombre cliente, Descuento)

Producto(ID_Producto, Nombre proveedor, Precio actual, Nombre, Stock, ID_Categoria)

Categoria(ID_Categoria, Nombre, Descripcion)

Ejercicio6

Aeropuerto(Codigo, Ciudad, Pais, Nombre, Numero de vuelo)

Programa de vuelo(Numero de vuelo, Linea aerea, Linea, Numero de orden)

Escala tecnica(Numero de orden, ID_Vuelo)

Vuelo(ID_Vuelo, Fecha, plazas vacias, modelo de avión, ID_Avion)

Avion(ID_Avion, Modelo, capacidad, Codigo)

Ejercicio7

Sede(Presupuesto, Cantidad)

Complejo(Localizacion, Jefe de organizacion, Area)

Monodeportivos(Localizacion, Jefe de organizacion, Area)

Multideportivos(Localizacion, Jefe de organizacion, Area, Areass)

Evento(ID_Evento, Fecha, Numero de participantes, Duracion, Localizacion, ID_Comisario)

Comisario(ID_Comisario , Rol del comisario, Cantidad)

Ejercicio8

Partido(ID_Partido, Premio de consolacion, Ronda, Premio, Arbitro, Ganador, ID_torneo, Nombre_jugador)

Torneo(ID_torneo , Año, Pais, Lugar, Modalidad)

Jugador(Nombre, Nacionalidad, Premios, FechaContratacion, Posicion, Premio)

Entrenador(NombreEntrenador, Nombre_Jugador)

Ejercicio9

Pelicula(ID_Pelicula, Idioma, Subtitulos, Pais de origen, Año, URL, Resumen, Fecha de estreno, Calificacion, Duracion, Titulo original,Titulo de distribucion, Genero, Nombre_participante, ID_funcion)

Cine(Nombre_Cine, Telefono, Direccion, Numero_Sala)

Opinion(ID_Opinion, Calificacion, Comentario, ID_persona)

Participante(Nombre_Participante, Nacionalidad, ID_pelicula)

Actor(Nombre_Participante, Nacionalidad, # de películas, ID_Personaje)

Director(Nombre_Participante, Nacionalidad, # de peliculas)

Personaje(ID_Personaje)

Persona(ID_Persona, Edad, Nombre, Fecha)

Sala(Numero_Sala, Nombre, Butacas)

Funciones(ID_Funcion, Dia, hora, ID_sala)

Promocion(ID_Promocion, Descripcion, Descuento, ID_Funcion)

Ejercicio10

Mueble(Nombre, Precio, Cantidad)

Pieza(ID_Pieza, ID_Mueble, Cantidad)

Estante(ID_Estante, Altura, pasillo, ID_Pieza)

Conclusión

La normalización de las relaciones que se dan en una base de datos permite optimizar éstas, eliminando redundancias y otros problemas que pueden ser perjudiciales en determinado momento. Una vez que el modelado de la base de datos se encuentra normalizado, dicha base puede comenzar a ser creada.

Bibliografía

Hispano, M. (29 de 05 de 2003). Recuperado el 23 de 03 de 2014, de http://www.eet2mdp.edu.ar/alumnos/MATERIAL/MATERIAL/info/infonorma.pdf

Marabini, R. (s.f.). Recuperado el 23 de 03 de 2014, de http://biocomp.cnb.csic.es/~roberto/II/Docencia/SI1/Clase/Reserved/Formas_Normales.pdf

Mora, E. (s.f.). Universidad de Cantabria. Recuperado el 23 de 03 de 2014, de http://personales.unican.es/zorrillm/PDFs/Docencia/BasesDatos/Formas%20Normales.pdf

Normalización

Introducción

Cuando se realiza el modelado de una base de datos, suelen cometerse algunos errores como caer en la redundancia de información. Estos errores perjudican a futuro la base de datos, pues si ésta no se planifica correctamente, ocurrirán problemas cuando se intente eliminar una tupla, pues se puede eliminar información adicional. Es por eso que una vez que se tiene el modelo relacional, se debe de seguir el proceso de normalización.

Primera forma normal (1FN)

Esta forma consiste en verificar la atomicidad de los distintos atributos de las relaciones. (Marabini) Un atributo es atómico cuando es indivisible. Los atributos que se deben de verificar son aquellos que sean compuestos o multivaluados.

Primeramente, y de manera importante, se debe de tener contemplado el propósito de cada atributo, es decir, que usos futuros se le darán. Esto determinara si el atributo debe ser dividido en otros o dejarese intacto. El ejemplo más común es el atributo Nombre, el cual puede ser tomado como un solo atributo indivisible o separarse en sus componentes Nombres, ApellidoPaterno y ApellidoPaterno. Hacer una u otra opción depende de la finalidad del atributo.

Segunda forma normal (2FN)

Para que en una relación se cumpla la 2FN, tiene que cumplirse de manera obligatoria la 1FN. Esta forma consiste en asegurar que en la relación, todos los atributos no clave dependan de la clave maestra, y no de ningún subconjunto de ella (Mora).

                En caso de que algún atributo no cumpla dicha dependencia, se procede a separarlo en una nueva tabla (Hispano, 2003), dentro de la cual si pueda mantener una dependencia con la clave maestra de dicha tabla.

Tercera forma normal (3FN)

Aun cuando un atributo dependa de la clave maestra, puede depender simultáneamente de otro atributo. Estas dependencias se llaman dependencias transitivas. Para que una relación se encuentre en 3FN, además de tener que encontrarse antes en 2FN, debe de eliminar las dependencias transitivas. (Mora)

                Nuevamente se procede a separar los atributos que se encuentren en dependencia transitiva, creando nuevas tablas en las que los atributos mantengan una dependencia exclusivamente con la clave maestra de la nueva tabla.

Ejercicios

Ejercicio 1

Cliente(ID_cliente, Nombre, ID_coche)

Coche(ID_coche, Accidentes registrados)

Ejercicio2

Usuario(DNI, Nombres, Apellidos)

Se especializa en

Cliente(Direccion, Telefono, Matricula)

y Mecanico(Fecha de contratacion, Salario, Matricula, FechaDeReparacion, Horas)

Coche(Matricula, Modelo, Color, Marca)

Se especializa en

Nuevo(# de unidades existentes)

y Usado(# de km recorridos)

Ejercicio3

Jugador(ID_Jugador, Estadisticas, ID_Partido)

Partido(ID_Partido, Resultado)

Ejercicio4

Cliente(No. de cliente, Limite, Descuento, Saldo, Direccion de envio, ID_Pedido)

Pedido(ID_Pedido, Cabecera, Cuerpo, No.de articulo)

Artículo(No. de articulo, Descripcion, # de existencia,Fabricas que lo distribuyen)

Fábrica(No. de fabrica, # de productos que provee, Telefono, No. De articulo)

Ejercicio5

Usuario(RUT, Nombre, Direccion)

Se especializa en

Cliente(Telefono, ID_Compra)

y Proveedor(Sitio web, Telefono, ID_Venta)

Adquiere(ID_Compra, ID_Producto, Monto total, Precio, Cantidad)

Venta(ID_Venta, ID_Producto, Fecha, Nombre cliente, Descuento)

Producto(ID_Producto, Nombre proveedor, Precio actual, Nombre, Stock, ID_Categoria)

Categoria(ID_Categoria, Nombre, Descripcion)

Ejercicio6

Aeropuerto(Codigo, Ciudad, Pais, Nombre, Numero de vuelo, ID_Avion)

Programa de vuelo(Numero de vuelo, Linea aerea, Linea, Numero de orden)

Escala tecnica(Numero de orden, ID_Vuelo)

Vuelo(ID_Vuelo, Fecha, plazas vacias, modelo de avion)

Avion(ID_Avion, Modelo, capacidad, ID_Vuelo)

Ejercicio7

Sede(Presupuesto, Cantidad)

Complejo(Localizacion, Jefe de organizacion, Area, ID_Evento)

Se especializa en

Monodeportivos()

y Multideportivos(Areas)

Evento(ID_Evento, Fecha, Numero de participantes, Duracion)

Comisario(Rol del comisario, Cantidad, ID-Evento)

Ejercicio8

Partido(ID_Partido, Premio de consolacion, Ronda, Premio, Arbitro,Ganador)

Torneo(Año, Pais, Lugar, Modalidad, ID_Partido)

Jugador(Nombre, Nacionalidad, Premios, NombreEntrenador, FechaContratacion, ID_Partido, Posicion, Premio)

Entrenador(NombreEntrenador)

Ejercicio9

Pelicula(ID_Pelicula, Idioma, Subtitulos, Pais de origen, Año, URL, Resumen, Fecha de estreno, Calificacion, Duracion, Titulo original,Titulo de distribucion, Genero, Nombre_Participante)

Cine(Nombre_Cine, Telefono, Direccion, Numero_Sala)

Opinion(ID_Opinion, Calificacion, Comentario)

Participante(Nombre_Participante, Nacionalidad)

Se especializa en

Actor(# de películas, ID_Personaje)

y Director(# de peliculas)

Personaje(ID_Personaje)

Persona(ID_Persona, Edad, Nombre, ID_Opinion, Fecha)

Sala(Numero_Sala, Nombre, Butacas, ID_funcion)

Funciones(ID_Funcion, Dia, hora, ID_Pelicula, ID_Promocion)

Promocion(ID_Promocion, Descripcion, Descuento)

Ejercicio10

Mueble(Nombre, Precio, ID_Pieza, Cantidad)

Pieza(ID_Pieza, ID_Estante, Cantidad)

Estante(ID_Estante, Altura, pasillo)

Conclusión

La normalización de las relaciones que se dan en una base de datos permite optimizar éstas, eliminando redundancias y otros problemas que pueden ser perjudiciales en determinado momento. Una vez que el modelado de la base de datos se encuentra normalizado, dicha base puede comenzar a ser creada.

Bibliografía

Hispano, M. (29 de 05 de 2003). Recuperado el 23 de 03 de 2014, de http://www.eet2mdp.edu.ar/alumnos/MATERIAL/MATERIAL/info/infonorma.pdf

Marabini, R. (s.f.). Recuperado el 23 de 03 de 2014, de http://biocomp.cnb.csic.es/~roberto/II/Docencia/SI1/Clase/Reserved/Formas_Normales.pdf

Mora, E. (s.f.). Universidad de Cantabria. Recuperado el 23 de 03 de 2014, de http://personales.unican.es/zorrillm/PDFs/Docencia/BasesDatos/Formas%20Normales.pdf