Posts from the ‘Sistemas de Informacion II’ Category

Manual Tècnico

En el siguiente documento se muestra el Manual tecnico desarrollado para el sfw Kids Time, en el encontraran el diagrama que describe el sistema ademas de  otros puntos importantes

MANUAL TÉCNICO FINAL

MANUAL TECNICO

Manual técnico

  1. Historia
  2. introducción
  3. Especificación de los requisitos del software
  4. Diagrama general (MER-D. Contexto)
  5. Diccionario de datos.
  6. Diagrama relacional
  7. Definición de variables de ambiente y librerías.
  8. Programas especiales y de ambiente
  9. Restricciones o límites de la programación.

10. Flujo grama de información, proceso actividad.

 

  • Historia.

En este apartado se registran los eventos relevantes durante la elaboración del doc., tales como: creación, revisión, autorización, adicción, modificación, actualización, etc. Para cada uno de estos eventos se debe de registra la fecha, el nombre del responsable y un  breve comentario de sobre la acción realizada.

 

  • Introducción.

En los puntos que integran este apartado, se debe incluir información relevante y útil para la comprensión de este doc.

 

  • ERS.

Documento específico en el cual se describen los requisitos y el análisis del sistema, para este doc. Se utiliza un formato estandarizado bajo normalización ISO.

 

  • Diagrama general.

Se debe representar la función del sistema en base a los diagramas representativos de las actividades propias del sistema.

 

  • Diccionario de datos.

El diccionario de datos es un listado organizado de todos los objetos de datos pertinentes para el sistema. La información contenida en el deberá incluir aquellas características que describan e identifiquen cada objeto de datos.

Las notaciones, métodos y/o herramientas utilizadas para desarrollar este apartado deberán de estar estandarizados.

 

  • Diagrama  relacional

Aquí se describirá por medio del diagrama relacional, las interrelaciones que existen entre los objetos de la base de datos. Esta relación se establece a través de los atributos o los campos comunes

 

  • Definición de variables de ambiente y librerías.

Se deben definir las variables o librerías que son utilizadas para la configuración del entorno o de la aplicación algunos ejemplos de estas variables pueden ser: el tipo de acceso que tiene un usuario, la conexión a una base de datos, las restricciones propias de la aplicación hacia el sistema operativo, etc., etc. En el caso de las librerías pueden ser aquellas que permiten a la aplicación el uso de gráficos, archivos, estilográficas de texto, etc.

 

 

  • Programas especiales o de ambiente

Se deben definir los programas o funciones específicas, que permitan la configuración del entrono y/o programas que son de uso común o de carácter específico; como pueden ser: el control de la fecha y hora, impresión, conexión de la base de datos, acceso a la aplicación, etc.

 

  • Restricciones o límites de la programación.

En esta parte se deberán documentar las restricciones y/o límites que se tuvieron sobre la programación del proyecto. Algunos ejemplos pueden ser: la impresión de textos a menores a “X” numero de caracteres, el efecto de un enter o el uso de comillas o algún otro carácter especial en un  texto, desventaja de utilizar algún tipo de recorteador, etc.

 

  • Flujo grama de información, proceso actividad.

Se representa de manera gráfica cada proceso del sistema de información (informático) por cada proceso se deberán incluir las actividades que en cada uno se ellos se realizan.

 

Esto no es un foco

  • Ejemplo del ejercicio»Esto no es un foco», referente a las «interfaces de usuario»

 

ESTO NO ES UN FOCO

