PARTE III - Creacion de Un Proyecto

7/27/2019 PARTE III - Creacion de Un Proyecto

http://slidepdf.com/reader/full/parte-iii-creacion-de-un-proyecto 1/9

[VISUAL FOXPRO BASICO] IDSYSTEMS 2013

PARTE III – Creacion de un proyecto Página 1

PARTE III – Creacion de un proyecto

1. Analisis de Sistemas

Todo en la vida tiene un principio , un punto en el que los detalles están mal definidos .El Desarrollo de

aplicaciones no es diferente . Todos los proyectos tienen un principio , las acciones que realizamos y las

decisiones que tomamos al principio será fuertemente influidas en el resto del proyecto . En este

capítulo vamos a ver en el inicio de proyectos de aplicación y encontrar algunas ideas sobre cómo

hacer que trabajen para nosotros y no contra nosotros. Este capítulo no es un tratado sobre el análisis

orientado a objetos y diseño, sino más bien una discusión pragmática de algunas ideas que pueden

ayudar a que el proceso sea más fructífero.

Averiguar lo que hay que hacer

La primera tarea es conseguir una pista! Obtener un poco de idea de lo que trata el proyecto . Esto

puede parecer obvio , pero no lo es. Hay dos conjuntos de ideas sobre el proyecto : el desarrollador y

el del cliente. Estas dos opiniones son rara vez lo mismo.

Somos desarrolladores, asi que podemos entender lo que necesita el desarrollador para obtener

detalles acerca de los requisitos funcionales, cuántas formas habrá , cuántos tablas se necesitan, cómo

las tablas se relacionan entre sí , y todas las otras cosas que necesitan saber los desarrolladores.

Sin embargo , los clientes a menudo ven el proyecto de una manera muy diferente. Un cliente tiene undolor! Algo está mal en sus negocios. Tal vez un competidor que está latiendo en el mercado, o que

están perdiendo inventario a través de la contracción y no puede rastrearlo . Tal vez el costo de ventas

es muy alto y los beneficios están siendo mermados. O incluso puede ser que la empresa está

creciendo a un ritmo muy rápido y se detecta una pérdida de control sobre sus costos.

Sea lo que sea , el cliente tiene un problema que les está causando el dolor. No nos están contratando

para construir un gran software, nos están contratando para aliviar su dolor. Si queremos tener éxito

con el proyecto, a continuación, hay que centrarse en aliviar el dolor del paciente . Para ello debemos

entender el dolor y de donde proviene.

¿Qué sabemos ?

Sabemos como construir aplicaciones. Sabemos cómo hacer que las computadoras canten . Podemos

modificar el último nanosegundo de las consultas SQL. Sabemos cómo proteger la integridad

referencial y hacer cumplir las restricciones de dominio. Podemos validar los campos , filas y tablas ,

incluso tablas enteras.





Todas estas cosas son importantes para el éxito del proyecto , sin embargo , estamos totalmente fuera

de base pensando que el cliente se preocupa por estos temas en absoluto. El cliente se preocupa por

encontrar la ruta más corta para el alivio del dolor .

¿Qué sabe el cliente?

El cliente sabe que están en el dolor , que puede o no puede saber la causa exacta de su dolor. Ellos

saben cómo manejar su negocio . Ellos saben su mercado y sus clientes. Ellos saben lo que sus clientes

quieren. Ellos saben cómo construir sus productos o prestar sus servicios.

El cliente es humano y le gusta sentirse importante e inteligente. Si empezamos forzándolos a un

análisis estructurado de sus negocios, los estamos poniendo en una situación incómoda donde no

conocen la jerga y están familiarizados con los procesos. La naturaleza humana dice que van a hacer

todo lo posible para acortar esa experiencia tanto como les sea posible.

En esto radica el conflicto

Se nos ha dicho una y otra vez que el análisis y el diseño son fundamentales para una aplicación sólida.

Esto es simplemente una verdad de la naturaleza . También sabemos que los clientes ven la fases de

