METODOLOGIA

 

v  Área de investigación: Ing. En sistemas, Lic. En Informática, Taller de Investigación II,

 

v  Materia de investigación: Lenguaje de programación Visual Basic.

 

v  Cobertura del proyecto: Municipal

 

v  Campo de interés: Desarrollo  agropecuario

 

v  Tipo de Investigación: es una investigación aplicada

 

v  Universo de trabajo: Tomando como universo de trabajo el desarrollo agropecuario y considerando el gran desperdicio y manejo de agua para riego, se pretende fomentar el aprovechamiento eficiente de las mismas, para una mejor producción agropecuaria.

 

v  Fecha:  Enero de 2011 a junio de 2011

 

v  Lugar: El espinal, Oaxaca.

 

1.      Investigación preliminar

2.      Requerimientos del sistema

3.      Diseño del sistema

4.      Prueba del sistema

5.      Implementación y evaluación del sistema.

Es importante el ámbito estratégico de organización conocer bien el proceso estratégico y con ello plantear la metodología a seguir:

C   La investigación preliminar: En esta se recopila la mayor información necesaria posible para la elaboración del sistema, se considera que los lugares estratégicos para realizar dicha investigación son las oficinas del modulo de riego N° 5-A El espinal; para recabar la información de la superficie total de riego y del sistema operativo de los canales laterales y sublaterales.

C   Requerimientos del sistema: Teniendo  recopilada toda la información necesaria, se deberán revisar y estudiar todos los datos obtenidos y de éste obtener los requerimientos del sistema, Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar. Este sistema de riego funcionara en cualquier versión de Windows y distintas plataformas.

C   Diseño del sistema: El diseño del sistema es la tercera fase, en él, se elaborará el diseño lógico del sistema tomando en cuenta todos los datos recopilados, El objetivo del proceso de Diseño del Sistema de Información (DSI) es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información.

 

C   Prueba del sistema: Una vez realizado el diseño se podrá poner a prueba el nuevo sistema informático de riego con la finalidad de mejorar el manejo y control de agua en los canales de riego. Tiene como objetivo verificar el sistema para comprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse varios tipos distintos de pruebas en función de los objetivos de las mismas. Algunos tipos son pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad, etc. Este trabajo se centra en pruebas funcionales de aplicaciones con interfaces gráficas. . Toda prueba consta tradicionalmente de tres elementos: interacciones entre el sistema y la prueba, valores de prueba y resultados esperados. Los dos primeros elementos permiten realizar la prueba y el tercer elemento permite evaluar si la prueba se superó con éxito o no. Un proceso de pruebas consta generalmente de cuatro fases: la fase de diseño de pruebas, la fase de codificación, la fase de ejecución y la fase de análisis de los resultados. El objetivo de un proceso de generación de pruebas del sistema es desarrollar las dos primeras fases y obtener esos tres elementos a partir del modelo de requisitos del propio sistema bajo prueba. Dicho proceso toma como punto de partida los requisitos y, a partir de ellos genera los resultados y construye las pruebas.

 

C   Implementación y evaluación del sistema:

 

v  Implementación: Finalidad: Poner en marcha el sistema desarrollado, y someterlo a un proceso de evaluación. Durante la puesta en marcha y evaluación, el quipo de proyecto debe dirigir al usuario, finalmente hacer entrega al usuario para que comience su operación.

Evaluación y ajuste: El objetivo de este paso es evaluar los resultados de la operación, del nuevo sistema antes de ser entregado, se analizarán los errores detectados en la puesta en marcha. Dichos errores pueden ser de diseño y/o desarrollo, como así también salidas previstas que a pesar de no tener errores, no satisfacen a los usuarios.