De su análisis preliminar se desprende que para conseguir una reducción sustancial de errores es necesario que los dependientes de Bright’s Electric (que vende partes eléctricas, focos y adornos a clientes mayoristas) adopten un sistema en línea. El nuevo sistema permitirá a los dependientes extraer piezas del inventario (y en consecuencia actualizar este último), devolver una pieza al inventario, verificar el estado del inventario y comprobar si una pieza necesita reabastecerse. En la actualidad, para actualizar el inventario, los dependientes contestan a mano un formulario con dos copias. El cliente se queda con una, el departamento de control de inventario conserva otra y los originales se depositan en la oficina principal al final del día.

 A la mañana siguiente, lo primero que hace la solitaria oficinista es ingresar en la computadora los datos de los formularios. Los errores se generan cuando ella introduce números de parte o cantidades erróneos.

 Cuando los encargados del inventario buscan una pieza de la cual creen que hay en existencia pero no la encuentran, se gasta tiempo adicional.

 Alrededor del mediodía se envían hojas de inventario actualizadas a los dependientes de ventas, pero para ese momento estos últimos ya han tomado del inventario más del doble de las piezas que se tomarán después del mediodía. Es evidente que un sistema en línea bien diseñado ayudaría a reducir estos errores y también auxiliaría en el control del inventario.

 El propietario, el señor Bright, ha considerado la idea de un sistema en línea durante los últimos cinco años y la ha abandonado varias veces.

La principal razón es que los dependientes, que deberían ser quienes más usaran el sistema, no confían en que los analistas de sistemas con quienes han hablado puedan satisfacer sus necesidades.

 M. I Sockette, el dependiente de ventas que más tiempo lleva trabajando con el señor Bright, es el más elocuente y dice: «Nosotros conocemos las piezas y a nuestros clientes. Sería muy bueno lo que pudiéramos hacer aquí con una computadora. Sin embargo, los tipos que  rajeron para ponerla a funcionar… es decir, dan indicaciones como: ‘Párense frente a la computadora y tecleen un foco General Electric de 60 watts’

 Para nosotros, no es un foco, es un GE60WSB. Todos nosotros conocemos los números de parte. Nos enorgullecemos de ello. Si escribiéramos toda esa basura nos tomaría todo el día.»

 Después de hablar con el señor Brlght, usted decide implementar un sistema en línea. Usted ya conversó con M. T. y los demás y les reiteró que el sistema utilizará los números de parte con los que ya están familiarizados y que esto les ahorrará tiempo. Aunque escépticos, los convenció de que prueben el sistema.

 ¿Qué tipo de interfaz de usuario diseñará para los dependientes de ventas? Antes

 

 

 

Preferìrìa Hacerlo Yo Mismo

«Puedo pedir a Mickey que baje de la Web o de nuestro servidor a mi PC los datos que necesito», le dice a usted DeWitt Miwaye, un alto ejecutivo de Yumtime Foods (un mayorista de alimentos del Medio Oeste). «Obtener los datos no es el problema. Lo que no quiero son muchos reportes.

Prefiero analizar los datos yo mismo.» Miwaye le dice a usted que, como ejecutivo, él no usa su PC con la frecuencia que quisiera, tal vez sólo tres veces por mes, pero sabe bien lo que le gustaría hacer con ella.

«Me gustaría hacer algunas comparaciones por mí mismo. Podría comparar el índice de rotación de empleados de nuestros 12 almacenes También me gustaría ver la eficacia con que se utiliza cada uno de nuestros almacenes. A menudo quisiera poder construir una gráfica de las comparaciones o ver un análisis de ellas en relación con el tiempo.»

En tres párrafos, compare tres tipos distintos de interfaz que podría usar Miwaye. A continuación recomiéndele una interfaz qué tome en cuenta la poca frecuencia con que utiliza la PC, la forma en que disfruta trabajar con datos puros y su deseo de desplegar datos en diversas formas;

Soluciòn:

1.- Interfaces de lenguaje natural:

La interfaz de lenguaje natural es una de las interfaces que el ejecutivo de Yumtime Foods podría utilizar ya que este tipo de interfaz es ideal para usuarios inexpertos y  Miwaye no suele utilizar la PC. Como desea por lo que no podría tener los conocimientos necesarios para el adecuado uso de ella y este tipo de interfaz le seria de gran ayuda

2.- Interfaces de formulario: Este tipo de formulario es muy parecido a un formulario impreso así que por ende los que trabajan con este tipo comentan  que les resulta sencillo trabajar con este tipo de interfaz ya que se sienten familiarizados con el.

