sábado, 9 de agosto de 2014

CARATULA



ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ
 MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA


                 SEMESTRE SEXTO                             PERÍODO MAR./2014-AGO./2014



PROYECTO DE PROGRAMACIÓN


AUTORA:

ZAMBRANO ZAMBRANO MARÍA LOURDES


CATEDRÁTICA:

ING. HIRAIDA SANTANA.




MISIÓN

Formación de profesionales íntegros que conjuguen ciencia, tecnología y valores en su accionar, comprometidos con la sociedad en el manejo adecuado de programas y herramientas computacionales de última generación.


VISIÓN

Ser referente en la formación de profesionales de prestigio en el desarrollo de aplicaciones  informáticas y soluciones de hardware

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.


DIAGRAMA PADRE (SUPERIOR)




(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