tec 2 portal

98
PARTE I DESCRIPCIÓN DEL PROBLEMA

Upload: andreita-mb

Post on 17-Dec-2015

28 views

Category:

Documents


1 download

DESCRIPTION

Perfil de informe de un sistema de informacion

TRANSCRIPT

UNIVERSIDAD AUTNOMA GABRIEL RENE ORENO

PARTE I

DESCRIPCIN DEL PROBLEMA

CAPTULO 1. PERFIL

1.1 Introduccin

En la actualidad las empresas en todo el mundo invierten sumas enormes de dinero en sistemas de informacin, aproximadamente entre el 4 y 7% de sus ingresos totales anuales. En un mundo globalizado y cada vez ms competitivo las empresas se han dado cuenta que uno de sus recursos ms importantes es la informacin. Una organizacin busca que la informacin sea confiable y oportuna para facilitar una toma de decisiones precisa y reaccionar ms rpido a los requerimientos del mercado. Todos los sistemas contienen datos, pero no sirven de nada sino tienen un sentido, una elaboracin; cuando se procesan es cuando obtenemos lo que conocemos como informacin. (Ackoff, 1999). Los usuarios de un sistema son los responsables de indicar cmo un sistema debe procesar los datos para que tenga como salida informacin til.

En las ltimas dcadas los sistemas de informacin se han convertido en una herramienta funcional y crtica de una organizacin, casi todas las empresas alrededor del mundo dependen de la tecnologa digital para procesar informacin. Su papel principal es apoyar la coordinacin de las distintas unidades de una organizacin. La manera en que la informacin est distribuida y es analizada dentro de una empresa puede ser un factor muy importante para el xito de la misma, consecuentemente los sistemas de informacin desempean un rol esencial en una organizacin.

As como un sistema bien desarrollado es importante tambin es importante mostrar la informacin al usuario final, y la mejor manera de llegar a dichos usuarios es teniendo un portal Web el cual pueda interactuar con el usuario.

1.3. Descripcin del problema

El sistema clsico de registro y seguimiento de informacin viene a quedar obsoleto en comparacin con la automatizacin del mismo, ya que si fuese manual no haramos uso de la gran ventaja que nos ofrece Internet, al permitir contactarnos con muchas personas a travs del uso de correo electrnico.

La siguiente lista hace constatar las limitaciones que el sistema de registro y seguimiento de informacin clsico presenta:

Tiempo, ya que para realizar la el registro y seguimiento de informacin nos vemos obligados a transportarnos hasta la oficina donde vamos a registrarnos.

Perdida de Informacin, ya que al manejar la informacin manualmente se la puede perder por diferentes motivos (fallas humanas o accidentes imprevistos).

Gastos Innecesarios, ya que se invierte dinero en material de escritorio.

Entre las ventajas que presenta la automatizacin de este proceso se encuentran:

Disminuye los costos asociados al material de escritorio, y contratacin de personal.

Reduce el tiempo de procesamiento, ya que una maquina es mucho mas rpida, obteniendo resultados en menor tiempo.

Disminuye las posibilidades de error y fallas por prdida o desaparicin de papeles.

1.4. Objetivos

1.4.1 Objetivo general

Desarrollar un portal web para la publicacin de Eventos en general.

1.4.2 Objetivos especficos

Realizar una minuciosa captura de requerimientos, tomando en cuenta los requerimientos explcitamente solicitados para la materia y otros requerimientos implcitos que sean necesarios.

Realizar un anlisis de todos los requerimientos para el desarrollo del sistema. A travs de la elaboracin de casos de uso, para una mejor comprensin de los requerimientos y de esta forma refinar y estructurar los requisitos.

Disear la arquitectura de la aplicacin tomando como base el anlisis de los requerimientos.

Seguir el desarrollo sistemtico de todas las actividades segn el PUDS Proceso Unificado de Desarrollo de Software, para Desarrollar un portal web para publicacin de Eventos.

Aplicar UML Lenguaje de Modulacin de Unificacin, para representar todos los diagramas y estereotipos que utiliza el PUDS en cada flujo de trabajo.