análisis y diseño como la pérdida de tiempo . Ellos lo ven de esa manera porque nada nuevo está

apareciendo en sus equipos. También lo ven así porque el proceso es una pesadilla para ellos. Se

sienten inadecuados y poco inteligentes.

¿Qué podemos hacer para cambiar esto? ¿Cómo podemos conseguir que el cliente compre en un buen

análisis y diseño ? Podemos hacerlo no diciendoles lo que estamos haciendo, saltandonos la jerga y las

formas elegantes y listas de control ( oh , las vamos a utilizar , pero no frente al cliente , al menos no alprincipio).

Comienza el análisis diciendo algo como : "Este sistema va a tener que trabajar bien dentro de su

negocio y no soy ni de lejos lo suficientemente bien informado sobre su negocio para lograr eso.

Necesitaré su ayuda y su experiencia para hacer frente a la parte comercial del proyecto. ¿Puede

describir la naturaleza de su negocio para mí ? "

Deja que estas primeras conversaciones este suelto y descriptivo del negocio total del cliente. Tome

notas. Cuando se retire de estas primeras reuniones analize sus notas. A continuación, escriba unas

pocas páginas de resumen, que describa lo que usted entiende . Regrese con el cliente y pidale quelean el resumen y le haga saber lo que tiene correcto y, sobre todo, lo que tiene incorrecto.

Después de uno o dos entrevistas, puede comenzar con los checklists (listas de control) y otras graficas

y diagramas. Presente estos documentos lentamente y explique su estructura. Trabaje lentamente en

los detalles de la información contenida en los documentos.





Siguiendo estas ideas desde el principio , usted estará en mejores condiciones para conseguir que el

cliente compre en la fase de análisis ( sin que ellos siquiera sepan que es lo que hicieron ) y es probable

que obtenga mejor informacion y mas completa.

Tener un plan

Una vez que el análisis es bastante completo y tiene una buena y sólida base de la comprensión tanto

de los requisitos del proyecto y el negocio en general, usted puede comenzar a hacer un plan para el

proyecto. El diseño inicial es ese plan.

Usted no consideraría salir de unas vacaciones de dos semanas sin tener la menor idea de dónde iba o

cómo llegar allí. Unas vacaciones que comienza de esa manera seguramente va a tener problemas. No,

usted selecciona un destino o dos y luego revisar los mapas para planificar la mejor ruta. Puede variar

de su plan durante las vacaciones , pero usted no empezaria sin un plan.

El desarrollo del proyecto es de la misma manera . Usted no quiere comenzar sin un plan - una especiede mapa de hacia dónde te diriges y cómo va a llegar allí. Sin un plan, lo más probable es viajar por

muchos callejones sin salida y tiene que tirar el trabajo y empezar de nuevo .

Tener un diseño no significa que usted no lo altere durante el desarrollo , que sin duda lo hará. Usted

podrá descubrir información o aprender algo nuevo acerca de las herramientas que hará que usted

altere su plan. Eso está bien . Incluso tiene un nombre : se llama desarrollo iterativo .

Su plan debe incluir diseños de clase para los objetos que se va a utilizar , el diseño de los datos de las

relaciones persistentes definidos , diseño de interfaz de usuario , diseño de informes , y otras cosas .

No hay ninguna ley que diga que no puede usar Visual FoxPro para lograr estos diseños. Usted puede

utilizar el diseñador de formularios para diseñar las formas y la interfaz de usuario, el diseño de basede datos para diseñar las tablas y relaciones, y el diseñador de informes para diseñar los informes. El

problema es que usted no quiere pasar mucho tiempo de llenado en los detalles en esta etapa. ¿Por

qué no ? Porque las cosas van a cambiar. Es mucho más fácil que hacer de nuevo un formulario que

tiene poco o nada de código en él , que sentir los calambres de tirar dos días de trabajo en una forma

que no encaja .

El desarrollo iterativo

Los procesos de análisis , diseño e implementación casi siempre se muestran como una línea de