Miwaye comenta no tiene el suficiente tiempo para checar cada uno de los detalles de la empresa como a el le gustaría, por se le recomienda a Miwaye que emplee este tipo de formulario ya que este le permitiría la comparación que requiere además de la impresión similar de las graficas.

3.- otras interfaces de usuario: Este tipo de interfaz resulta  provechoso para los usuarios que no pueden accesar con frecuencia a los datos mediante la PC. Permite el uso de aparatos tecnológicos novedosos que son de ayuda para este tipo de personas.

Miwaye no cuenta con el tiempo necesario para acceder a los datos que necesita y este tipo de interfaz es de ayuda para el.

Interfaces de formulario

La interfaz que le recomendaria a Miwaye es la interfaz de formulario ya que este tipo de interfaz  le permite tener diferentes formularios en pantalla o en la web y permite tener una excelente documentacion.

Modelo E/R y sus tipos

*En este video encontraras informacion relacionada al modelo Entidad Ralacion y sus tipos.

  • Modelo Hibrido.
  • Modelo Entidad Relacion
  • Modelo Entidad Ralacion Extendido.

http://www.youtube.com/watch?v=qv1RTsjVAfI

Base de Datos

 

BASE DE DATOS.

Las bases de datos no son tan solo una colección de archivos. Más bien, una base de datos es una fuerte central de datos destinados a compartirse entre muchos usarios para diversidad de aplicaciones.

 

OBJETIVOS DE EFECTIVIDAD DE LA BASE DE DATOS.

  • 1.-asegurar que los datos se puedan compartir entre los usuarios para una diversidad de aplicaciones.
  • 2.-mantener datos que sean exactos y consistentes.
  • 3.-asegurar que todos los datos requeridos por las aplicaciones actuales y futuras se podrán aceder con facilidad.
  • 4.-permitir a la base de datos evolucionar con forme aumentan las necesidades de los usuarios.
  • 5.-permitir a los usuarios contruir su vista personal de los datos, sin preocuparse por la forma en que los datos se encuentran almacenados físicamente.

EJEMPLO ENTIDAD/RELACION

https://anahiitsl.wordpress.com/wp-content/uploads/2010/09/presentacion1.ppt

Lay de Fitt

LEY DE FITT.

Esta ley es la más básica y conocida entre las leyes de diseño de interfaces de usuario esta ley dice que cuando más grande y más cercano al puntero del ratón es un objeto más sencillo es hacer clic sobre él.

Esto es sentido común, pero muchas veces es ignorado en el diseño de interfaces de usuario.

 

INTERFERENCIAS INECESARIAS

Esto quiere decir que cuando un usuario está trabajando sobre una aplicación normalmente está concentrado en su trabajo, suponga el caso de que una aplicación “modernista” facilita automáticamente al usuario la notificación puntual de cada hora mediante un mensaje grafico o animación, el usuario tiende a distraerse y perder la concentración; llevando a esto como consecuencia que el usuario recapitule lo que estaba haciendo.

 

UTILIZAN LA POTENCIA DE LA COMPUTADORA.

  • 1.- utiliza su potencia para ayudar al usuario.
  • 2.- as que se pueda distinguir fácilmente entre los elementos similares.
  • 3.-recuerda las opciones de la aplicación.

Diseño de Interfaces de Usuario

*Antes de implementar los formularios y los informes ahí que diseñar su aspecto para ello es necesario tener en cuanta.

 

  • 1.-Utilizar títulos que sean significativos, y que identifiquen sin ambigüedad el propósito del informe o formulario.
  • 2.-Dar instrucciones breves y fáciles de comprender.
  • 3.-Agrupara y secuenciar los campos de forma lógica.
  • 4.-Aser que el aspecto del informe o formulario sea atractivo a la vista.
  • 5.-Utlizar nombres familiares para etiquetar los campos.
  • 6.-Utilizar terminología y abreviaturas contingentes.
  • 7.-Hacer un uso razonable de los colores.
  • 8.-Dejar un espacio visible para los espacios de entrada y delimitarlo
  • 9.- Permitir un uso y adecuado del cursor.
  • 10.-Permitir la correxion de carácter a carácter y de campos correctos.
  • 11.-Dar mensajes de error para los valores ilegales.
  • 12.-Marcar los campos que sean opcionales o en su defecto requisitos.
  • 13.-Dar mensajes a nivel de campo para indicar su significado.
  • 14.-Dar una señal que indique cuando el informe o formulario está completo.

 

 

