23 de marzo de 2011

I Fase del Proyecto - Actividad Nro. 3

Título del Proyecto
Aplicación Web para el Registro de Citas en la UPS María de los Ángeles (EMS Arroz del Alba, S.A.) para el Despacho de Subproducto

Requerimientos del Proyecto

Requerimientos del Entorno
La aplicación se ejecutará en un entorno web, adaptándose a cualquier navegador que soporte el protocolo HTTP; Para el desarrollo se usará el Lenguaje de Programación PHP, ya que su interpretación y ejecución se da en el servidor, en el que se encuentra almacenado el script, y el cliente (navegador) sólo recibe el resultado de la ejecución, cuando el cliente hace una petición al servidor para que le envíe una página web, el servidor ejecuta el interprete de PHP, el cual procesa el script solicitado de manera dinámica.
Para la gestión de base de datos se usará MySQL, porque es un gestor de bases de datos usado en múltiples plataformas por su gran rapidez y facilidad de manejo, además de que posee una infinidad de librerías y otras herramientas que permiten el uso a través de lenguajes de programación y es fácil de instalar y configurar.
Para realizar las pruebas de la aplicación se implementará primeramente en un servidor local, pudiéndose usar Xammp, Wamp o AppServ, para luego implementarse en un Servicio de Nombre de Dominio, el cual ya lo posee la empresa y lleva por dirección http://arrozdelalba.gob.ve 

Requerimientos Ergonómicos
La meta en el desarrollo de que la interfaz sea amena al usuario y al administrador, incluyendo las características que permiten hacer tareas de una manera más fácil y rápida. En ese sentido, se han de controlar todas las posibilidades para que la aplicación web sea amigable, sin añadir funciones innecesarias y que los usuarios no lleguen a comprender, para con ello obtener los resultados de una manera inmediata y oportuna, la vista del menú será desplegable de acuerdo al login realizado (cliente, supervisor, administrador). La información será distribuida amigablemente

Requerimientos de Interface
El usuario, supervisor y administrador podrán interactuar con la computadora a través de elementos de control representados gráficamente, las cuales permitirán comunicarse con el computador de una forma rápida.
El usuario, supervisor y administrador requerirán monitor, teclado, CPU y mouse así como impresora.
Para un uso efectivo del software del software, se debe implementar el Internet como medio de comunicación entre el usuario, supervisor y administrador y el servidor de datos.

Pantalla de Login
 

Requerimientos Funcionales

Clase de usuario 1

Caso de Uso
Req 1: Obtener pronósticos
Actor
Cliente
Propósito
Ingreso de la intención de compra.
Resumen
El encargado de operaciones debe ingresar una página web y elegir una opción; a la vez ingresar la data correspondiente. Luego debe ingresar las opciones de las cantidades de subproducto a comprar.
Referencias cruzadas
Req 2


Curso normal de los eventos
Acción del actor
Respuesta del sistema
1. Este caso de uso empieza cuando el encargado elige la opción de intención de compra


2. El sistema pide la contraseña.
3.Introduce la clave


4.Presenta las opciones disponibles
5.Selecciona la opción de inventarios


6. Procesa la petición y muestra el lo solicitado.
7.Selecciona la opción salir


8. Muestra la página de ingreso al sistema.
Cursos alternativos
Línea 4: La contraseña es incorrecta. Se indica el error y la solicita nuevamente.
Clase de usuario 2
Caso de Uso
Req 2: Ingreso de datos históricos
Actor
Encargado de Mercadotecnia
Propósito
Ingresar las demandas anteriores.
Resumen
El encargado de mercadotecnia debe ingresar una página web y elegir una opción; a la vez ingresar la contraseña correspondiente. Luego debe ingresar la opción “ingresar demanda o intención de compra” donde aparecerá los datos a probar o corregir.
Referencias cruzadas
Req 1
Curso normal de eventos
Acción del actor
Respuesta del sistema
1. Este caso de uso empieza cuando el encargado elige la opción Supervisión
2. El sistema pide la contraseña.
3.Introduce la clave
4.Presenta las opciones disponibles
5.Selecciona la opción de pedidos de clientes
6. Procesa la petición y muestra una plantilla para aprobar o modificar pedido.
7. Introduce los datos y selecciona el botón “Aceptar”
8. El sistema verifica los datos y muestra un mensaje de aprobación.
9. Selecciona “Aceptar” y luego la opción “Salir”.
10. Muestra la página de inicio.