Realizar los flujos de trabajos formalizados y definidos por el proceso unificado.

Comprobar si existe falencias, errores, para la posterior actualizacin del portal, para esto aplicar el flujo de trabajo Pruebas.

1.5. Alcance

El sistema contempla dos mdulos, los cuales son: requerimientos funcionales y los no Funcionales.

1.5.1. Requerimientos Funcionales

RF1 Instruccion.- El sistema proveer una gua para navegar en el portal web, Adems permitir al cliente enviar reclamos y sugerencias. RF2 ABM Productos.- El sistema proveer los mecanismos necesarios para la creacin, edicin y eliminacin de productos.

RF3 ABM Cliente.- El sistema proveer los mecanismos necesarios para el registro, la modificacin y la eliminacin de los clientes del sistema.

RF4 Detalle de Productos.- El sistema contiene los mecanismos para presentar un detalle especfico de un producto en particular.

RF5 Promocionar Productos.- El sistema proveer los mecanismos necesarios para la publicacin o promocin de los productos nuevos.

RF6 Cotizaciones.- El sistema proveer los mecanismos para la realizacin de cotizaciones requeridas por el Cliente.

RF7 Reportes.- El sistema proveer informacin de los productos y servicios ms destacados y todos los reportes requeridos por el sistema.

1.5.2. Requerimientos No funcionales

Almacenamiento de la informacin en un gestor de base de datos

Portabilidad del sistema y compatibilidad con los servidores de correo existentes.

Proveer de las interfaces necesarias para que el sistema (o parte de l) pueda reutilizarse.

1.6. Metodologa

La metodologa que se utilizar para el desarrollo del presente proyecto ser el ciclo de vida del PROCESO UNIFICADO DE DESARROLLO DE SOFWTWARE (P.U.D.S.), el cual utiliza el Lenguaje Unificado de Modelado (UML), porque es un proceso dirigido por casos de uso definidos en cada fase, centrado en la arquitectura, donde se puede visualizar el comportamiento del proyecto.

Es iterativo e incremental, lo que permite dividir el proyecto en partes ms pequeas, donde cada incremento aumenta la funcionalidad del proyecto. Est centrada en la arquitectura, es decir, en la estructura del sistema.

Las fases que se desarrollarn del Proceso Unificado son: Inicio, Elaboracin y Construccin. La fase de transicin no se tomar en cuenta, puesto que el proyecto a realizar no est centrado a un caso de estudio especfico.

PARTE II

MARCO REFERENCIAL

CAPITULO 2. MARCO TERICO

2.1 SMARTYSmarty es un motor de plantillas para PHP. Mas especificamente, esta herramienta facilita la manera de separar la aplicacin lgica y el contenido en la presentacin. La mejor descripcin esta en una situacin donde la aplicacin del programador y la plantilla del diseador juegan diferentes roles, o en la mayoria de los casos no la misma persona. Por ejemplo: Digamos que usted crea una pagina web, es decir, despliega el articulo de un diario. El encabezado del articulo, el rotulo, el autor y el cuerpo son elementos del contenido, estos no contiene informacin de como quieren ser presentados. Estos son pasados por la aplicacin Smarty, donde el diseador edita la plantilla, y usa una combinacin de etiquetas HTML y etiquetas de plantilla para formatear la presentacin de estos elementos (HTML, tablas, color de fondo, tamao de letras, hojas de estilo, etc...). Un da el programador necesita cambiar la manera de recuperar el contenido del articulo. Este cambio no afectara al diseador de la plantilla, el contenido llegara a la plantilla exactamente igual. De la misma manera, si el diseador de la plantilla quiere redisearla en su totalidad, estos cambios no afectaran la aplicacin lgica. Por lo tanto, el programador puede hacer cambios en la aplicacin lgica sin que sea necesario reestructurar la plantilla. Y el diseador de la plantilla puede hacer cambios sin que haya rompimiento con la aplicacin lgica.Smarty no intenta separar completamente la lgica de la plantilla. No hay problema entre la lgica y su plantilla bajo la condicin que esta lgica sea estrictamente para resentacin. Mantener la aplicacin lgica fuera de la plantilla, y la presentacin fuera de la aplicacin lgica. Esto tiene como finalidad tener un objeto mas manipulable y escalable para un futuro proximo.

