Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
TESIS (2).doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
2.18 Mб
Скачать

Capítulo 4.6 Modelo de Arquitectura de la solución (Gráfico y Narración)

La arquitectura es de cliente servidor de tres capas: capa de presentación, de negocios y de datos.

El sistema comprenderá a todas las instancias del directorio de transporte público metropolitano, ya que todas las gerencias, en su momento, hacen pedidos de compras a la gerencia de Administración y personal. Estos pedidos serán administrados por el sistema a través de una base de datos MySQL tal como lo muestra la figura 4.6

Figura 4.6

Capítulo 4.7

Estudio de factibilidad.

En este estudio veremos la factibilidad del proyecto para ser implementado en el Directorio de Transporte Público Metropolitano

Capítulo 4.7.1

Factibilidad técnica

En el Directorio de Transporte Público Metropolitano, cuyas oficinas quedan en Moneda 975 existe una plataforma informática que alberga diferentes tipos de servidores. 4 de estos son servidores de máquinas virtuales que contiene servidores de diferentes tipos, en uno de estos se configurará una máquina virtual bajo Linux donde residirá el sistema.

El software requerido para el desarrollo de la solución, está compuesto por:

Linux (distribución Ubuntu Server 14.04 de 64 bit LTS)

MySQL

Apache 2.4

PHP 5.5

Y el Hardware será dentro de un servidor de máquinas virtuales, que tendrá:

8 núcleos

8 GB de RAM

20 GB

Unido a una LUN de un Storage de unos 100 GB. Donde se almacenaran los datos, esta será ampliable, si es que se necesita hasta 20 TB.

Imagen 4.7.1 Factibilidad Técnica.

Capítulo 4.7.2 Factibilidad Económica

Los software son de licencia libre, esto evitara que el estado incurra en estos gastos por los sistemas.

El hardware ya está implantado hace mucho tiempo, debido a que en el servidor de máquinas virtuales funcionan muchos sistemas que se han ido integrando desde hace 3 años, el servidor más nuevo de máquinas virtuales fue comprado hace un año y medio, y fue por un costo de 4 millones de pesos.

El costo de el programador es de 1.5 UF x hora durante 3 días, esto siendo un día de 6 horas.

1.5 UF x 3 días. 6 horas = 27 UF

Estando la unidad de fomento a $23.881, sería el costo de $644.787

Por la documentación seria 2 días a un costo de 1 UF, lo que daría un total de $ 668.668

Capítulo 4.7.3

Factibilidad Operacional

Los usuarios que usaran este producto serán todos los administrativos de todas las gerencias del Directorio Publico Metropolitano. Ya que los pedidos se harán de todas las gerencias y por sobre todo será la Gerencias de Administración y Personal la que llevar a cabo la recepción de los pedidos.

Capítulo 4.7.4

Factibilidad Legal

El sistema no infringirá ninguna ley ya que las licencias del sistema serán de software libre bajo licencia internacional GNU (General Public License).

Capítulo 4.8

Análisis FODA

En este análisis vemos las siguientes 4 puntos según muestra la figura 4.8

Figura 4.8 F.O.D.A.

Capítulo 4.9

Análisis de Riesgos

Se puede encontrar que los usuarios tengan una resistencia a cambiar la forma habitual de realizar los pedidos de compra. Esto podría impedir que los procesos puedan hacerse más rápido. Para eso es indispensable parametrizar los tiempos en el software con los pedidos que tenga los usuarios.1

Figura 4.9 Análisis de Riesgo.

Los riesgos son medio bajo y conforme a esta matriz este proyecto por lo tanto es viable.

Capítulo 4.10

Metodología

El método a usar será el de cascada iterativa incremental, el cual tiene sus fases que se muestran a continuación.

Capítulo 4.10

Metodología de Desarrollo

La metodología de desarrollo será la de cascada interactivo e incremental debido a que nos permite poder perfeccionar el sistema retroalimentándose varias veces, sacando varias versiones del programa y la creación de nuevas funcionalidades que puedan nacer que el sistema sea más robusto con el tiempo.2

Tal como lo explica la figura 4.10.

Figura 4.10 Metodología de Cascada iterativo e incremental

Cada uno de estos procesos de cascada desarrolla una versión y una funcionalidad para la aplicación. Posteriormente el desarrollo nuevo se suma al desarrollo anterior haciendo que la aplicación tenga más robustez.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]