Ejercicio 1
¿A que lado de la celda se alinea por defecto un texto? ¿Y una fecha?
Si se introduce el dato 16.259,59 ¿dónde se alineará? ¿Y si se introduce el dato 16 259,59?
¿Qué tipo de dato es 6/95? ¿Y el dato 16 6/95?
Si el texto introducido en una celda no cabe en ella por ser más largo y dos celdas a la derecha de la misma hay introducido un dato, ¿dónde se visualizará el texto? ¿qué celdas lo contienen?
Al introducir una fórmula en una celda, ésta muestra el resultado de la misma, ¿cómo se puede observar la sintaxis de la fórmula?
¿El dato (19) y el -19 son iguales?
¿Se interpreta igual el valor 1 1/2 que el valor 1,5? ¿Y el valor 1/2 al valor 0,5?
Ejercicio 2
¿Son correctas las siguientes relaciones?
Fórmula Resultado o equivalencia
=6+10/2 El resultado es 8.
=12-10*2 El resultado es -8
=4+6^2 El resultado es 100
=2*5^2+10 Es equivalente a 60
=25*2-4+3 Es equivalente a 25
Fórmulas con fechas
="31/10"-"16-8-98" Calcula el número de días que transcurren entre el 16-8-98 y el 31-10-99.
="5-12"+15 Proporciona la fecha 20 de diciembre del año en curso.
Ejercicio 3
Crear la tabla que muestra la figura, siendo los datos que contiene de tipo texto y número. Una vez creada la tabla introducir en la columna Totales la fórmula que sume, para cada producto, los costes de los tres meses.
(Tabla en TABLERO)
Una vez completada la tabla, modificar los datos que contienen las celdas de tipo número. Observar que los resultados de las fórmulas irán cambiando según se realicen las modificaciones en las celdas de las cuales dependen. Las fórmulas se actualizan automáticamente y en tiempo real.
jueves, 24 de junio de 2010
viernes, 21 de mayo de 2010
Montar un video en Flash
Debe tener el video grabado, tambien sirve en formato .FLV
Pasos a seguir:
Archivo
Importar
Importar Video
(Seleccionamos) En el equipo
Examinar... (Buscamos la ruta del Video)
Siguiente
(Seleccionamos) Flujo de Flash Video Streaming Service
Siguiente
Aspecto (Aqui podemos seleccionar el tipo de reproductor y tamaño que deseamos)
Siguiente
Finalizar
Nota: Grabar el archivo
Pasos a seguir:
Archivo
Importar
Importar Video
(Seleccionamos) En el equipo
Examinar... (Buscamos la ruta del Video)
Siguiente
(Seleccionamos) Flujo de Flash Video Streaming Service
Siguiente
Aspecto (Aqui podemos seleccionar el tipo de reproductor y tamaño que deseamos)
Siguiente
Finalizar
Nota: Grabar el archivo
Comando para unir dos peliculas en flash
Pasos a seguir:
Acciones
Navegador/Red
Loadmovie
Nota: Puede copiar esta instrucción cambiando la ruta de su pelicula en .SWF
on(release){
loadmovie("D:\ Templates para Blog\ dos.swf", 0)
}
Acciones
Navegador/Red
Loadmovie
Nota: Puede copiar esta instrucción cambiando la ruta de su pelicula en .SWF
on(release){
loadmovie("D:\ Templates para Blog\ dos.swf", 0)
}
lunes, 12 de abril de 2010
miércoles, 24 de febrero de 2010
Documentación del Programa
Describimos los aspectos claves para el desarrollo de una buena documentación del programa a entregar al cliente.
Por Sara Alvarez
Publicado: 06/7/06
La documentación de los programas es un aspecto sumamente importante, tanto en el desarrollo de la aplicación como en el mantenimiento de la misma. Mucha gente no hace este parte del desarrollo y no se da cuenta de que pierde la posibilidad de la reutilización de parte del programa en otras aplicaciones, sin necesidad de conocerse el código al dedillo.
La documentación de un programa empieza a la vez que la construcción del mismo y finaliza justo antes de la entrega del programa o aplicación al cliente. Así mismo, la documentación que se entrega al cliente tendrá que coincidir con la versión final de los programas que componen la aplicación.
Una vez concluido el programa, los documentos que se deben entregar son una guía técnica, una guía de uso y de instalación.
Tipos de documentación
La documentación que se entrega al cliente se divide claramente en dos categorías, interna y externa:
- Interna: Es aquella que se crea en el mismo código, ya puede ser en forma de comentarios o de archivos de información dentro de la aplicación.
- Externa: Es aquella que se escribe en cuadernos o libros, totalmente ajena a la aplicación en si. Dentro de esta categoría también se encuentra la ayuda electrónica.
En la guía técnica o manual técnico se reflejan el diseño del proyecto, la codificación de la aplicación y las pruebas realizadas para su correcto funcionamiento. Generalmente este documento esta diseñado para personas con conocimientos de informática, generalmente programadores.
El principal objetivo es el de facilitar el desarrollo, corrección y futuro mantenimiento de la aplicación de una forma rápida y fácil.
Esta guía esta compuesta por tres apartados claramente diferenciados:
- Cuaderno de carga: Es donde queda reflejada la solución o diseño de la aplicación.Esta parte de la guía es únicamente destinada a los programadores. Debe estar realizado de tal forma que permita la división del trabajo
- Programa fuente: Es donde se incluye la codificación realizada por los programadores. Este documento puede tener, a su vez, otra documentación para su mejor comprensión y puede ser de gran ayuda para el mantenimiento o desarrollo mejorado de la aplicación. Este documento debe tener una gran claridad en su escritura para su fácil comprensión.
- Pruebas: es el documento donde se especifican el tipo de pruebas realizadas a lo largo de todo el proyecto y los resultados obtenidos.
Es lo que comúnmente llamamos el manual del usuario. Contiene la información necesaria para que los usuarios utilicen correctamente la aplicación.
Este documento se hace desde la guía técnica pero se suprimen los tecnicismos y se presenta de forma que sea entendible para el usuario que no sea experto en informática.
Un punto a tener en cuenta en su creación es que no debe hacer referencia a ningún apartado de la guía técnica y en el caso de que se haga uso de algún tecnicismo debe ir acompañado de un glosario al final de la misma para su fácil comprensión.
La guía de instalación
Es la guía que contiene la información necesaria para implementar dicha aplicación.
Dentro de este documento se encuentran las instrucciones para la puesta en marcha del sistema y las normas de utilización del mismo.
Dentro de las normas de utilización se incluyen también las normas de seguridad, tanto las físicas como las referentes al acceso a la información.
lunes, 18 de enero de 2010
Educando a los usuarios
Agosto 28, 2009 por rtmex
Cuando desarrollamos un software a la medida, es común encontrar que el usuario (la empresa o persona) a quien se le desarrolla la aplicación, no tiene ni la más remota idea de cómo es el proceso de desarrollo de software; es más, muchos no saben ni como copiar archivos de una carpeta a otra en una PC, pero bueno, eso ya es otro tema.
Lo que yo he optado por hacer y hasta ahora me ha funcionado, es explicarles que el proceso de desarrollo de una aplicación es parecido al proceso de construcción de una casa. Primero le decimos al arquitecto lo que tenemos en mente para que el haga el plano, nos lo muestre y nosotros lo aprobemos o le indiquemos si queremos que le haga algunos cambios.
En el caso de que le hayamos indicado que haga cambios al plano, el arquitecto debe hacer un nuevo plano con los cambios y volver a mostrarnoslo para que lo aprobemos. Este proceso se repite hasta que nosotros aprobemos el plano. Es hasta que el plano (arquitectónico) está aprobado por nosotros que el arquitecto empieza a crear los demás planos que se requieren (eléctrico, hidráulico, etc.)
De igual forma, después de que el usuario nos dice que tiene en mente, lo que debemos hacer es la especificación de requisitos, que será la base para el desarrollo de la aplicación. En este documento se describe la funcionalidad que tendrá la aplicación y debe ser aprobado por el usuario. Una vez que la especificación de requisitos es aprobada por el usuario, empezamos a hacer el diagrama entidad-relación de la base de datos, etc.
El que el usuario espere ver la primer pantalla de la aplicación un dia después de que nos dijo cuáles son sus necesidades, es tanto como esperar que el arquitecto levante la primera barda inmediatamente después de que le dijimos lo que tenemos en mente, sin que haga un plano que nos muestre para que lo aprobemos, es ilógico ¿no creen?
Así como en el proceso de construcción de una casa, no le preguntamos al arquitecto a la mitad de la obra “¿en dónde va a estar ubicada la cancha de tenis?”, siendo que en el plano que nos mostró y que nosotros aprobamos no aparece ninguna cancha de tenis, está por demás explicarle al usuario que no esperamos que a la mitad del desarrollo de la aplicación nos pregunte “¿En qué menú estará la opción de facturación?”, cuando en la especificación de requisitos que le mostramos y que aprobó no se habla en ningún momento de un módulo de facturación.
Otra analogía entre el desarrollo de una aplicación y la construcción de una casa que utilizo es para hacerles entender que cuesta mas agregar funcionalidad a un módulo ya hecho que incluir dicha funcionalidad en el módulo desde un principio.
Supongamos que el arquitecto ya terminó la planta baja de nuestra casa, está construyendo la planta alta y le decimos que queremos que el medio baño de la planta baja, que está junto a la sala, ahora sea baño completo. “¿Se puede hacer esa modificación?”, probablemente si, pero desde luego costará más de lo que hubiera costado si desde que nos mostró el plano para que lo aprobaramos le hubieramos pedido esto, cuesta más porque ahora hay que instalar más tubería para que llegue agua caliente a la regadera que se instalaŕa en ese baño, y probablemente habrá que tirar algún muro para que haya espacio para la ducha en ese baño.
De igual forma, generalmente el agregar a un módulo ya hecho funcionalidad que no se contempló desde un inicio, cuesta más porque implica más trabajo. Así de simple.
En conclusión, debemos hacer entender al usuario que no debe asumir que la aplicación tendrá funcionalidad que en la especificación de requisitos no se dijo que tendría. Nada de que “yo pensé”, “es que es obvio”, y otras frases por el estilo.
Si desarrollas software a medida, te recomiendo hacer la especificación de requisitos y que el usuario la firme como aprobada antes de empezar con el desarrollo. Evitarás malos entendidos y problemas posteriores.
Y si tu eres usuario final, desconfia de la capacidad de cualquier “profesional de sistemas” que te prometa mostrarte avances de la aplicación sin antes haber hecho la especificación de requisitos y sobre todo, antes de haber construido el diagrama entidad-relación de la base de datos y demás “planos”. Es equivalente a que el arquitecto que construirá tu casa te diga que verás la primera barda sin antes haberte mostrado el plano.
Etiquetas: desarrollo de software a medida, educar al usuario final, especificación de requisitos
Lo que yo he optado por hacer y hasta ahora me ha funcionado, es explicarles que el proceso de desarrollo de una aplicación es parecido al proceso de construcción de una casa. Primero le decimos al arquitecto lo que tenemos en mente para que el haga el plano, nos lo muestre y nosotros lo aprobemos o le indiquemos si queremos que le haga algunos cambios.
En el caso de que le hayamos indicado que haga cambios al plano, el arquitecto debe hacer un nuevo plano con los cambios y volver a mostrarnoslo para que lo aprobemos. Este proceso se repite hasta que nosotros aprobemos el plano. Es hasta que el plano (arquitectónico) está aprobado por nosotros que el arquitecto empieza a crear los demás planos que se requieren (eléctrico, hidráulico, etc.)
De igual forma, después de que el usuario nos dice que tiene en mente, lo que debemos hacer es la especificación de requisitos, que será la base para el desarrollo de la aplicación. En este documento se describe la funcionalidad que tendrá la aplicación y debe ser aprobado por el usuario. Una vez que la especificación de requisitos es aprobada por el usuario, empezamos a hacer el diagrama entidad-relación de la base de datos, etc.
El que el usuario espere ver la primer pantalla de la aplicación un dia después de que nos dijo cuáles son sus necesidades, es tanto como esperar que el arquitecto levante la primera barda inmediatamente después de que le dijimos lo que tenemos en mente, sin que haga un plano que nos muestre para que lo aprobemos, es ilógico ¿no creen?
Así como en el proceso de construcción de una casa, no le preguntamos al arquitecto a la mitad de la obra “¿en dónde va a estar ubicada la cancha de tenis?”, siendo que en el plano que nos mostró y que nosotros aprobamos no aparece ninguna cancha de tenis, está por demás explicarle al usuario que no esperamos que a la mitad del desarrollo de la aplicación nos pregunte “¿En qué menú estará la opción de facturación?”, cuando en la especificación de requisitos que le mostramos y que aprobó no se habla en ningún momento de un módulo de facturación.
Otra analogía entre el desarrollo de una aplicación y la construcción de una casa que utilizo es para hacerles entender que cuesta mas agregar funcionalidad a un módulo ya hecho que incluir dicha funcionalidad en el módulo desde un principio.
Supongamos que el arquitecto ya terminó la planta baja de nuestra casa, está construyendo la planta alta y le decimos que queremos que el medio baño de la planta baja, que está junto a la sala, ahora sea baño completo. “¿Se puede hacer esa modificación?”, probablemente si, pero desde luego costará más de lo que hubiera costado si desde que nos mostró el plano para que lo aprobaramos le hubieramos pedido esto, cuesta más porque ahora hay que instalar más tubería para que llegue agua caliente a la regadera que se instalaŕa en ese baño, y probablemente habrá que tirar algún muro para que haya espacio para la ducha en ese baño.
De igual forma, generalmente el agregar a un módulo ya hecho funcionalidad que no se contempló desde un inicio, cuesta más porque implica más trabajo. Así de simple.
En conclusión, debemos hacer entender al usuario que no debe asumir que la aplicación tendrá funcionalidad que en la especificación de requisitos no se dijo que tendría. Nada de que “yo pensé”, “es que es obvio”, y otras frases por el estilo.
Si desarrollas software a medida, te recomiendo hacer la especificación de requisitos y que el usuario la firme como aprobada antes de empezar con el desarrollo. Evitarás malos entendidos y problemas posteriores.
Y si tu eres usuario final, desconfia de la capacidad de cualquier “profesional de sistemas” que te prometa mostrarte avances de la aplicación sin antes haber hecho la especificación de requisitos y sobre todo, antes de haber construido el diagrama entidad-relación de la base de datos y demás “planos”. Es equivalente a que el arquitecto que construirá tu casa te diga que verás la primera barda sin antes haberte mostrado el plano.
Etiquetas: desarrollo de software a medida, educar al usuario final, especificación de requisitos
miércoles, 9 de diciembre de 2009
Taller 9,10 y 11
Orden de los Hermanos Menores Capuchinos
Colegio San Francisco de Asís
Colegio San Francisco de Asís
Taller de Sistemas Grados 9,10 y 11
Docente: Juan Carlos Jaramillo Corrales
1: En una tienda efectúan un descuento a los clientes dependiendo del monto de la compra. El descuento se efectúa con base en el siguiente criterio:
Si el monto es menor que $500→no hay descuento.
Si el monto está comprendido entre $500 y $1,000
inclusive→5% de descuento
Si el monto está comprendido entre $1,000 y $7,000
inclusive→11% de descuento
Si el monto está comprendido entre $7,000 y $15,000
inclusive→18% de descuento
Si el monto es mayor a $15,000→25% de descuento.
Construya un diagrama de flujo tal que dado el monto de la compra de un cliente, determine lo que el mismo debe pagar.
2: Dado como datos tres números reales. Identifique cuál es el mayor. Considere que los números pueden ser iguales. Desarrolle el diagrama de flujo correspondiente.
3. El costo de las llamadas telefónicas internacionales depende de la zona geográfica en la que se encuentre el país destino y del número de minutos hablados. En la siguiente tabla se presenta el costo del minuto por zona. A cada zona se le ha asociado una clave.
CLAVE ZONA PRECIO
12 América del Norte $1300
15 América Central $900
18 América del Sur $1800
19 Europa $2300
23 Asia $2900
25 África $2950
29 Oceanía $2500
Construya un diagrama de flujo que le permita calcular e imprimir el costo total de una llamada.
Suscribirse a:
Entradas (Atom)