*El sistema no está usando tu aplicación

La cuestión más básica a considerar en el diseño de interfaces de usuario es que el usuario no quiere utilizar tu aplicación. Quieren hacer su trabajo de la forma más sencilla y rápida posible y la aplicación no es más que una herramienta para ayudarles a lograrlo.

TAREA: DISEÑO DE LA ARQUITECTURA DEL SOFTWARE Y APLICACIONES MONOLITICAS

TAREA 1:

Consultar y preparar ejemplos al menos dos de siguiente tema: 

La arquitectura y el diseño digieren (no están de acuerdo) en tres áreas:

Cuales son en que consistes 2 ejemplos de cada una de las áreas 

 

TAREA 2

Investigar 3 aplicaciones  comerciales:

a)     de arquitectura cliente/servidor

B) aplicaciones que utilicen arquitectura cliente/servidor mejorada

c) aplicaciones que utilicen arquitectura de tres niveles.

 

 

La Arquitectura Vs. Diseño La arquitectura y el diseño difieren en tres áreas:

  Arquitectura Diseño
Nivel de Abstracción Alto nivel Bajo nivel. Enfoque específico en detalles
Entregables Planear subsistemas, interfaces con sistemas externos, servicios horizontales, frameworks, componentes reutilizables, prototipo arquitectónico Diseño detallado componentes.

Especificaciones de codificación

Áreas de Enfoque Selección de tecnologías, Requerimientos no funcionales (QoS),

Manejo de riesgos

Requerimientos funcionales

 

Arquitectura cliente servidor

¿En que consiste? Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

Ejemplo: Implementar reglas comerciales en la aplicación de cliente-servidor de ejemplo Visual Studio .NET 2003 La aplicación de cliente-servidor de ejemplo utiliza un servidor de Automatización personalizado para reforzar las reglas comerciales. Esta arquitectura, conocida como el modelo de tres capas, permite la implementación de las reglas comerciales en la capa del medio, aparte de los datos actuales y aparte de la interfaz del cliente. Hay muchas aplicaciones y muchas bases de datos que pueden utilizar el mismo conjunto de reglas comerciales, codificado y mantenido en una única ubicación.  El servidor de Automatización personalizado en la aplicación de cliente-servidor de ejemplo es Bizrules. El proyecto para el servidor de Automatización es Bizrules.pjx y la clase se define en Bizrules.pjx:

Ejemplo: Vacacional Premium es una aplicación Cliente/Servidor, podrá centralizar los datos en un servidor central SQL, y acceder a la información desde varios PCs cliente desde delegaciones distintas; una correcta gestión de cuentas de administración y agrupación por departamentos, le permitirá gestionar turnos de empresas con multitud de departamentos, turnos y empleados.

 

Aplicaciones que utilicen arq cliente servidor mejorada

Ejemplo: Los sistemas cliente/servidor están construidos de tal modo que la base de datos puede residir en un equipo central, llamado servidor y ser compartida entre varios usuarios. Los usuarios tienen acceso al servidor a través de una aplicación de cliente o de servidor:

  • En un sistema cliente/servidor de dos capas, los usuarios ejecutan una aplicación en su equipo local, llamado cliente, que se conecta a través de la red con el servidor que ejecuta SQL Server.
  • La aplicación de cliente ejecuta las reglas de la compañía y el código necesario para presentar el resultado al usuario; también se conoce como cliente amplio.
  • En un sistema cliente/servidor de varios componentes, la lógica de la aplicación de cliente se ejecuta en dos capas:

*El cliente reducido se ejecuta en el equipo local del usuario y se encarga de presentar los resultados al usuario.