Requerimientos de Desempeño
  • Rapidez en la captura, recolección y recuperación de datos.
  • Soporte de varias sesiones simultáneas y continuas.
  • Tratar de cometer errores técnicos, que sea confiable.
Disponibilidad (en un determinado periodo de tiempo)
Disponibilidad: la aplicación debe estar disponible las 24 horas, siendo la comunicación a través de Internet, será accesible desde cualquier lugar.

Entrenamiento
  • Fácil de instruirse y fácil de emplear para personas sin entrenamiento y poco entendimiento de las computadores. Con errores amigables, entendiendo el usuario que fue lo que pasó y que debe realizar a continuación.
  • Gráfico e intuitivo.
  • Tripticos con información sobre las funciones que posee el sistema para cada tipo de usuario.
Restricciones de Diseño
Para que se efectué el desarrollo, es pertinente realizar un diagnostico exhaustivo de la situación que actualmente se viene presentando en la oficina de atención al público de la UPS María de los Ángeles, con el fin de elaborar un análisis, diseñar el sistema de información e implementarlo, para cumplir con el objetivo planteado en este estudio, teniendo previsto que es un ente del Gobierno de la República Bolivariana de Venezuela, se debe usar plantillas que se refieran a la institución.

Materiales
  • Computador con desempeño que pueda correr las diferentes herramientas para el desarrollo, podría decirse que un computador Pentium IV con 1 GB de RAM, con más de 20 GB de disco duro libre o similar, con su respectiva impresora.
  • Papelería para realizar las encuestas e impresión de los trípticos informativos.
  • Internet.
  • Con los materiales nombrados anteriormente se procedera a publicar la web en los DNS de la empresa, asi mismo se dejaran los codigos fuentes del desarollo, quedando abierto a modificaciones (codigo abierto), dejando de lado la implementacion de un software libre, ya que un software libre no es codigo abierto, pero un codigo abierto es un software libre.
Conflicto e Inconsistencia de Requerimientos
Acceso a Internet por parte de los clientes que no posean el servicio, se determina realizar el pedido en la misma oficina de atención al público de la UPS. debido a esto se presenta este conflicto, pero se debe tomar en cuenta que en la mayoría de los casos los requerimientos de los clientes tienen prioridad sobre los requerimientos del usuario supervisor.

Herramientas para el Desarrollo del Software
  • Debido a que la aplicación será orientada hacia el software libre se deben utilizar herramientas que conlleve a tal fin, sin dejar atrás las herramientas privativas, las cuales ofrecen algunas ventajas sobre las de uso libre.
  • MySQL será el manejador de base de datos.
  • En el diseño y maquetación Adobe Photoshop (SO Windows) o GIMP (SO LINUX).
  • Desarrollo de PHP, programación cliente, con Dreamweaver, ZEND STUDIO (SO Windows), o ECLIPSE (SO LINUX), todos inclusive.
  • Para las pruebas locales se instalará APACHE, de esta manera se realizarán pruebas rápidamente y así editar el fichero PHP. La utilización en de diferentes navegadores para ver el comportamiento, tales como: FIREFOX, Opera, IE, Google Chrome.
  • Ya concluida la aplicación Dreamweaver, Zend Studio y Eclipse poseen plugins para uso de cliente FTP y así subir los ficheros al servidor, en caso de usar SO LINUX se usará FileZilla.

1 de marzo de 2011

Proyecto Integrado Comunidad Universidad

En esta entrada se estara discutiendo los posibles temas para el proyecto (Informe Final).

Proyecto: Aplicación Web para el Registro de Citas de la UPS María de los Ángeles.
Los clientes serán válidados por:
Temporizador de un (1) mes para poder ejecutar una solicitud de una nueva cita.
Aunque podrán solicitar cantidades de subproductos, estas cantidades serán modificadas y así remitir un total de subproductos como un total de Bolívares a depositar para que asista a la cita con el bacuhe correspondiente para proceder al despacho.
Los reportes visualizarán la frecuencia de asistencia de los clientes, cantidades despachadas, entre otros aspectos.