tiempo, donde un proceso no comienza hasta que se complete la anterior . No es así como funciona enel mundo real. Analizamos la información hasta que tengamos un grado de comprensión , y luego

comenzamos a diseñar la aplicación . A menudo, durante el diseño, surgirán preguntas que nos hacen

volver al análisis y obtener las respuestas .





Cuando el diseño está bastante bien distribuido, comenzamos la construcción de los componentes que

formarán parte de la aplicación. Este proceso , inevitablemente, va a descubrir debilidades , omisiones

o errores simples en nuestro diseño , que nos hacen parar y volver al diseño para modificarlo .

El único pecado mortal para cualquier desarrollador es el orgullo de la autoría. El orgullo de la autoría

nos hará resistir desechar algo que no está del todo bien . Vamos a torcer , hacer palanca , el sudor , elmartillo , apretar, empujar, tirar , doblar , eje y mutilar a esa cosa para tratar de conseguir que

funcione . Cuanto más tiempo le ganamos en él, mayor será el grado de orgullo de la autoría y la más

difícil será para finalmente dejar ir, y empezar de nuevo.

Cada vez que usted se encuentra aún considerando remotamente empezar algo más , recuerde esto:

nunca va a ser más fácil que empezar de nuevo de lo que es ahora mismo , sino que sólo se hacen más

difíciles .

La aplicación

Una aplicación es mayor que la suma de sus partes. El buen desarrollo de aplicaciones requiere la

apreciación y la comprensión de la idea de los servicios de aplicación y asegurar que cada

componente está disponible para el resto del sistema .

Formas u objetos creados con un propósito específico hacen gran parte del "trabajo" real de una

aplicación. Es posible llevar a cabo una tarea significativa mediante la ejecución de un formulario desde

la ventana de comandos o creando una instancia de un objeto y llamar a sus métodos . Sin embargo,

esto no demuestra el funcionamiento de una aplicación.

Una aplicación necesita para exponer toda la funcionalidad del sistema a través de una interfaz de

usuario totalmente integrado que aborda muchos más problemas que simplemente aislando el usuariodesde el comando DO FORM .

Servicios a nivel de sistema

Cada componente de una aplicación proporciona servicios al usuario o a otro componente de la

aplicación - o alguna combinación de ambos. Un formulario en una aplicación de base de datos (

asumiendo que es visible) ofrece un servicio a los usuarios, que les permite ingresar, ver o alterar los

datos almacenados en la base de datos . Un botón de comando en esa forma también proporciona un

servicio que permite a los usuarios comunicar sus deseos, y proporciona un servicio al resto del

formulario , pasando a lo largo de la entrada del usuario con el método apropiado. Un menú sirveigualmente la necesidad del usuario para poner en marcha una forma particular , y puede llevar a cabo

ese deseo de pasarlo a un gestor de formularios .

Existen algunos componentes sólo para proporcionar a nivel de sistema: son los servicios - que su

responsabilidad es gestionar o facilitar algún aspecto de la aplicación interna . Un método de un

formulario puede prestar un servicio a la forma de deshabilitar el botón Guardar hasta que el usuario

ha modificado el registro actual.





Servicios de nivel de sistema pueden incluir algunas o todas de las siguientes funciones . Esta lista no es

de ninguna manera exhaustiva . Las aplicaciones individuales pueden requerir servicios adicionales , y

usted puede decidir proporcionar o servicios puede necesitar una aplicación particular - adicionales a

nivel de sistema .

El lanzamiento de la aplicación. " Comenzando " del proceso de establecimiento de todo el

recorrido , la carga de las bibliotecas de clases , archivos y bibliotecas de tiempo de ejecución

de procedimientos , a partir del menú u otro lanzador componente , la emisión de los " eventos

de lectura ", y así sucesivamente.

Identificación del usuario y la seguridad. Restringir o permitir el acceso al sistema o ciertas

partes del sistema , y hacer que la identidad del usuario actual a nivel global disponibles para el

sistema .