Un nico aspecto acerca de Smarty es la compilacin de la plantilla. De esta manera Smarty lee la plantilla y crea los scripts de PHP. Una vez creados, son ejecutados sobre l. Por consiguiente no existe ningn costo por analizar gramaticalmente cada archivo de template por cada requisicin, y cada template puede llevar toda la ventaja del compilador de cache de PHP tal como Zend Accelerator o PHP Accelerator.Algunas de las caractersticas de Smarty:

Es extremamente rpido.

Es eficiente ya que puede interpretar el trabajo mas sucio.

No analiza gramaticalmente desde arriba el template, solo compila una vez.

El esta atento para solo recompilar los archivos de plantilla que fueron cambiados.

Usted puede crear funciones habituales y modificadores de variables customizados, de modo que el lenguaje de la platilla es altamente extensible.

Sintaxis de etiquetas delimitadoras para configuracin de la plantilla, as lo puede usar {}, {{}}, , etc.

Los construtoress if/elseif/else/endif son pasados por el interpretador de PHP, as la sintaxis de la expresin {if ...} puede ser compleja o simple de la forma que usted quiera.

Permite un anidamiento ilimitado de sections, ifs, etc.

Es posible incrustar directamente codigo PHP en los archivos de plantilla, aunque esto puede no ser necesario dado que la herramienta se puede ajustar.

Soporte de caching incrustado

Fuentes de Plantilla absoluto

Funciones habituales de manipulacin de cache

Arquitectura de PluginSINTAXIS DE SMARTYComentarios

Los comentarios en los templates son cercados por asteriscos, y por los delimitadores, as: {* este es un comentario *}. Los comentarios en Smarty no son mostrados en la salida final del template. Estos son usados para hacer notas internas dentro del template.

Ejemplo

{* Smarty *}

{* include the header file here *}

{include file="header.tpl"}

{include file=$includeFile}

{include file=#includeFile#}

{* display dropdown lists *}

{html_options values=$vals selected=$selected output=$output}

Funciones

Cada etiqueta Smarty muestra una variable o utiliza algn tipo de funcin. Las funciones son procesadas y mostradas colocando los atributos de la funcin entre delimitadores, as: {funcname attr1="val" attr2="val"}.

Ejemplo

{config_load file="colors.conf"}

{include file="header.tpl"}

{if $highlight_name}

Welcome, {$name}!

{else}

Welcome, {$name}!

{/if}

{include file="footer.tpl"}Las funciones internas y las funciones habituales, ambas deben tener la misma sintaxis dentro del template. Las funciones internas que funcionan en Smarty, son: if, section y strip. Estas no pueden ser modificadas. Las funciones habituales son funciones adicionales implementadas por plugins. Estas si pueden ser modificadas como usted quiera, o usted tambin puede adicionar nuevas. html_options y html_select_date son ejemplos de funciones habituales.

Atributos

La mayoria de las funciones llevan atributos que especifican o cambian su funcionamiento. Los atributos para las funciones de Smarty son muy parecidos a los atributos de HTML. Los valores estaticos no necesitan estar entre comillas, pero si es recomendado para cadenas y literales. Las variables tambin pueden ser usadas y no precisamente estando entre comillas.

Algunos atributos requieren valores boleanos(true o false). Estos pueden ser especificados como cualquier otro valor sin comillas true, on, y yes, o false, off, y no.

Ejemplo{include file="header.tpl"}

{include file=$includeFile}

{include file=#includeFile#}

{html_select_date display_days=yes}

{html_options values=$vals selected=$selected output=$output}

Colocando variables entre comillas dobles

Smarty puede reconocer variables asignadas entre comillas aunque estas solo tengan nmeros, letras, guiones bajos y corchetes[].

Con cualquier otro carcter(puntos, referencia de objetos, etc.) las variables deben estar entre apostrofos.

Ejemplo

{func var="test $foo test"}