17 de febrero de 2011

Foro de Discusion Grupal para la Web

En esta entrada se publica enlace para el Foro y asi seguir la actividad de la Lectura del Capitulo 7 del Libro de Ingenieria del Software de Roger Pressman en su Sexta Edicion. Las Preguntas se recrean en el foro


Grupo PNF Informática

7 de febrero de 2011

Conociendo los Requerimientos del Software

Antes de iniciar un proyecto cuya finalidad sea la de crear específicamente un software, sea cual fuere su  naturaleza, se deben determinar una serie de requisitos y/o requerimientos que nos permitan tener una visión más clara de la situación. Una vez que nos encontramos en esta fase del proyecto es muy importante establecer una metodología practica para la determinación de dichos requisitos debido a que por lo general el cliente cree saber todo lo que el software tiene que hacer y en su mente por lo general solo piensa: ‘debe haber un botón que al yo hacerle clic me muestre tal y cual cosa o haga esto o aquello’, o ‘yo quiero que al ingresar esto, me muestre esto y haga esto otro’. Es cierto que el cliente lo que realmente desea es realizar x proceso de una manera más eficiente y expedita, a menudo no le importa cómo, solo desea ver reflejado lo que él espera. Es en este momento que el analista debe poseer la destreza para detectar, corregir y proponer soluciones reales que fundamentados en la información que se le ha suministrado le permita presentar una propuesta o solución que satisfaga las necesidades que espera del cliente.  Es importante destacar que en esta fase lo que piensa el cliente generalmente es diametralmente opuesto a lo que piensa el analista-programador, debido a que ambos es piensan en función de sus experiencias y conocimientos. Mientras que el cliente piensa en lo que debe tener, como por ejemplo un resultado, reporte, etc., el analista-programador piensa en el posible diseño de la base de datos, como va a mantener la integridad y fidelidad de los datos, como adapta lógicamente cierto proceso manual de forma correcta de manera automatizada, y todo esto pensando siempre en no hacer un mal diseño que lo lleve a programar errores, que lógicamente no es lo que quiere el cliente.
Al realizar el estudio de los requerimientos es frecuente encontrarnos con situaciones confusas debido a que la información suministrada y esperada por el cliente no siempre es obvia, y tienen  muchas fuentes, por lo que un mismo problema es resuelto con dos o más formas diferentes por el cliente. En ocasiones podemos observar que el cliente no encuentras las palabras correctas para expresar lo que necesita para un caso especifico, por lo puede decirnos: ‘mira tengo esto y quisiera ver si pudiera obtener aquello’ o ‘no se como usted podría solucionar o mejorar esto’. Esta situación se complica un poco cuando hay varios interesados (llámese departamentos, sucursales, etc.), para los cuales la solución pudiese ser levemente diferente a otro departamento, pero al fin y al cabo los participantes desean lo mismo.
Los requisitos no son más que la determinación de las necesidades mismas que ayudarán a los ingenieros de software a entender mejor el problema en el cual están trabajando. Esto es importante debido a que se debe entender ampliamente lo que el cliente quiere antes de empezar a diseñar y construir un sistema, ya que esto repercutirá en el coste y tiempo necesarios para la culminación exitosa del software.
Podemos enunciar algunos de las especificaciones de los requerimientos:
-    Funcionales: son los que el usuario necesita que efectúe el software, capacidad de resolver un problema o alcanzar un objetivo (entrada, salida y excepciones). Ejemplo: el sistema debe emitir un comprobante al asentar la entrega de mercadería.
-    No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología).
-     Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ejemplo: Definir el costo de la industrialización del sistema, teniendo como objetivo disminuir costos de expedición y definir medio de entrega del sistema.
En entornos de software libre, muy frecuentemente el fundador (y gestor) del proyecto será también su primer usuario, pero esto no le exime de esta tarea, que determinará el alcance del proyecto al menos en sus primeras versiones, y permitirá a los desarrolladores que se vayan incorporando al proyecto, hacerse una idea de su progreso y objetivos, así como dónde prestar su ayuda.
Analizando las estadísticas de por qué los proyectos de software fallan según la Quality Sistems & Software tenemos que el mayor índice corresponde a requerimientos incompletos con un 15.9%, seguido de la falta de requerimientos con un 12.4%. Esto nos da una idea de lo importante que es la ingeniería de requisitos y análisis en la práctica a la hora de realizar nuestro proyecto anual.
A fin de realizar un buen estudio de los requerimientos y tener un mejor porcentaje de éxito del software en proyecto, podemos clasificar los requerimientos por: entorno, ergonómicos, interface, funcionales, desempeño, disponibilidad, entrenamiento, restricciones de diseño y materiales.
Entre las técnicas que estamos estudiando para la determinación de los requisitos del software tenemos el Método JAD y el Método FPA.
El Método FPA mejora la definición de los requerimientos comunicando requerimientos funcionales. Estima esfuerzo, agenda y costos basado en requerimientos; al evaluar la factibilidad, de un proyecto se administran los cambios, optimizando el mantenimiento y soporte para así medir la productividad y verificar el desarrollo absoluto del sistema.
El Método JPA (Joint Application Development) es más costoso, depende de la unidad del grupo concerniente al tamaño del proyecto, convive de las metas comunes y de las ideas comunes, es peferida por las compañías por el gran desempeño en los nuevos sistemas para llevarlos a cabo, tanto desarrolladores como usuarios son participantes activos.
Los métodos antes descritos no son más que diferentes técnicas exploratorias para la organización de las etapas que implican la realización de un software. En el caso del método JAD, este se organiza en cinco roles
·         Patrocinador del proyecto: es quien presupuesta el proyecto y proporciona los recursos necesarios para apoyar el proyecto en cuanto a personal técnico, selección de casos de prueba, funcionalidad y evaluación del sistema.
·         Líder del proyecto: podría llamarse el experto que tiene un conocimiento a fondo del área comercial objeto de estudio y de los sistemas de información relacionados con el proyecto y encargado de que las reuniones del equipo de trabajo se reúnan de acuerdo a lo planificado, asegurarse de que se ejecuten las tareas pautadas y en la línea de tiempo estipulada. En otras palabras esta persona es el coordinador de cada uno de los integrantes del equipo que realizan el sistema.
·         Registrador: es quien realiza un resumen conciso de las discusiones y decisiones, en palabras coloquiales seria el cronista, ya que es él quien permite que en los momentos en que el sistema llega a un punto complejo revisar el cuándo y por qué se tomo cierta decisión, lo que contribuye a que el equipo puede reorientarse hacia los objetivos originalmente propuestos.
·         Time keeper: es el responsable de asegurar que se cumpla la agenda establecida a fin de optimizar el tiempo. También son los responsables de todos los materiales necesarios que se necesiten durante la sesión.
·         Clientes: estos son sumamente importante pues son ellos los que conocen como deberá funcionar el sistema y cómo se usa. Ellos ayudaran al equipo a comprender las tareas manipuladas por el sistema.
Sin duda alguna que el comprender este aspecto de la ingeniería de software nos permitirá aumentar las probabilidades de éxito del sistema en que estemos trabajando. La interacción por sí sola de los diferentes elementos que están involucrados en el análisis, diseño y desarrollo de un sistema no garantiza el éxito del mismo, sino más bien la aplicación correcta de un método práctico que garantice la organización y consecución de los objetivos planteados al momento de finalmente decidir realizar el diseño de un software.


Fuente Bibliográfica

Ginesta, M.G. y González, A.P. (2005). Ingeniería del Software en Entornos de SL. UOC Formación de Posgrado.

Pressman, R.S. (2002). Ingeniería del Software. Un enfoque práctico. Quinta Edición. México: Mc Graw Hill.

Quizhpe, C.A. y Ramírez S.L. (2009). Ingeniería de Requisitos2621. Universidad Técnica Particular de Loja. Escuela de Ciencias de la Computación.

Rodríguez, N. (2010). Ingeniería del Software: Levantamiento y Recolección de Requerimientos. Extraído el 06 de febrero de 2011 desde www.slideshare.net