Gestion de formas . Limitación de las instancias de ciertas formas , crear instancias de las barrasde herramientas es necesario, cierre las formas mediante programación , la organización de las

formas en el escritorio del usuario, y la coordinación de las formas activas de las barras de

herramientas , menús y otros elementos de la interfaz .

Gestión de menús. Encapsulación de código necesario para implementar menú de

comportamiento dinámico , tales como cambio de opciones de menú, adición o eliminación de

cuadros de menú o barras de menús , y así sucesivamente .

Gestion de Informes. Encapsular los procesos de información en un solo componente para

facilitar el mantenimiento (por el promotor) y el acceso ( para el usuario) .

Guardado y restablecimiento de las preferencias del usuario . Tamaños formulario , botones

de la barra , los arreglos de red , los valores de búsqueda por defecto , etc .

Configuración global. Configuración de todo el sistema para determinar el comportamiento por

defecto del sistema , configuraciones y suposiciones, incluyendo la red y el diseño de

accionamiento , encauzamiento y reglas de negocio.

El manejo de errores . Informar a los usuarios de las condiciones de error inesperados , y la

información de error de registro para la depuración y solución de problemas .

Servicios no especificados en otra parte . Establecer parámetros específicos del entorno ( SET

hablar , SET DELETED , SET BARRA DE ESTADO hasta la saciedad ) , la remoción y reparación

(para beneficio de los desarrolladores durante el desarrollo ) en el menú del sistema y las barras

de herramientas , así como otros servicios que sean necesarios.





Pruebe y depure secciones de código a medida que desarrolla el programa. Compruebe que elcódigo hace lo que quiere que haga. La depuración es el proceso de encontrar y solucionar

problemas que impiden que el código se ejecute correctamente.

Perfeccione los datos y el almacenamiento de datos para facilitar la manipulación de estos datos

a través del código del programa. Esto suele implicar estructurar las tablas de forma adecuada.

Definir el problema

Antes de poder resolver un problema, debe formularlo claramente. Algunas veces, si ajusta la

formulación del problema podrá ver más opciones para resolverlo.

Suponga que obtiene muchos datos de distintos orígenes. Si bien la mayoría de los datos son

estrictamente numéricos, algunos valores contienen guiones y espacios en blanco además de números.

Suponga que quiere eliminar todos los espacios en blanco y los guiones de dichos campos y guardar losdatos numéricos.

En lugar de intentar eliminar los espacios en blanco y los guiones de los datos originales, podríaformular el objetivo del programa como:

Objetivo

Reemplazar los valores existentes de un campo por otros valores que contengan todo lo que contenían

los valores originales, excepto los espacios en blanco y los guiones. Esta formulación evita la dificultad

que supone manipular una cadena de caracteres cuya longitud sigue cambiando a medida que trabaja conella.

Checar. McGrawHill Manual del programador parte 01 cap 1 al 4. Pagina 14

No comentaremos mas acerca del Analisis de Sistemas, que es un tema muy extenso dentro del

desarrollo de aplicaciones, pero si insistiremos que a la mayor brevedad consulte un libro sobre este

tema ya que le dara una perspectiva muy amplia en el desarrollo de las aplicaciones.

Desarrollo de Bases de Datos

El Desarrollo o creacion de las bases de datos, tambien es un tema por si mismo para uno o varios

libros. Ya que los conceptos de bases de datos, relaciones, normalizacion, tipos de bases de datos es la

base principal para el desarrollo de aplicaciones empresariales primordialmente.

Todo sistema, despues de su respectivo analisis, comienza con el diseño de la base de datos. Es decir,

que informacion necesitamos almacenar, procesar y presentar. Comenzamos con los datos mas basicos

según el tipo de sistema. Creamos las tablas con estos datos (campos) y les asignamos el tipo de dato





prototipo pero en algunos casos una aplicación de produccion puede estar realizada enteramente en

uno de ellos.

PARTE III - Creacion de Un Proyecto

Documents

Transcript of PARTE III - Creacion de Un Proyecto