Universidad Nacional Experimental de los Llanos Occidentales ......2018/05/04 · (MEDSI – Jonas...
Transcript of Universidad Nacional Experimental de los Llanos Occidentales ......2018/05/04 · (MEDSI – Jonas...
Universidad Nacional Experimentalde los Llanos Occidentales “Ezequiel
Zamora”Barinas, Estado Barinas
LA UNIVERSIDAD QUE SIEMBRA
Prof. Darjeling SilvaEstudiantes:
Quintero Jesús D. C.I.22.114.321Ramos Carlos C.I.22.983.208Carrera: Ing. en Informática.Semestre:VII.Sección: 01D.
Barinas, marzo de 2.014
MEDSI
Jonas Montilva (1983)
Es Estructurada.
Es Completa.
Es Particionada.
Es Modificable y Adaptable.
MEDSI
Fases:
1. Definición del Proyecto.
2. Análisis del Contexto.
3. Definición de Requerimientos.
4. Diseño Preliminar.
5. Diseño Detallado.
6. Construcción del Sistema.
7. Control de Programas
8. Prueba de Aceptación.
CICLO DE VIDA DE MEDSI.
FASE 1: DEFINICIÓN DEL PROYECTO.
Descripción del Sistema Actual.
Formulación del Problema.
SISTEMA AUTOMATIZADO PARA EL
CONTROL DE TURNOS DE LOS
USUARIOS DE HIDROANDES (SACOTUS).
Estudio de Factibilidad Factibilidad Técnica.
1). Procesador INTEL CORE DUO de 1.8 GHz2). 1Gb en RAM.3). 120 Gb de disco duro.4). Monitor de Pantalla Pana 25 pulgadas.5). Sistema Operativo Windows XP Servipack 3.
Factibilidad Económica.
Factibilidad Operativa.
Planificación del Proyecto.
Objetivo General.
Desarrollar un sistema de control automatizado para
mejorar el servicio de la espera de los clientes y la
organización de los turnos para pasar a las taquillas de la
Oficina de Servicios Públicos de Hidroandes.
Objetivos Específicos. Mejorar el servicio de la espera de los clientes y la
organización de los turnos para pasar a las taquillas de la
Oficina de Servicios Públicos de Hidroandes.
Agilizar los procesos y tareas para ofrecer un servicio de
calidad a los clientes.
Modernizar las estructuras organizando la atención al cliente
mediante la incorporación de nuevas tecnologías.
Desarrollar un sistema de control automatizado para mejorar el
servicio de la espera de los clientes y la organización de los
turnos.
PROPÓSITOS. Automatizar el control de turnos.
Generar un ambiente armonioso.
Clasificar los usuarios por el tipo de operación a realizar.
Ordenar de forma eficiente los turnos de espera.
Mejorar la calidad de espera.
BENEFICIOS.Mayor facilidad de organizar los turnos al momento de
espera.
Facilidad y rapidez al momento de elegir una operación.
Mayor interacción entre el usuario y la operación.
Ofrece un ambiente de respeto entre los usuarios.
Ofrece prioridades a los adultos mayores y personas con
discapacidad física.
FASE 2: ANÁLISIS DEL CONTEXTO.
FASE 2: ANÁLISIS DEL CONTEXTO.
FASE 2: ANÁLISIS DEL CONTEXTO.
FASE 3: DEFINICIÓN DE
REQUERIMIENTOS.
Especificación de Requerimientos
Requerimientos de Información.
Requerimientos funcionales.
Requerimientos de restricciones y atributos.
ATRIBUTOS DE CALIDAD
Según las normas ISO/IEC 9126 del año 2001
Funcionalidad.
Fiabilidad.
Usabilidad.
Eficiencia.
Mantenibilidad.
Portabilidad.
FASE 4: DISEÑO PRELIMINAR.
FASE 4: DISEÑO PRELIMINAR.
FASE 4: DISEÑO PRELIMINAR.
FASE 5: DISEÑO DETALLADO.
SACOTUS
Tomar Ticket
Taquilla Preferencial
Operaciones de Taquilla
Gestionar Reclamos
Atender
Taquilla Preferencial
Taquilla Reclamos
Inicio
Carta Estructurada (Nivel General).
FASE 6: CONSTRUCCIÓN DEL
SISTEMA
FASE 6: CONSTRUCCIÓN DEL
SISTEMA
FASE 7: CONTROL DE
PROGRAMAS.934 por 488 pixeles.
Pantalla de tomar un número
Pantalla de tomar un número
Pantalla de atender taquillas.
Pantalla de atender taquillas.
Pantalla de atender taquillas.
Botón de inicio.
FASE 8: PRUEBAS DE
ACEPTACIÓN
Implantación del Sistema Automatizado
para el Control de los Turno de los
Usuarios en la Oficina de Servicios
Públicos de Hidroandes Sector Centro del
Estado Barinas.
Metodología AgEnD Schenone
Marcelo Hernán 2004
Destacar en cada una de susprácticas las personas son las queindudablemente decidirán sobrela mejor forma de trabajo paraellas.
El nombre de la metodología esAgEnD que significa desarrollomejorado por agilidad
Está enfocada a pequeños gruposde desarrollo, de no más de 15personas involucradas en elproyecto
Crear proceso de desarrollo queresulte fácil de implementar ybasar el mismo en la aplicaciónde prácticas ágiles para contribuira la construcción del software
AgEdn
Utilizarán las técnicas que lessean más efectivas para llegaral final de la iteración con losartefactos construidos deacuerdo a las estimaciones
Aplica un desarrollo de cajanegra
La motivación la que nospermitirá lograr mejoresresultados en la adopción deun proceso ágil.
Lograr que el desarrollo decaja negra tenga éxitodeberemos tener un equipointegrado, balanceado yaltamente motivado
AgEdn
Metodología AgEnD Schenone
Marcelo Hernán 2004
Estructura
Fue concebida con la idea de ser aplicada enpequeños grupos de desarrollo, sin necesidad deinvertir en costosas herramientas o de capacitar enforma extensiva a las personas involucradas.
AgEnD no prescribetécnicas salvo enalgunos casos enparticular en que sonmencionadas enconjunto con lasactividadescorrespondientes.
AgEnD no prescribe ningún tipo de herramienta para llevar a cabo las actividades
AgEnD no prescribe estándares de ningún tipo para los entregables
Fases
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Fases
Concepción
Consiste en la definición que tendrá la aplicación, el
alcance de la misma, la identificación de los
stakeholders, la customización.
Fases
Elaboración
Se refiere a la exploración de los requerimientos más
críticos (funcionales y no funcionales) que involucra el
proyecto, así como las decisiones técnicas más
importantes que quedarán plasmadas en el documento
de Arquitectura.
Fases
Construcción
Se terminan de especificar los casos de uso
correspondientes a la iteración, se diseñan los mismos
bajo la arquitectura candidata presentada, se codifican
todos los componentes definidos por los casos de uso,
ejecutándose el testing correspondiente y la
integración.
Fases
Transición
Se llevarán a cabo las actividades de despliegue
necesarias y se evalúa lo realizado contra las
expectativas del Cliente y del Equipo de Desarrollo.
Disciplinas de AgEnD
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Factibilidad
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Requerimientos de Análisis
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Diseño
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Implementación
Se lleva a cabo la producción del Software, el equipo
de desarrollo se encarga de implementar las
funcionalidad mediante el lenguaje de programación
elegido, algunos lenguajes sugeridos por AgEnD son:
Java, MS. NET o Smalltalk.
Pruebas Unitarias: Controlan la calidad del código
construido.
Pruebas Funcionales: Son usadas durante todo el
desarrollo.
Pruebas de Aceptación: Se lleva a cabo durante las
Iteraciones con Release donde se lleva a cabo la
transición de la aplicación al ambiente del cliente.
Despliegue
Permite que el sistema construido sea transferido al
ambiente de producción para ser utilizado por el
usuario.
Generar Manuales del Usuario, de Operación, etc.
Capacitar a los Usuarios que utilizarán el nuevo
sistema.
Realizar un empaquetamiento de componentes junto
con scripts de instalación que el Cliente utilice para
instalar la aplicación en su entorno.
Despliegue
Esquema Cronológico de entregas de una versión del
sistema
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Diagrama de Actividad
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Ejemplos – Diagramas
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Diagrama de despliegue
Diagrama de componentes
Ejemplos – Diagramas
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Diagrama de estado
Diagrama de secuencia
Ejemplos – Diagramas
Diseño de una Metodología Ágil de Desarrollo de Software. Schenone Marcelo Hernán, Tesis de Grado en Ingeniería en Informática, Facultad de Ingeniería, Universidad
de Buenos Aires. 2004
Diagrama de datos
Diagrama de clases
“El no involucrar al usuario durante
el desarrollo de software nos permite
construir un producto de software
que sólo cumple las necesidades de
aquellas personas que no van a
utilizarlo”.
Standish, 1994
LA UNIVERSIDAD QUE SIEMBRA
Universidad Nacional Experimental
De los Llanos Occidentales
“Ezequiel Zamora”
Barinas, Estado Barinas
SACOTUS (Aplicando MEDSI)
Metodología del Software
Prof. Darjeling Silva.
Estudiantes:
Quintero Jesús D. C.I.22.114.321
Ramos Carlos C.I.22.983.208
Carrera: Ing. en Informática.
Semestre: VII.
Sección: 01D.
Barinas, marzo de 2014
Índice:
Metodología Estructurada para el Desarrollo de Sistemas de Información 1
Fase 1 3
Fase 2 9
Fase 3 12
Fase 4 15
Fase 5 18
Fase 6 23
Fase 7 35
Fase 8 39
Presentación de AgEnD (Metodología Actual) 40
Referencias Bibliográficas 48
1 | P á g i n a
Metodología Estructurada para el Desarrollo de Sistemas de Información
(MEDSI – Jonas A. Montilva C. 1983)
MEDSI es una metodología creada por Jonas Montilva, la cual está estructurada
para desarrollar sistemas de información en y para organizaciones de cualquier tipo. Entre
las características resaltantes de esta metodología podemos destacar:
Es Estructurada. Esta característica se debe a dos razones esenciales, la primera es que
utiliza diferentes métodos y técnicas estructuradas, que son propias de la Ingeniería de la
Programación, y que han demostrado ser las más eficientes y eficaces para el desarrollo de
sistemas programados, y en segundo lugar guía paso a paso de arriba hacia abajo el grupo
que la aplica explicando primero de forma muy general lo que debe hacerse para luego
entrar en los detalles, a medida que se avanza hasta explicar las tareas esenciales que el
grupo debe llevar a cabo para realizar el sistema de información.
Es Completa. Cubre todas las distintas fases del ciclo de desarrollo de un sistema de
información, desde la definición del proyecto hasta la implantación del sistema en la
organización. Guía al grupo de desarrollo a través de las fases, a un nivel bastante
detallado, explicando las actividades que deben hacerse y en la mayoría de los casos,
enumerando las tareas específicas que los miembros del grupo deben efectuar.
Es Particionada. A fin de manipular mejor la inherente a un proyecto de este tipo, la
metodología se divide en fases, y cada una de las fases está compuesta por pasos los cuales
están orientados a algún tipo de tópicos, aspecto o elemento de un sistema de información.
Cada paso a su vez agrupa a un conjunto de actividades que han de ser realizadas por el
grupo de desarrollo.
Es Modificable y Adaptable. El grupo de desarrollo puede modificar fácilmente la
metodología, bien para introducir nuevos elementos como para eliminar algunos. De igual
modo, puede adaptarla a las condiciones, exigencias y características de la organización
donde se utilice o a cualquier otro tipo de proyecto de sistemas de información.
2 | P á g i n a
CICLO DE VIDA DE MEDSI.
(Metodología Estructurada para el Desarrollo de Información)
3 | P á g i n a
FASE 1: DEFINICIÓN DEL PROYECTO.
SISTEMA AUTOMATIZADO PARA EL CONTROL DE TURNOS DE LOS
USUARIOS DE HIDROANDES (SACOTUS).
SITUACIÓN ACTUAL
DESCRIPCIÓN DEL SISTEMA ACTUAL
El sistema actual que utiliza la Oficina de Servicios Públicos de Hidroandes ubicada
en el sector centro del estado Barinas organiza su lista de espera de personas mediante una
fila, que se extiende a lo largo de la oficina mientras los usuarios se van ubicando de
acuerdo a su respectivo orden de llegada.
El proceso que se lleva a cabo en la actualidad para la atención y control de turno de
los usuarios o personas que acuden a realizar las diferentes operaciones y servicios que se
prestan en esta oficina de servicios públicos ocurre de la siguiente manera:
Las personas se dirigen a la oficina, y una vez estando dentro pasan a ser ubicados
por el vigilante o portero, el cual le indica la fila correspondiente a la operación que el
usuario está dispuesto a realizar, una vez ubicada la persona en su fila conveniente debe
esperar de pie su respectivo turno sin saber el tiempo que demore el operador de servicios
en atenderlo.
En el caso de las personas que pertenecen al grupo que se contempla como atención
preferencial en cualquier organización entre los cuales tenemos (tercera edad o también
llamados adultos mayores, personas con discapacidad, mujeres en estado de embarazo y
personas con problemas de obesidad), deben realizar de la misma forma mencionada
anteriormente, el procedimiento para esperar su turno sin tener prioridades debido a su
condición.
4 | P á g i n a
FORMULACIÓN DEL PROBLEMA
El sistema actual que se utiliza en la Oficina de Servicios Públicos de Hidroandes
ubicada en el sector centro del estado Barinas para la atención y la organización de los
turnos de espera de los usuarios que acuden a realizar el pago de los recibos y los reclamos
presentados por los inconvenientes del servicio público; se realiza mediante filas que se
conforman con cada uno de los usuarios que pasan a ubicarse en ella de acuerdo al orden en
el que van llegando a la oficina.
Este sistema que se está utilizando en esta Oficina de Servicios genera una serie de
problemas e incomodidades al momento en que los usuarios se encuentran formados en la
fila en la cual esperan su turno, los cuales son:
Agotamiento físico.
Dolores musculares.
Limitaciones de movimiento debido a espacios estrechos.
Aumento de la temperatura dentro de las instalaciones de la oficina.
Falta de oxigeno por la multitud de personas que se presentan en la oficina.
Pérdida de tiempo al momento de la espera.
Incomodidad por falta de aseo personal (presentada en algún usuario).
Altercados entre algunos usuarios por intentar saltar su posición en la fila.
5 | P á g i n a
ENCUSTAS.
¿Piensa usted que el espacio que posee la Oficina de Servicios Públicos de Hidroandes
Sector Centro es lo suficientemente grande para realizar filas de espera?
Realizada a un grupo de 30 usuarios obteniendo de esta manera las siguientes
respuestas:
24 personas respondieron NO.
6 personas dijeron SI.
Respuestas
NO (80%)
SI (20%)
6 | P á g i n a
¿Piensa usted que implementar un sistema automatizado para controlar el turno de
los usuarios dentro de la oficina de Hidroandes ayudaría a mejorar el problema que
se presentan al realizar las filas?
Realizada a un grupo de 30 usuarios obteniendo de esta manera las siguientes
respuestas:
27 personas respondieron SI.
3 personas dijeron NO.
Respuestas
SI (90%)
NO (10%)
7 | P á g i n a
¿Posee usted los conocimientos en computación necesarios como para manejar un
sistema de información?
Realizada a un grupo de 6 operadores los cuales son los encargados de atender
las taquillas (de forma rotativa), obteniendo de esta manera las siguientes respuestas:
6 operadores respondieron SI.
Respuestas
SI (100%)
8 | P á g i n a
¿Les gustaría utilizar un sistema automatizado que permita manejar el control de
turno de los usuarios en las diferentes taquillas de atención que posee la oficina?
Realizada a todos los trabajadores de la oficina (18 trabajadores en total),
obteniendo las siguientes respuestas:
16 trabajadores respondieron SI.
2 trabajadores respondieron NO.
Respuestas
SI (88,89 %)
NO (11,11 %)
9 | P á g i n a
ESTUDIO DE FACTIBILIDAD.
Factibilidad Técnica.
Para la manipulación del SISTEMA AUTOMATIZADO PARA EL CONTROL DE
TURNOS DE LOS USUARIOS (SACOTUS) la Oficina de Servicio Públicos de
Hidroandes sector centro del estado Barinas cuenta 7 equipos genéricos con las siguientes
características:
Procesador INTEL CORE DUO de 1.8 GHz
1Gb en RAM.
120 Gb de disco duro.
Monitor de Pantalla Pana 25 pulgadas.
Sistema Operativo Windows XP Servipack 3.
Otros componentes adicionales que mejoraran la implementación del sistema propuesto
dentro de la oficina de servicios públicos son: un UPS de 550va marca CDP, cable UTP
categoría 5 no apantallado, Switch de 16 puertos de red y conectores RJ-45, además de esto
cuentan con un equipo (de los 7 antes mencionados) desincorporado que se utilizara para
implementación del sistema.
Factibilidad Económica.
Para que la oficina de Servicios Públicos de Hidroandes ubicada en el sector centro
del estado Barinas pueda implementar el SISTEMA AUTOMATIZADO PARA EL
CONTROL DE TURNOS DE LOS USUARIOS (SACOTUS) debe adquirir un dispositivo
para imprimir el ticket con el turno de espera. El dispositivo propuesto es:
IMPRESORA TICKET TOSHIBA TERMICA TRST-A00 NEGRA con Velocidad
170mm/s, conexión USB
La oficina cuenta con un equipo de computación cuyo rendimiento y velocidad de
transmisión de datos bastante aceptable para el volumen procesos que allí se maneja, con la
que viene a reducir considerablemente los costos de la implementación del sistema y así
mismo poder automatizar el proceso.
10 | P á g i n a
Factibilidad Operativa.
La implantación de un sistema automatizado en cualquier organización puede
ocasionar una aceptación o rechazo al cambio tecnológico expuesto esto quiere decir que
crear un impacto social por lo cual se realizaron entrevistas directas con el personal, para
determinar si existen incertidumbres hacia este cambio.
El alcance del sistema a implantar significa una base a nivel social debido a que su
sistema cumple todos los requerimientos para operar.
La aceptación de un sistema es indiscutible, actuando en forma positiva para el
mejoramiento y funcionamiento en cuanto al Control y Atención de Turnos de los Usuarios.
11 | P á g i n a
PLANIFICACIÓN DEL PROYECTO.
SISTEMA AUTOMATIZADO PARA EL CONTROL DE TURNOS DE LOS
USUARIOS DE HIDROANDES (SACOTUS)
Con el funcionamiento del sistema propuesto para la automatización del proceso de
control y organización de turnos de la Oficina de Servicios Públicos Hidroandes ubicada en
el sector centro del estado Barinas, lo que se pretende lograr es el mejoramiento de la
organización en la espera de los turnos de los usuarios, así como también la clasificación
correspondiente de los turnos para poder pasar a ser atendidos en las taquillas destinadas a
cumplir con las operaciones que se disponen a realizar los usuarios en la oficina.
OBJETIVO GENERAL:
Desarrollar un sistema de control automatizado para mejorar el servicio de la espera
de los clientes y la organización de los turnos para pasar a las taquillas de la Oficina de
Servicios Públicos de Hidroandes.
OBJETIVOS ESPECÍFICOS:
1. Mejorar el servicio de la espera de los clientes y la organización de los turnos para
pasar a las taquillas de la Oficina de Servicios Públicos de Hidroandes.
2. Agilizar los procesos y tareas para ofrecer un servicio de calidad a los clientes.
3. Modernizar las estructuras, organizando la atención al cliente mediante la
incorporación de nuevas tecnologías.
4. Desarrollar un sistema de control automatizado para mejorar el servicio de la espera
de los clientes y la organización de los turnos.
12 | P á g i n a
PROPÓSITOS:
Automatizar el control de turnos.
Generar un ambiente armonioso.
Clasificar los usuarios por el tipo de operación a realizar.
Ordenar de forma eficiente los turnos de espera.
Mejorar la calidad de espera.
BENEFICIOS:
Mayor facilidad de organizar los turnos al momento de espera.
Facilidad y rapidez al momento de elegir una operación.
Mayor interacción entre el usuario y la operación.
Ofrece un ambiente de respeto entre los usuarios.
Ofrece prioridades a los adultos mayores y personas con discapacidad física.
13 | P á g i n a
FASE 2: ANÁLISIS DEL CONTEXTO.
DIAGRAMA DE FLUJO DEL SISTEMA ACTUAL.
Inicio del
Proceso
Espera Turno en
la Fila
Pasa a ser
Atendido
Fin del
Proceso
10 | P á g i n a
DIAGRAMA CONTEXTUAL DEL SISTEMA ACTUAL.
0
CONTROL DE TURNO
DE USUARIOS
Usuario
.
Usuario
Se ubica
por orden
de llegada
en la fila
Pasa a ser
atendido
OFICINA DE SERVICIOS PÚBLICOS DE
HIDROANDES SECTOR CENTRO – BARINAS.
11 | P á g i n a
DIAGRAMA EXPANDIDO DEL SISTEMA ACTUAL DE CONTROL DE TURNOS.
1
Usuario Usuario
1.1
Se ubica por
orden de llegada
en la fila
1.2
Pasa a ser
atendido
OFICINA DE SERVICIOS PÚBLICOS DE HIDROANDES SECTOR CENTRO -
BARINAS
12 | P á g i n a
FASE 3: DEFINICIÓN DE REQUERIMIENTOS
La especificación de los requerimientos es para saber cómo trabaja el sistema actual
y si es necesario efectuar mejoras.
Para implementar un sistema se debe realizar un estudio previo de los procesos
actuales para así detectar las fallas en el sistema actual y determinar cuáles serán las
operaciones necesarias que permitan resolverlas.
ESPECIFICACIÓN DE REQUERIMIENTOS DE INFORMACIÓN.
Requerimientos de Entrada:
En el sistema propuesto se encuentran los requerimientos básicos de entrada que se
especifican a continuación:
Para pago de recibo: Específicamente (personas sin un impedimento físico) es una
petición que se le hace al dispositivo para obtener el número del correspondiente.
Para pago de recibo: Específicamente atención preferencial (tercera edad, personas
con discapacidad, mujeres en estado de embarazo y personas con problemas de
obesidad) es una petición que se le hace al dispositivo para obtener el número del
turno correspondiente.
Para realizar reclamos: (público en general) es una petición que se le hace al
dispositivo para obtener el número del turno correspondiente.
Para atender un turno: Es una petición realizada por el operador o encargado de la
atención al sistema, para que éste haga el llamado a un turno correspondiente a la
numeración la cual que le fue asignada a un usuario al momento de seleccionar la
operación a realizar.
13 | P á g i n a
Requerimientos de Salida:
Son las impresiones físicas arrojados por el sistema automatizado, las cuales son:
Ticket para pago de recibo (personas sin un impedimento físico).
Ticket para pago de recibo (adultos mayores y personas con discapacidad).
Ticket para realizar reclamos (público en general).
Impresión por pantalla del número correspondiente al turno llamado para ser
atendido.
ESPECIFICACIÓN FUNCIONAL DEL NUEVO SISTEMA.
Entre estos procedimientos se ubican las funciones que el nuevo sistema debe
ejecutar.
Procesamiento de transacción: Entre estos requerimientos el sistema propuesto
permitirá al personal de la Oficina hacer el llamado a los usuarios que hayan
adquirido su ticket.
Generación de reportes: Permite originar el comprobante que es requerido y
transmitirlo a los usuarios que lo soliciten, se puede producir mediante papel.
ESPECIFICACIONES DE RESTRICCIONES Y ATRIBUTOS.
En este paso se estableció junto con el personal las restricciones bajo las cuales se
debe desarrollar y debe operar el nuevo sistema de información, así como también se
establecieron los atributos de calidad que debe satisfacer el nuevo sistema.
Restricciones:
En cuanto a las restricciones para el desarrollo del nuevo sistema se encuentran las
de carácter económico y técnico, las cuales no son superadas debido a que el hardware y el
software que posee la Oficina actualmente son suficientes para el desarrollo del nuevo
sistema. Los elementos adicionales necesarios, se considera que la Oficina se encuentra en
14 | P á g i n a
capacidad de adquirirlos, tal como es el caso de la máquina de ticket: IMPRESORA
TICKET TOSHIBA TERMICA TRST-A00 NEGRA, Velocidad 170mm/s, conexión USB
En lo que concierne al personal necesario, la Oficina dispone del personal suficiente
para operar y mantener el nuevo sistema, debido a que poseen la información técnica
mínima necesaria para tal efecto.
Atributos de Calidad
El sistema propuesto debe responder a una serie de atributos que garanticen
ampliamente la calidad del mismo, según las normas ISO/IEC 9126 del año 2001, el
sistema propuesto cumple con las siguientes características:
Funcionalidad: El sistema propuesto cuenta con las habilidades necesarias para
llevar a cabo y de manera eficiente cada uno de los procesos para el cual fue
diseñado.
Fiabilidad: El sistema cuenta con una estructura confiable que minimiza la
presencia fallos casi a su totalidad.
Usabilidad: El sistema cuenta con la capacidad de ser aprendido, atendido y usado
por el personal de la oficina y brinda un diseño atractivo a la hora de ser utilizado.
Eficiencia: El sistema proporciona las respuestas de sus procesos en tiempos
bastante rápidos, gracias a su estructura interna.
Mantenibilidad: El sistema cuenta con la capacidad de ser modificado, tanto para
incluir correcciones como para mejoras o adaptaciones de nuevos procesos.
Portabilidad: El sistema es capaz de coexistir con otro software independiente en un
entorno en común y es capaz ser instalado en un entorno especificado.
15 | P á g i n a
FASE 4: DISEÑO PRELIMINAR.
DIAGRAMA DE FLUJO DEL SISTEMA PROPUESTO.
NO
Inicio del
Proceso
Selecciona la
Operación
Genera el Ticket
con el Turno
Existen
Usuarios
Fin del
Proceso
SI
Atiende Taquilla
Turno a Atender
y Usuarios en
Espera
Fin del
Proceso
Operador de Taquilla
16 | P á g i n a
DIAGRAMA CONTEXTUAL DEL SISTEMA PROPUESTO.
0
SISTEMA AUTOMATIZADO
PARA EL CONTROL DE
TURNOS DE LOS USUARIOS
DE HIDROANDES (SACOTUS)
Usuario Usuario
Operador Operador
Solicitud
de ticket
Atender
Usuario
Emisión
de
ticket
Turno a
atender
OFICINA DE SERVICIOS PÚBLICOS DE HIDROANDES SECTOR
CENTRO - BARINAS
17 | P á g i n a
DIAGRAMA EXPANDIDO DEL SISTEMA PROPUESTO DE CONTROL DE TURNOS.
1
Usuario Usuario
Operador Operador
1.1
Selección de
Operación
1.3
Atender Taquilla
1.2
Generación de Ticket
1.4
Turno a Atender y
Usuarios en Espera
OFICINA DE SERVICIOS PÚBLICOS DE HIDROANDES SECTOR
CENTRO - BARINAS
18 | P á g i n a
FASE 5: DISEÑO DETALLADO.
En este paso se elaboro minuciosamente el diseño de la interacción entre el usuario
y la maquina, de la misma manera se especifica separadamente el diseño del sistema de
información que se encontrará en la oficina de servicios públicos.
Diseño de Entradas y Salidas:
En diseño de entradas y salidas que se especifica a continuación se establece
inicialmente en la carta estructurada que representa las opciones con las cuales contara el
nuevo sistema, describiendo las acciones pertinentes de cada opción.
19 | P á g i n a
CARTA ESTRUCTURADA (NIVEL GENERAL):
SACOTUS
Tomar Ticket
Taquilla Preferencial
Operaciones de Taquilla
Gestionar Reclamos
Atender
Taquilla Preferencial
Taquilla Reclamos
Inicio
20 | P á g i n a
CARTA ESTRUCTURADA (NIVEL DE USUARIO):
Tomar Ticket
Taquilla Preferencial
Operaciones de Taquilla
Gestionar Reclamos
21 | P á g i n a
CARTA ESTRUCTURA (NIVEL DE OPERADOR):
Atender
Taquilla Preferencial
Taquilla Reclamos
22 | P á g i n a
DESCRIPCIÓN DE LOS MÓDULOS.
Módulo Tomar Ticket: En este módulo el sistema genera una pantalla en la cual
aparecen las operaciones a realizar, se subdivide en taquilla preferencial,
operaciones de taquilla y gestionar reclamos.
Módulo Atender: En este modulo se subdivide en taquilla preferencial, taquilla y
reclamos; de manera tal que al acceder a este módulo se presenta una pantalla en la
cual los operadores encargados de atender a los usuarios puedan realizar su trabajo
seleccionándolos de acuerdo a la operación que les corresponda.
Módulo Inicio: Este módulo se presenta en forma de botón, permitiéndoles a los
usuarios y operadores regresar a la pantalla principal.
23 | P á g i n a
FASE 6: CONSTRUCCIÓN DEL
SISTEMA.
CODIFICACIÓN DEL SISTEMA.
Public Class Form2
Public i = 0, w = 0, j = 0, r = 0, t = 0, k
= 0, c, d, con As Integer
Public taquilla1(100), taquilla2(100),
taquilla3(100) As Integer
'PRINCIPAL
Public Sub Form2_Load(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles
MyBase.Load
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' TOMANDO NUMEROS
Public Sub btn1_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btn1.Click
' esta es el de tomar un numero
(mostrando)
24 | P á g i n a
lblt1.Show()
lblt2.Show()
lblt3.Show()
btnt1.Show()
btnt2.Show()
btnt3.Show()
' esta es el principal (ocultando)
lbl1.Hide()
btn1.Hide()
lbl3.Hide()
btn3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' esta es la taquilla 1
Public Sub btnt1_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btnt1.Click
Dim pos As Integer
i = i + 1
w = w + 1
taquilla1(i) = w
pos = i - 1
MsgBox("Tiene el Número: " & w
& " y tiene: " & pos & " Persona(s) por
delante", MsgBoxStyle.Information)
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
25 | P á g i n a
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' esta es la taquilla 2
Private Sub btnt2_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btnt2.Click
Dim pos As Integer
j = j + 1
r = r + 1
taquilla2(j) = r
pos = j - 1
MsgBox("Tiene el Número: " & r &
" y tiene: " & pos & " Persona(s) por
delante", MsgBoxStyle.Information)
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
26 | P á g i n a
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' esta es la taquilla 3
Private Sub btnt3_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btnt3.Click
Dim pos As Integer
k = k + 1
t = t + 1
taquilla3(k) = t
pos = k - 1
MsgBox("Tiene el Número: " & t &
" y tiene: " & pos & " Persona(s) por
delante", MsgBoxStyle.Information)
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
'MOSTRANDO TAQUILLAS
Private Sub btn2_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs)
27 | P á g i n a
' esta es el principal (ocultando)
lbl1.Hide()
btn1.Hide()
lbl3.Hide()
btn3.Hide()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' esta es la taquilla 1
Private Sub btnm1_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs)
MsgBox("En la Taquilal de
Atención Preferencial hay: " & i & "
Personas(s) en espera",
MsgBoxStyle.Exclamation)
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
28 | P á g i n a
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' esta es la taquilla 2
Private Sub btnm2_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs)
MsgBox("En la Taquilal de
Atención Preferencial hay: " & j & "
Personas(s) en espera",
MsgBoxStyle.Exclamation)
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' esta es la taquilla 3
Private Sub btnm3_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs)
MsgBox("En la Taquilal de
Atención Preferencial hay: " & k & "
Personas(s) en espera",
MsgBoxStyle.Exclamation)
' esta es el principal (mostrando)
29 | P á g i n a
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
'ANTENDER TAQUILLAS
Private Sub btn3_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btn3.Click
' esta es el de atender (mostrando)
lbla1.Show()
lbla2.Show()
lbla3.Show()
btna1.Show()
btna2.Show()
btna3.Show()
' esta es el principal (ocultando)
lbl1.Hide()
btn1.Hide()
lbl3.Hide()
btn3.Hide()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
30 | P á g i n a
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
End Sub
' esta es la taquilla 1
Private Sub btna1_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btna1.Click
If i = 0 Then
MsgBox("No hay Clientes para
Atender", MsgBoxStyle.Critical)
Else
c = w - 1
i = i - 1
For p = 0 To c
taquilla1(p) = taquilla1(p + 1)
Next
MsgBox("Es el Turno del
Número: " & taquilla1(0) & " y faltan: "
& i & " Persona(s)",
MsgBoxStyle.Information)
End If
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
31 | P á g i n a
End Sub
' esta es la taquilla 2
Private Sub btna2_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btna2.Click
If j = 0 Then
MsgBox("No hay Clientes para
Atender", MsgBoxStyle.Critical)
Else
d = r - 1
j = j - 1
For p = 0 To d
taquilla2(p) = taquilla2(p + 1)
Next
MsgBox("Es el Turno del
Número: " & taquilla2(0) & " y faltan: "
& j & " Persona(s)",
MsgBoxStyle.Information)
End If
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
' esta es la taquilla 3
Private Sub btna3_Click(ByVal sender
As System.Object, ByVal e As
System.EventArgs) Handles btna3.Click
32 | P á g i n a
If k = 0 Then
MsgBox("No hay Clientes para
Atender", MsgBoxStyle.Critical)
Else
con = t - 1
k = k - 1
For p = 0 To con
taquilla3(p) = taquilla3(p + 1)
Next
MsgBox("Es el Turno del
Número: " & taquilla3(0) & " y faltan: "
& k & " Persona(s)",
MsgBoxStyle.Information)
End If
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
Private Sub Button1_Click(ByVal
sender As System.Object, ByVal e As
System.EventArgs) Handles
Button1.Click
' esta es el principal (mostrando)
lbl1.Show()
btn1.Show()
33 | P á g i n a
lbl3.Show()
btn3.Show()
' esta es el de tomar un numero
(ocultando)
lblt1.Hide()
lblt2.Hide()
lblt3.Hide()
btnt1.Hide()
btnt2.Hide()
btnt3.Hide()
' esta es el de atender (ocultando)
lbla1.Hide()
lbla2.Hide()
lbla3.Hide()
btna1.Hide()
btna2.Hide()
btna3.Hide()
End Sub
End Class
34 | P á g i n a
DISEÑO DEL SISTEMA:
El sistema de la Oficina se Servicios Públicos de Hidroandes, está diseñado de
una manera bastante básico lo mas entendible posible ya que se trabajara con
personas de avanzada edad. De manera general el diseño es un formulario de Visual
Basic 2010 con una resolución aproximada de 938 por 488 de la siguiente manera:
Sección 1
Pertenece al
botón de
inicio.
Sección 2
Pertenece al encabezado del sistema.
Sección 3
Contiene las opciones que van cambiando dependiendo de las operaciones.
Si se selecciona alguna de las operaciones de la sección tres cambiara solo el
contenido de esa sección, la sección uno y dos son fijas y nunca cambiaran a lo largo
de las operaciones que realice el sistema.
35 | P á g i n a
FASE 7: CONTROL DE PROGRAMAS.
Diseño de Pantallas:
De manera estándar las pantallas están diseñadas en una resolución de 934 por
488 pixeles en donde en la esquina superior izquierda se sitúa el botón de inicio y
más abajo se encuentran las opciones mostradas a continuación.
Menú principal: en esta pantalla se muestran las opciones principales de nuestro
sistema en este caso se ve reflejada las dos opciones que posee, pero para fines de la
implementación el usuario solo tendrá el botón de Tomar un Numero y el operador de
la taquilla el de Atender Taquillas.
36 | P á g i n a
Pantalla de tomar un número: en esta pantalla tenemos tres opciones las cuales el
usuario escogerá dependiendo de la operación que desee realizar
El sistema le arrojara un mensaje de la siguiente manera cuando haiga pulsado
la operación a realizar.
37 | P á g i n a
La pantalla de atender taquillas: esta venta es exclusiva para los operadores de las
taquillas y les permitirá de manera ordenada ir llamando a los números de turnos
correspondientes si existiesen.
Al pulsar una taquilla les mostrara un mensaje con el número a atender y le
reportara cuantos usuarios quedan en espera.
38 | P á g i n a
Si no existiesen usuarios en espera mostraría este mensaje.
El botón de inicio tradicional que la mayoría de usuarios conoce que nos
enviara a la pantalla principal.
39 | P á g i n a
FASE 8: PRUEBAS DE ACEPTACIÓN.
Implantación del Sistema Automatizado para el Control de los Turno de los
Usuarios en la Oficina de Servicios Públicos de Hidroandes Sector Centro del Estado
Barinas.
40 | P á g i n a
METODOLOGIA ACTUAL PARA DESARROLLAR SISTEMAS
DE INFORMACIÓN.
Presentación de AgEnD
(Schenone Marcelo Hernán. 2004).
El nombre de la metodología es AgEnD que significa en inglés Agility
Enhanced Development (Desarrollo Mejorado Por Agilidad). En otras palabras, la
idea es configurar un proceso de desarrollo que resulte fácil de implementar y basar el
mismo en la aplicación de prácticas ágiles para contribuir a la construcción del
software, lidiando con la impredictibilidad de la disciplina.
AgEnD en particular está enfocada a pequeños grupos de desarrollo, de no
más de 15 personas involucradas en el proyecto, las cuales deben compartir un
ambiente de trabajo común, con mínima separación física. Cabe mencionar que en
caso de contar con una mayor cantidad de recursos se deberán particionar en
subgrupos del tamaño antes indicado, trabajando en forma paralela.
El énfasis de todas las metodologías ágiles está centrado en los individuos y
sus interacciones, a diferencia de las metodologías tradicionales en que impera el
proceso y las herramientas como propulsores de la calidad. AgEnD no es ninguna
excepción a estos principios y propone destacar en cada una de sus prácticas que las
personas son las que indudablemente decidirán sobre la mejor forma de trabajo para
ellas. También de las personas dependerá la adopción de AgEnD o cualquier proceso
de desarrollo ágil.
Realizando una analogía con el testing, se podría considerar que AgEnD
aplica lo que denominaremos desarrollo de caja negra mientras que las metodologías
tradicionales utilizan el desarrollo de caja blanca. El primero refiere a la noción de
41 | P á g i n a
tomar ciertas entradas y verificar las correspondientes salidas. El segundo refiere a
tomar ciertas entradas, analizar el proceso interno y verificar las correspondientes
salidas.
Para lograr que el desarrollo de caja negra tenga éxito deberemos tener un
equipo integrado, balanceado y altamente motivado. De estos tres factores, es la
motivación la que nos permitirá lograr mejores resultados en la adopción de un
proceso ágil. Es la motivación la que logra sacar lo mejor de un equipo de desarrollo;
la que nos permite saber que las personas involucradas utilizarán las técnicas que les
sean más efectivas para llegar al final de la iteración con los artefactos más críticos
construidos de acuerdo a las estimaciones. La motivación es por lejos la mayor
contribuyente a la productividad
Estructura
Se verá en detalle cómo está estructurada AgEnD, la metodología ágil que da
una solución al problema del desarrollo de software de alta calidad. En particular la
misma fue concebida con la idea de ser aplicada en pequeños grupos de desarrollo,
sin necesidad de invertir en costosas herramientas o de capacitar en forma extensiva a
las personas involucradas.
Por tratarse de una metodología ágil se intenta minimizar la burocracia que
subyace en la utilización de complejos procesos determinísticos que son utilizados en
proyectos con gran cantidad de recursos.
AgEnD no prescribe técnicas salvo en algunos casos en particular en que son
mencionadas en conjunto con las actividades correspondientes. Esto está dado
por la Orientación a las Personas y a los Productos
42 | P á g i n a
AgEnD no prescribe ningún tipo de herramienta para llevar a cabo las
actividades.
AgEnD no prescribe estándares de ningún tipo para los entregables.
Fases
Como cualquier metodología AgEnD se compone de un conjunto de fases que son
realizadas a lo largo del tiempo, las mismas conforman un período de tiempo
encuadrado entre hitos significativos para el proyecto. Las mismas indican el énfasis
ya propuesto por Barry Boehm en relación a la división en dos perspectivas de
desarrollo. La primera perspectiva ocurre en las primeras iteraciones del proyecto,
cuando se analiza la factibilidad de la ejecución del mismo y se termina con la
obtención de la arquitectura con los riesgos más críticos mitigados. La segunda
perspectiva ocurre en fases iterativas de construcción en donde el énfasis esta en el
código fuente generado. Esto significa que el grado de creatividad requerido en el
proceso disminuye con el tiempo, tornándose en un ciclo más predecible. En relación
a la definición de fases e hitos de AgEnD se han tomado dos fuentes importantes
Boehm, 1995 y RUP, 2002.
La primera fase denominada Concepción que consiste en la definición de
los features que tendrá la aplicación, el alcance de la misma, la identificación
de los stakeholders, la customización. La fase de Concepción finaliza con un
hito mayor denominado Objetivos del Ciclo de Vida en el que se evalúa lo
realizado contra las expectativas del Cliente y del Equipo de Desarrollo.
La siguiente fase denominada Elaboración, se refiere a la exploración de
los requerimientos más críticos (funcionales y no funcionales) que involucra
43 | P á g i n a
el proyecto, así como las decisiones técnicas más importantes que quedarán
plasmadas en el documento de Arquitectura. El objetivo principal consiste en
asegurar la factibilidad técnica respecto a la realización del proyecto. La fase
de Elaboración finaliza con un hito mayor denominado Arquitectura del Ciclo
de Vida en el que se evalúa lo realizado contra las expectativas del Cliente y
del Equipo de Desarrollo.
Durante la Construcción se terminan de especificar los casos de uso
correspondientes a la iteración, se diseñan los mismos bajo la arquitectura
candidata presentada, y se codifican todos los componentes definidos por los
casos de uso, ejecutándose el testing correspondiente y la integración. Cuando
se quiera pasar un cierto conjunto de componentes al entorno productivo se
tendrá una fase de Transición en la cual se llevarán a cabo las actividades de
despliegue necesarias. La fase de Transición finaliza con un hito mayor
denominado Release del Producto en el que se evalúa lo realizado contra las
expectativas del Cliente y del Equipo de Desarrollo.
44 | P á g i n a
Disciplinas dentro de las Fases
Para planificar un proyecto y permitir tener visibilidad sobre el progreso y el
grado de avance del mismo, AgEnD propone dividir el proceso en disciplinas que
conforman agrupaciones de actividades en las cuales se produce un conjunto
particular de artefactos.
Factibilidad
Durante la disciplina de Factibilidad se produce el primer contacto entre el
equipo de desarrollo y el cliente. Esta disciplina permite al equipo de desarrollo
adquirir todo el conocimiento posible acerca del dominio, las necesidades de los
45 | P á g i n a
usuarios, los objetivos y expectativas que debe cumplir el software que está siendo
construido.
Requerimientos-Análisis
En la disciplina de Requerimientos-Análisis se realizan actividades tendientes
a capturar las necesidades de los stakeholders, transformar las mismas en features de
alto nivel y especificarlas posteriormente en casos de uso. Como se observa en la
Figura 016 se deberá especificar el espectro funcional el cual servirá para que los
desarrolladores diseñen e implementen los casos de uso y también el espectro no
funcional que posteriormente utilizará el arquitecto para construir la arquitectura de la
aplicación y el prototipo.
46 | P á g i n a
Diseño
La disciplina de Diseño consiste en plasmar el problema planteado, que se
halla en forma de casos de uso o requerimientos contenidos implícitamente por
Analistas o Clientes, en el dominio de la solución. Asimismo, también se realiza la
definición de la arquitectura siendo validada mediante algún prototipo (conocidos
como Proof Of Concept).
47 | P á g i n a
Implementación – Testing
En la disciplina de Implementación-Testing se lleva a cabo la producción del
software. El equipo de desarrollo se encarga de implementar la funcionalidad
especificada en los casos de uso mediante el lenguaje de programación elegido.
Despliegue
La disciplina de Despliegue permite que el sistema construido sea transferido
al ambiente de producción para ser utilizado por el usuario. Esto no significa que el
software debe estar implementado en su totalidad, cubriendo el 100% de los aspectos
funcionales y no funcionales sino que en una iteración determinada se desee liberar
una versión con un porcentaje de los casos de uso implementados. Dado el esquema
de desarrollo iterativo e incremental, durante las iteraciones ya mencionadas se va
agregando funcionalidad y se hace “crecer” al sistema hasta que cumpla con los
requerimientos que se especificaron al principio, sumados a los cambios surgidos a lo
largo del desarrollo.
48 | P á g i n a
49 | P á g i n a
REFERENCIAS BIBLIOGRÁFICAS
Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., & Selby, R. (1995). Cost
models for future software life cycle processes: COCOMO 2.0. Annals of software
engineering, 1(1), 57-94.
Molpeceres, A. (2002). Procesos de desarrollo: RUP, XP y FDD.
Montilva, J. (1999). Desarrollo de sistemas de información. Universidad de los Andes.
Schenone, M. (2004). Diseño de una Metodología Ágil de Desarrollo de Software. Trabajo
de grado para optar al título de Ingeniero, Universidad de Buenos Aires.