Proyecto de Programación
sábado, 9 de agosto de 2014
REFERENCIA DEL AUTOR
Zambrano
Zambrano María Lourdes
Nació
en Manta Cantón Manta, el 12 de Mayo de 1993, realizó sus estudios primarios en
la Escuela Fiscal Simón Bolívar, sus estudios secundarios los realizó en la
Unidad Educativa Nacional “13 de Octubre”, obtuvo el título de bachiller en
Físico Matemático, actualmente cursa sus estudios superiores en la Escuela
Superior Politécnica Agropecuaria de Manabí Manuel Félix López, está en sexto
semestre de la carrera de Informática.
DICCIONARIO DE DATOS Y TABLAS DE DECISIÓN
INTRODUCCIÓN
Esta clase realizada por la Docente Hiraida Santana fue
la última clase del semestre que consistió en exponer sobre el diccionario de
datos y árboles y tablas de decisión.
DICCIONARIO DE DATOS
El diccionario de datos guarda y organiza los detalles
del Diagrama de Flujo de Datos. Es el segundo componente del análisis
estructurado. También se conoce como "DataRepository". Incluye el
contenido de los data flow (flujos de datos), los "data store", las entidades
externas y los procesos.
CONTENIDO DE UN
REGISTRO DEL DICCIONARIO
El diccionario tiene dos tipos de descripciones para el
flujo de datos del sistema, son los elementos datos y estructura de datos.
Elemento dato.
Son los bloques básicos para todos los demás datos del
sistema, por si mismos no le dan un significado suficiente al usuario. Se
agrupan para formar una estructura de datos.
Descripción.
Cada entrada en el diccionario consiste de un conjunto de
detalles que describen los datos utilizados o producidos por el sistema. Cada
uno está identificado con: Un nombre: para distinguir un dato de otro.
Descripción: indica lo que representa en el sistema. Alias: porque un dato
puede recibir varios nombres, dependiendo de quién uso este dato. Longitud:
porque es de importancia de saber la cantidad de espacio necesario para cada
dato. Valores de los datos: porque en algunos procesos solo son permitidos
valores muy específicos para los datos. Si los valores de los datos están
restringidos a un intervalo especifico, esto debe estar en la entrada del diccionario.
Estructura de datos.
Es un grupo de datos que están relacionados con otros y
que en conjunto describen un componente del sistema.
Descripción
Se construyen sobre cuatro relaciones de componentes. Se
pueden utilizar las siguientes combinaciones ya sea individualmente o en
conjunción con alguna otra
Relación secuencial: define los componentes que siempre se incluyen en una estructura
de datos.
Relación de selección: (uno u otro), define las alternativas para datos o
estructuras de datos incluidos en una estructura de datos.
Relación de iteración: (repetitiva), define la repetición de un componente.
Relación opcional: los datos pueden o no estar incluidos, o sea, una o ninguna
iteración.
Notación Los analistas usan
símbolos especiales con la finalidad de no usar demasiada cantidad de texto
para la descripción de las relaciones entre datos y mostrar con claridad las relaciones.
TABLAS DE DECISIÓN
Una tabla de decisión es una herramienta que sirve para
representar de manera más fácil la lógica de un problema cuando está es más o menos
complicada. Para ello se trata de identificar en el problema las acciones que
hay que ejecutar y las condiciones que se tienen que cumplir para ejecutar esas
acciones.
Partes de la Tabla
Conjunto de
condiciones:
Son las condiciones que intervienen en el problema.
Entrada de condiciones: Son las combinaciones posibles entre los valores de las
condiciones. SI, NO, DA IGUAL.
Conjunto de acciones:
Abarca todas las acciones que se tienen que ejecutar
cuando se cumplen un conjunto dado de condiciones.
Salida de ejecución:
Se determina cuándo se ejecuta cada acción.
La regla de decisión:
Es una combinación de un estado en la entrada de
condiciones y de una o más acciones
asociadas en la parte de la salida de acciones asociadas en la parte de la salida de acciones siendo N
el número de condiciones y considerándolas
como binarias (SI/NO) habrá un número máximo de 2 elevado a N reglas.
Cada regla equivale desde el parte de vista de algoritmos
a una estructura si…entonces…fin si, y en
cada momento solo se puede cumplir una
regla. Las tablas de decisión las podemos usar para controlar la lógica de control de un
algoritmo.
Utilidad
Permite representar la descripción de situaciones decisivas,
es decir, se representan las distintas alternativas, estados de la naturaleza y
las consecuencias.
Nos proporcionan una descripción completa, correcta,
clara y concisa de una situación que se resuelve por una decisión tomada en un
momento específico del tiempo.
COMO SE CONSTRUYE
1. Determinar las condiciones
2. Determinar las acciones posibles
3. Determinar las alternativas para cada condición
4. Calcular el máximo de columnas en la tabla de
decisión: se calcula multiplicando el número de alternativas de cada condición.
5. Armar una tabla de cuatro cuadrantes.
6. Completar la tabla completando con X todas las
acciones que debe ejecutarse con cada regla.
7. Combinar aquellas reglas en las que aparecen alternativas
de condiciones que no influye en el conjunto de acciones.
8. Verificar la tabla para eliminar situaciones
imposibles, contradictorias o redundantes. (Castellanos, L. 2007)
BIBLIOGRAFÍA:
Kendall,K ; Kendall,J. 2011. Analisis y diseño de
sistemas. Octava edición. Cap- 8. (Libro Digital.)
Castellanos, L. 2007. Árboles y tablas de desición. (En línea).
Formato PDF. Disponible en: https://luiscastellanos.files.wordpress.com/2007/03/arboles-y-tablas-decisiones-luis-castellanos.pdf
4.1 ANÁLISIS Y DISEÑO ESTRUCTURADO
INTRODUCCIÓN
Esta clase realizada por la Docente Hiraida Santana fue
sobre el siguiente tema del silabo el cual es el análisis y diseño estructurado;
este tema se vio un poco a fondo ya que la Docente nos mandó un trajo de
proyecto de curso en el cual debíamos realizar los niveles de DFD del 0, 1, 2.
Además, en la clase realizamos una práctica junto con la
Docente del nivel 0 orientado a nuestro proyecto.
DIAGRAMA DE
FLUJO DE DATOS
Muestran en forma visual sólo el flujo de datos entre los
distintos procesos, entidades externas y
almacenes que conforman un sistema. Cuando los analistas de sistemas indagan sobre
los requerimientos de información de los usuarios, deben ser capaces de
concebir la manera en que los datos
fluyen a través del sistema u
organización, los procesos que sufren estos datos y sus tipos de salidas.
(Zuluaga, L. 2008)
Los diagramas de flujo de datos son una herramienta de
representación del flujo de información. (Vargas, A. 2007)
ELEMENTOS DE UN
DFD
ENTIDAD EXTERNA
Persona, grupo de personas o unidad de negocio que
entrega y o recibe información.
PROCESO
Conjunto de actividades de negocio que explican que se
hace y como se llevan a cabo.
FLUJO DE DATOS
Señala el flujo de datos de una entidad externa a un proceso y viceversa, de un proceso a otro, y de un proceso a un almacén de datos y viceversa.
ALMACÉN DE DATOS
Lugar físico donde se almacenan los datos procesados o desde donde se recuperan
para apoyar un proceso. (Zuluaga, L. 2008)
COMO DESARROLLAR DFD:
He aquí unas cuantas reglas básicas a seguir:
1. El diagrama de flujo de datos debe tener por lo menos
un proceso y no debe haber objetos independientes o conectados a sí mismos.
2. Un proceso debe recibir por lo menos un flujo de datos
entrante y debe crear por lo menos un flujo de datos saliente.
3. Un almacén de datos debe estar conectado con por lo
menos un proceso.
4. Las entidades externas no se deben conectar entre sí.
Aunque se comunican en forma.
Creación del diagrama
de contexto
Con una metodología arriba-abajo para crear un diagrama
del movimiento de los datos, los diagramas avanzan de generales a específicos.
Aunque el primer diagrama ayuda al analista de sistemas a comprender el
movimiento de datos básico, su naturaleza general limita su utilidad. El
diagrama de contexto inicial debe ser una vista general que incluya las
entradas básicas, el sistema general y las salidas. Este diagrama será el más
general, una verdadera vista panorámica del movimiento de datos en el sistema y
la conceptualización más amplia posible del sistema.
El diagrama de contexto es el nivel más alto en un
diagrama de flujo de datos y contiene sólo un proceso, el cual representa a
todo el sistema. El proceso recibe el número cero. Todas las entidades externas
se muestran el diagrama de contexto, así como el flujo de datos principal que
entra y sale de ellas. El diagrama no contiene almacenes de datos y es bastante
simple de crear una vez que los analistas conocen las entidades externas y el flujo
de datos que entra y sale de ellas.
DIAGRAMA NIVEL 0
El Diagrama 0 es la expansión del diagrama de contexto;
puede incluir hasta nueve procesos. Si incluimos más procesos en este nivel
obtendremos un diagrama abarrotado de información que será difícil de
comprender. Cada proceso se enumera con un entero, por lo general empezando a
partir de la esquina superior izquierda del diagrama y avanzando hacia la
esquina inferior derecha. En el Diagrama 0 se incluyen los principales
almacenes de datos del sistema.
Creación de diagramas
hijos (niveles más detallados)
Cada proceso en el Diagrama 0 puede a su vez expandirse
para crear un diagrama hijo más detallado. Al proceso que se expande en el
Diagrama 0 se le conoce como el proceso padre, y al diagrama que resulta se le
conoce como el diagrama hijo. La regla principal para crear diagramas hijos es
el balanceo vertical; esta regla establece que un diagrama hijo no puede
producir salida o recibir entrada que el proceso padre no produzca o reciba
también. Todos los datos entrantes o salientes del proceso padre deben
mostrarse como entrantes o salientes en el diagrama hijo.
(Kendall,K ; Kendall,J. 2011)
CONCLUSIONES:
- Los diagramas de flujo de datos son muy importantes para el cliente para que entienda como es el flujo de datos entre los procesos.
- El realizar investigaciones se despejaron dudas con los niveles de los DFD.
BIBLIOGRAFÍA:
Kendall,K ; Kendall,J. 2011. Analisis y diseño de
sistemas. Octava edición. Cap- 7. (Libro Digital.)
Zuluaga, L. 2008. Diagrama de flujos d datos. (En línea).
Formato PDF. Disponible en: http://alayo.files.wordpress.com/2008/12/diagrama-de-flujo-de-datos2.pdf
Vargas, A. 2007. Análisis de sistemas. (En línea).
Formato PDF. Disponible en: http://www.cs.umss.edu.bo/doc/material/mat_gral_122/DFdatos.pdf
3.3 EL CICLO DE VIDA DE UNA BASE DE DATOS
INTRODUCCIÓN
Esta clase realizada por la Docente Hiraida Santana fue
sobre el siguiente tema del silabo el cual es el ciclo de vida de una base de
datos; este tema tiene varias etapas a realizar las cuales fueron explicadas
por la Docente.
Esta clase fue teórica,
donde los alumnos aportaban sobre el tema con lluvias de ideas y mucha
información.
EL CICLO DE VIDA
DE UNA BASE DE DATOS
Las etapas del ciclo de vida de una aplicación de bases
de datos son las siguientes:
1. Planificación del proyecto.
2. Definición del sistema.
3. Recolección y análisis de los requisitos.
4. Diseño de la base de datos.
5. Selección del SGBD.
6. Diseño de la aplicación.
7. Prototipado.
8. Implementación.
9. Conversión y carga de datos.
10. Prueba.
11. Mantenimiento.
1. Planificación del proyecto. Esta etapa conlleva la
planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de
la manera más eficiente.
2. Definición del sistema. En esta etapa se especifica el
ámbito y los límites de la aplicación de bases de datos, así como con qué otros
sistemas interactúa. También hay que determinar quiénes son los usuarios y las
áreas de aplicación.
3. Recolección y análisis de los requisitos. En esta
etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de
aplicación.
4. Diseño de la base de datos. Esta etapa consta de tres
fases: diseño conceptual, diseño lógico y diseño físico de la base de datos.
5. Selección del SGBD. Si
no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger
un SGBD que sea adecuado para el sistema
de información.
6. Diseño de la aplicación. En esta etapa se diseñan los
programas de aplicación que usarán y procesarán la base de datos.
7. Prototipado. Un prototipo es un modelo de trabajo de
las aplicaciones del Sistema. Este proceso permite
que quienes diseñan e implementan el sistema sepan si han interpretado
correctamente los requisitos de los usuarios.
8. Implementación. La implementación de la base de datos
se realiza mediante las sentencias del
lenguaje de definición de datos (LDD) del SGBD escogido.
9. Conversión y carga de datos. Esta etapa es necesaria cuando
se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan
desde el sistema viejo al nuevo directamente
10. Prueba. En esta etapa se prueba y valida el sistema
con los requisitos especificados por los
usuarios.
11. Mantenimiento. Una
vez que el sistema está completamente implementado y probado, se pone en
marcha. El sistema está ahora en la fase de mantenimiento. (UNIVERSIDAD
AUTÓNOMA DEL ESTADO DE HIDALGO. 2011)
CONCLUSIONES:
- Los ciclos de una base de datos es importantes saber todas estas etapas en las que se subdivide.
- El investigar sobre el tema ayudo a informarse más sobre los ciclos de vida de la base de datos.
BIBLIOGRAFÍA:
UNIVERSIDAD AUTÓNOMA DEL
ESTADO DE HIDALGO. 2011. Ciclo de vida de un sitema de base de datos. (En línea).
Formato PDF. Disponible en: http://www.uaeh.edu.mx/docencia/P_Presentaciones/huejutla/sistemas/estructura_datos/ciclo_vida.pdf
Triana, A. 2010. Ciclo de vida de una base de datos. (En línea).
Formato HTML. Disponible en: http://es.slideshare.net/atrianaguzman/ciclo-de-vida-de-una-base-de-datos
3.2 MODELOS DE CICLO DE VIDA
INTRODUCCIÓN
Esta clase realizada por la Docente Hiraida Santana y exposiciones
de mis compañeros fue sobre el siguiente tema del silabo el cual es modelos de
ciclos de vida; estas exposiciones fueron muy interesantes y además compartimos
criterios sobre cada uno de los métodos. El objetivo de la clase fue que los
estudiantes aprendan el mejor método para desarrollo del proyecto.
Esta clase fue teórica
práctica; en esta se realizó prácticas y ejercicios de los modelos de ciclos de
vida al final de la clase realizamos un resumen de todo esto.
MODELO DE PROCESO PRESCRIPTIVO
Los modelos de proceso prescriptivo fueron propuestos
originalmente para poner orden en el caos del desarrollo de software.
MODELO DE LA
CASCADA
El modelo de la cascada, a veces llamado ciclo de vida
clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del
software, que comienza con la especificación de los requerimientos por parte
del cliente y avanza a través de planeación, modelado, construcción y
despliegue, para concluir con el apoyo del software terminado. (Pressman,R. 2010)
Ventajas
- El modelo de cascada es el modelo más antiguo y más ampliamente utilizado en el campo de desarrollo de software.
- Una gran ventaja del modelo de cascada es que la documentación se produce en cada etapa del desarrollo del modelo de cascada. Esto hace que la comprensión del producto diseñar procedimiento más sencillo.
- Después de cada etapa importante de la codificación de software, las pruebas se realizan para comprobar el correcto funcionamiento del código
Desventajas
- Cualquier cambio que se menciona en el medio puede causar mucha confusión
- Los pequeños cambios o errores que surgen en el software completo pueden causar mucho problema
- La mayor desventaja del modelo de cascada es que hasta la etapa final del ciclo de desarrollo se ha completado, un modelo de trabajo del software no está en las manos del cliente. (Rojas,M. 2010)
MODELOS DE PROCESO INCREMENTAL
El modelo incremental combina elementos de los flujos de
proceso lineal y paralelo estudiados. El modelo incremental aplica secuencias
lineales en forma escalonada a medida que avanza el calendario de actividades.
Cada secuencia lineal produce “incrementos” de software susceptibles de
entregarse de manera parecida a los incrementos producidos en un flujo de
proceso evolutivo.
Cuando se utiliza un modelo incremental, es frecuente que
el primer incremento sea el producto fundamental. Es decir, se abordan los
requerimientos básicos, pero no se proporcionan muchas características
suplementarias. (Pressman,R. 2010)
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.
- El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
Desventajas:
- El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos.
- Requiere de mucha planeación, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto. (Calero, W. 2010)
- Wynnie Calero (Estudiante de Ingeniería en Sistemas de Información de la Universidad Politécnica de Nicaragua(UPOLI))2010
MODELOS DE PROCESO EVOLUTIVO
Los modelos evolutivos son iterativos. Se caracterizan por
la manera en la que permiten desarrollar versiones cada vez más completas del
software.
HACER PROTOTIPOS
El paradigma de hacer prototipos comienza con
comunicación. Usted se reúne con otros participantes para definir los objetivos
generales del software, identifica cualesquiera requerimientos que conozca y
detecta las áreas en las que es imprescindible una mayor definición.
El ideal es que el prototipo sirva como mecanismo para
identificar los requerimientos del software. Si va a construirse un prototipo,
pueden utilizarse fragmentos de programas existentes o aplicar herramientas que
permitan generar rápidamente programas que funcionen.
EL MODELO
ESPIRAL
Modelo espiral es un modelo evolutivo del proceso del
software y se acopla con la naturaleza iterativa de hacer prototipos con los
aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial para
hacer un desarrollo rápido de versiones cada vez más completas.
Con el empleo del modelo espiral, el software se
desarrolla en una serie de entregas evolutivas. Durante las primeras
iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones
posteriores se producen versiones cada vez más completas del sistema cuya
ingeniería se está haciendo.
MODELOS
CONCURRENTES
El modelo de desarrollo concurrente, en ocasiones llamado
ingeniería concurrente, permite que un equipo de software represente elementos
iterativos y concurrentes de cualquiera de los modelos de proceso descritos.
Si el cliente indica que deben hacerse cambios en los
requerimientos, la actividad de modelado pasa del estado en desarrollo al de cambios
en espera. (Pressman,R. 2010)
MODELO DE
PROCESO ESPECIALIZADO
DESARROLLO BASADO EN COMPONENTES
Variación del modelo en espiral donde las aplicaciones se
construyen usando componentes sw previamente empaquetados llamados clases.
MÉTODOS FORMALES
Notación matemática rigurosa utilizada para especificar,
diseñar y verificar sistemas basados en computadoras.
PROGRAMACIÓN ORIENTADA A ASPECTOS
Provee un proceso para definir, especificar, diseñar y
construir aspectos de sw como interfaces, seguridad y gestión de memoria que
impactan varias partes del sistema en desarrollo. (Pérez, N.2011)
CONCLUSIONES:
- Los modelos de ciclo de vida son fundamentales para llevar una organización del proyecto.
- Unos de los modelos según más utilizados es el de cascada pero ya es obsoleto así se recomienda que se utilice los modelos evolutivos, aun así el utilizado es el método Scrum.
- Esta clase ayudo a a la realización del proyecto de año del semestre.
BIBLIOGRAFÍA:
Rojas,M. 2010. Ciclos de vida modelo de cascada. (En línea).
Formato HTML. Disponible en: http://spanishpmo.com/index.php/ciclos-de-vida-modelo-de-cascada/
Calero, W. 2010.Ciclos de
vida modelo incremental. (En línea). Formato HTML. Disponible en: http://ingenieraupoliana.blogspot.mx/2010/10/modelo-incremental.html
Pressman, R., Ingeniería de software un enfoque práctico,
séptima edición. Editorial McGrawHill, México, año 2010 (Libro digital). Capítulo 2
Pérez, N.2011. Modelos de procesos. (En línea). Formato
PDF. Disponible en: http://sistinfii.files.wordpress.com/2011/03/siii2011-02-modelos-de-proceso.pdf
Suscribirse a:
Entradas (Atom)