Tabulación de Datos

Resumen Aprender a Investigar

 

Introducción

El documento Aprender a Investigar muestra métodos, elementos y técnicas que se deben incluir en el proceso de investigación científica, en este proceso se debe tener un espíritu de curiosidad, indagación y crítica, tener conocimiento del área específica en la cual se va a trabajar, hay que tener muy en cuenta que para aprender ha investigar se de una manera concreta y vivencial se debe realizar investigaciones no importa si son cortas.

Este documento esta diseñado para estudiantes con el fin de prepararlos como profesionales e investigadores y se logre resolver problemas de conocimiento, aplicando la lógica utilizando instrumentos básicos. Dentro de una investigación se debe desarrollar habilidades como la comprensión lectora, matemáticas, geometría, historia.

Dentro de la Investigación se encuentra niveles, entre ellos se encuentran los siguientes:

Nivel 1	Epistemológico
Nivel 2	Teórico
Nivel 3	Metodológico
Nivel 4	Técnico

 

Información primaria y secundaria

La recolección de datos se somete a análisis, clasificación e interpretación muy cuidadosa para establecer hipótesis y el enfoque de la investigación, a la hora de la recolección de información encontramos:

Información Primaria: El investigador recoge directamente a través de un contacto inmediato con su objeto de análisis.

Información Secundaria: Es aquella que el investigador recoge información a partir de investigaciones ya hechas por otros investigadores.

 

Unidades, variables, valores y constructos

Es muy importante tener en cuenta que los datos tienen sus componentes:

·         La unidad de Análisis: Elemento mínimo de estudio, eje, en las Ciencias  Sociales la unidad mínima podría ser, el obrero, la empresa, las naciones etc.

 

·         La variable o variables:

·         El valor:

Entidad- Relación

 Entidad- Relación

Se aplica a Base de datos, es una especie de diagrama que nos muestra cómo debemos diseñar una base de datos.(¿Cómo se relacionan las entidades en la base de datos?)

El diagrama ER esta conformado por:

• Entidades
• Atributos
• Relaciones
• Tipos de relaciones

Una entidad es un objeto que se representa del mundo real, y puede ser:

• Objeto con existencia física (se pueden tocar, ver..)
• Objeto con existencia conceptual (no se puede palpar o ver pero sabemos que está presente ahí eje: puesto de trabajo, asignatura..)

Las entidades de objetos con existencia física se denominan Entidades Concretas.

Las entidades de objetos con existencia conceptual se denominan Entidades Abstractas.

Las entidades se representan mediante un rectángulo

Los Atributos son la propiedad o característica que describe a una entidad. Se representan mediante un ovalo. Una entidad puede tener varios atributos y un atributo varios registros, existen atributos claves que se define como único, que es irrepetible eje: un número de ID.

 En el modelo entidad relación, nosotros trabajamos con entidades (que en el futuro serán nuestras tablas).

Estas entidades suelen estar relacionadas entre ellas, esta simbología representa una relación.

En este punto es donde nace la cardinalidad.

Es un termino que se utiliza en las bases de datos, para referirnos a la cantidad de veces en que nuestras entidades se relacionan. La cardinalidad, identifica como están relacionadas nuestras entidades para posteriormente crear la base de datos según el tipo de cardinalidad que sea.

Brochure

 Brochure

Es un estilo de folleto que se puede utilizar para presentar productos, servicios y valores de una entidad o empresa con el fin de atraer clientes o usuarios que puedan interesarse en el contenido, es una forma muy llamativa a nivel visual para el público.

Ciclos de vida del desarrollo de software

 Ciclos de vida del desarrollo de software

Los ciclos de vida del desarrollo de software son los pasos que se siguen para crear un software desde su concepción hasta su entrega final. Es como una receta para hacer un pastel, pero en lugar de harina, azúcar y huevos, usamos requerimientos, diseño, codificación y pruebas. Algunas actividades genéricas del ciclo de vida del software son : especificación, desarrollo, validación, y evolución.

Existen modelos de ciclo de vida del desarrollo del software los cuales establecen y muestran las diferentes fases y etapas por las que pasa un producto software desde su inicio hasta llegar a la etapa final. Algunos de los modelos mas conocidos son los siguientes:

Modelo en Cascada: En este modelo intervienen la fase de los requisitos, diseño, implementación, pruebas y mantenimiento, en este modelo no se puede  seguir a una fase sin haber culminado la anterior (desarrollo secuencial que fluye hacia abajo)

Modelo en V: En este modelo se hace las respectivas mejoras frente al modelo en cascada, puesto que establece que las pruebas deben realizarse mucho antes, no en la etapa final, para evitar mayores inconvenientes ni retrasos. Los técnicos de pruebas necesitan trabajar con los desarrolladores y analistas para lograr producir un entregable de pruebas.

(V= Validación y Verificación)

Modelo Interactivo: Es un modelo derivado del ciclo de vida en cascada, por medio de esta etapa se busca disminuir los errores que se pueden obtener por la recogida de requisitos y cambios que se presenten por parte del usuario.

Modelo de desarrollo Incremental: Se presenta por medio de secuencias lineales que van escalando junto al calendario y cada secuencia conlleva a un incremento en cuanto al desarrollo del software. Este modelo entrega un producto operativo con cada incremento.

Modelo en Espiral: Desarrollado por Barry Boehm en 1985, este modelo combina modelos en cascada y prototipado, es en forma de un espiral que comienza en el centro y se expande hacia afuera, cada vuelta representa una interación o fase del proyecto.

Modelo de prototipos: Comienza con la recolección de requisitos, el desarrollador y el cliente definen los objetivos globales para el software, con esto se abre paso al diseño que serán visibles para el cliente o usuario, ya con el diseño establecido se puede plantear un prototipo que es evaluado por el cliente o el usuario con el fin de refinar o pulir los requisitos del software a desarrollar.