*La lógica de la compañía se encuentra en aplicaciones de servidor que se ejecutan en un servidor. Los clientes reducidos solicitan funciones a la aplicación de servidor, que, a su vez, es una aplicación multiproceso capaz de operar con varios usuarios simultáneos. La aplicación de servidor es la que abre las conexiones con el servidor de la base de datos y se puede ejecutar en el mismo servidor que la base de datos, o se puede conectar a través de la red con otro servidor que opere como servidor de base de datos. Éste es el escenario típico de las aplicaciones de Internet. Por ejemplo, una aplicación de servidor se puede ejecutar en un equipo con Microsoft Internet Information Services (IIS) y dar servicio a miles de clientes reducidos que se ejecuten en Internet o en una Intranet. La aplicación de servidor utiliza un grupo de conexiones para comunicarse con una copia de SQL Server. SQL Server puede estar instalado en el mismo equipo que el IIS o en otro servidor de la red.

  • Arquitectura Cliente-Servidor  Mejorada
  • Lógica de negocios en BD
  • Clientes pesados, no estándar.
  • Conexiones dedicadas a la BD.
  • Mejora en rendimiento
  • Alta administración
  • Baja escalabilidad
  • Baja flexibilidad
  • Baja portabilidad

 

 

Aplicaciones que utilicen arq de 3 niveles: La arquitectura de tres niveles es lógica y no física. Se preocupa con las funciones y no con la implantación. 

 La arquitectura puede ser utilizada para desarrollar sistemas Centralizados o Distribuidos. La arquitectura facilitará la distribución de los componentes del sistema.

Diseño de la Arquitectura del SFW Y Aplicaciones Monoliticas.

Diseño de la Arquitectura del SFW

*La arquitectura está compuesta por su componente la relación que existe entre ellos y con el ambiente que trabajaran, así como también los principios o regalas que normaran su diseño y su evolución.

*Una definición por parte de la ingeniería del software será lo siguiente.

Una arquitectura del software es la estructura de estructuras de un sistema, la cual abarca componentes de software propiedades estrena visible a estos componentes.

¿Porque es importante la arquitectura?

1.-Por que las representaciones de la arquitectura del software facilitan la comunicación entre todas las partes interesadas, en el desarrollo de un sistema avanzado en computadora.

2.- Destacan decisiones tempranas de diseño que tendría un profundo impacto en todo el trabajo de ing.

3.-Porque constituye un modelo relativamente pequeño e intelectualmente comprensible de como este estructurado el sistema y de cómo trabajan junto los componentes.

 

Aplicaciones Monoliticas.

*Son aquellas que conocemos como aplicaciones de estación en otras palabras interfaces graficas de usuario GUI’S son servicios de presentación, negocios y pertinencia de datos, en la misma maquina no ahí concurrencia de usuarios.

*ARQUITECTURA LIENTE/SERVIDOR una de sus características es que cuenta con clientes pesados aunque esto no es un estándar dependiendo del lenguaje, existen conexiones dedicadas a la base de datos mediante esta arquitectura generalmente los protocolos de comunicaciones son pesados, existe ejecución remota de SQL’S existe alta administración y el rendimiento es bajo el tráfico en la red puede estar saturado o ser muy alto

*ARQUITECTURA LIENTE/SERVIDORMEJORADA.Se aplica en la lógica de negocios en la base de datos existen cliente pesados aunque también no es un estándar las conexiones a las bases de datos se convierten a conexiones dedicadas el rendimiento en este tipo de arquitectura es mucho mejor  existe una alta administración baja escalabilidad, flexibilidad y portabilidad.

*ARQUITECTURA DE TRES NIVELES. Reutilización de la lógica de negocios para diferentes clientes o sistemas son aplicables en este enfoque se mejora la escalabilidad y la flexibilidad de las aplicaciones existe una completa independencia de la base de datos.

*ARQUITECTURA VERSUS DISEÑOS. la arquitectura envuelve un conjunto de decisiones de  estrategias de diseños,linchamiento de  reglas y patrones que restringen el diseño Y la implementación de un software.