Evaluación del ciclo de vida del aceite de motor como producto … · 2018-09-26 · 2.1...

DISEÑO E IMPLEMENTACIÓN DEL PROCESO DE ANÁLISIS TÉCNICO DE ASIGNACIÓN DE ESPECTRO DE TELEVISIÓN EN LA HERRAMIENTA WEB “SISTEMA DE SIMULACIÓN EN LÍNEA” DE LA AGENCIA NACIONAL DEL

ESPECTRO (ANE).

JUAN CARLOS VALDERRAMA CAMARGO

UNIVERSIDAD PEDAGOGICA Y TECNOLOGICA DE COLOMBIA

FACULTAD SEDE SECCIONAL SOGAMOSO

INGENIERIA ELECTRONICA

SOGAMOSO

2017

DISEÑO E IMPLEMENTACIÓN DEL PROCESO DE ANÁLISIS TÉCNICO DE ASIGNACIÓN DE ESPECTRO DE TELEVISIÓN EN LA HERRAMIENTA WEB “SISTEMA DE SIMULACIÓN EN LÍNEA” DE LA AGENCIA NACIONAL DEL

ESPECTRO (ANE).

JUAN CARLOS VALDERRAMA CAMARGO

Trabajo de grado presentado como requisito para optar al título de

INGENIERO ELECTRÓNICO

DIRECTOR: INGENIERO EDISON FERNEY ANGARITA MALAVER

PROFESOR AUXILIAR

UNIVERSIDAD PEDAGOGICA Y TECNOLOGICA DE COLOMBIA

FACULTAD SEDE SECCIONAL SOGAMOSO

INGENIERIA ELECTRONICA

SOGAMOSO

2017

Nota aceptación

DIRECTOR

JURADO 1

JURADO2

Sogamoso 25 de agosto de 2017

Copyright © 2017 por TES América Andina SAS y la Agencia Nacional del Espectro

ANE.

Todos los derechos reservados.

AGRADECIMIENTOS

A mi familia por brindarme el apoyo necesario para poder culminar con éxito el proceso para obtener mi título de ingeniero.

Expreso mi gratitud a las personas y dependencias de la universidad pedagógica y tecnológica de Colombia que de una u otra manera hicieron parte activa en mi proceso de formación profesional y personal dentro de la institución. A TES américa andina SAS por brindarme la oportunidad de realizar mi práctica empresarial en dicha empresa, en especial al área de soporte y desarrollo de la misma.

TABLA DE CONTENIDO

INTRODUCCIÓN ................................................................................................... 12

1. GENERALIDADES .......................................................................................... 13

1.1 DESCRIPCIÓN DE LA NECESIDAD EMPRESARIAL ............................. 13

1.2 OBJETIVOS .............................................................................................. 14

1.2.1 Objetivo general. .................................................................................... 14

1.2.2 Objetivos específicos. ............................................................................. 14

2. FUNDAMENTOS TEORICOS ......................................................................... 15

2.1 METODOLOGIAS PARA DESARROLLO DE SOFTWARE ..................... 15

2.1.1 Metodologías tradicionales. .................................................................... 16

2.1.1.1 CMMI. .......................................................................................... 17

2.1.1.2 RUP. ............................................................................................ 19

2.1.1.3 MSF. ............................................................................................ 19

2.1.2 Metodologías agiles................................................................................ 20

2.1.2.1 SCRUM........................................................................................ 21

2.1.2.2 XP. ............................................................................................... 23

2.1.2.3 Crystal methodologies. ................................................................ 24

2.2 ESPECTRO RADIOELECTRICO EN COLOMBIA ................................... 25

2.2.1 Atribución de frecuencias en Colombia. ................................................. 25

2.2.2 Bandas VHF y UHF en Colombia. .......................................................... 27

2.2.3 Televisión en Colombia. ......................................................................... 27

2.2.3.1 Plan de distribución de canales servicio de radiodifusión de televisión. 27

2.3 APLICACIONES WEB .............................................................................. 28

2.3.1 Arquitecturas de tres capas. ................................................................... 29

3. DESARROLLO DEL PROYECTO ................................................................... 31

3.1 SISTEMA DE SIMULACIÓN EN LÍNEA.................................................... 31

3.2 REQUERIMIENTOS ................................................................................. 32

3.2.1.1 Herramienta simulación servicio punto-multipunto. ..................... 32

3.2.1.2 Herramienta análisis de ingeniería servicio de televisión. ........... 32

3.2.1.3 Soporte y mantenimiento. ............................................................ 33

3.3 DISEÑO Y DESARROLLO DE LOS REQUERIMIENTOS ........................ 33

3.3.1 Capa de presentación ui. ........................................................................ 33

3.3.2 Capa de negocios bll. ............................................................................. 33



3.3.3 Capa de datos dal. ................................................................................. 34



3.4 METODOLOGIA ....................................................................................... 34

3.5 APLICACIÓN DE LA METODOLOGIA ..................................................... 35

3.5.1 Requerimiento inicial. ............................................................................. 36

3.5.1.1 Tareas. ........................................................................................ 36

3.5.2 Requerimiento 2. .................................................................................... 36

3.5.2.1 Tareas. ........................................................................................ 36

3.5.3 Requerimiento 3. .................................................................................... 36

3.5.3.1 Tareas. ........................................................................................ 36

3.5.4 Requerimiento 4. .................................................................................... 37

3.5.4.1 Tareas. ........................................................................................ 37

4. RESULTADOS DEL PROYECTO ................................................................... 38

4.1 MODULO ANALISIS DE INGENIERÍA SERVICIO DE TELEVISIÓN ....... 38

4.2 SIMULACIÓN DE COBERTURAS ............................................................ 42

4.2.1 Gestión de red. ....................................................................................... 43

4.2.1.1 Adicionar/Ver/Editar objeto. ......................................................... 43

4.2.1.2 Modificar objetos. ......................................................................... 43

4.2.1.3 Mapear objetos seleccionados. ................................................... 44

4.2.1.4 Validar plan de canalización. ....................................................... 44

4.2.1.5 Actualizar msnm. ......................................................................... 44

4.2.1.6 Calcular pra. ................................................................................ 45

4.2.1.7 Calcular haat. ............................................................................... 45

4.2.1.8 Matriz itu-r p.1546-4. .................................................................... 45

4.2.1.9 Potencia recibida (dl). .................................................................. 46

4.2.1.10 Polígonos cubiertos. .................................................................... 46

4.2.1.11 Importar estaciones existentes. ................................................... 47

4.2.1.12 Posibles interferidos. ................................................................... 48

4.2.1.13 Posibles interferentes. ................................................................. 48

4.2.1.14 Intensidad de campo. .................................................................. 49

4.2.1.15 Crear contorno cobertura. ............................................................ 49

4.2.1.16 Potencia recibida (ul). .................................................................. 50

4.3 soporte y mantenimiento técnico .............................................................. 51

5. CONCLUSIONES ............................................................................................ 53

LISTA DE ACRONIMOS ........................................................................................ 55

REFERENCIAS BIBLIOGRÁFICAS ....................................................................... 56

ANEXOS ................................................................................................................ 58

ANEXO TECNICO .............................................................................................. 58

LISTA DE TABLAS

Tabla 1. Diferencias entre metodologías agiles y tradicionales. ............................... 16

Tabla 2. Plan de distribución de canales servicio radiodifusión de televisión en Colombia. ............................................................................................................................ 28

Tabla 3. Estructura básica de la PB en el proyecto. .................................................... 35

Tabla 4. Resumen soporte técnico Sistema de simulación en Línea. ...................... 52

Tabla 5. Tipos de fallas. ................................................................................................... 58

LISTA DE FIGURAS

Figura 1. Comparación metodologías desarrollo de software. a) Ciclos de vida b) costos de cambio. ............................................................................................................. 16

Figura 2. Niveles de madurez CMM. .............................................................................. 18

Figura 3. RUP fases y disciplinas. .................................................................................. 19

Figura 4.Ciclo de vida de un proyecto MSF. ................................................................. 20

Figura 5.Marco de SCRUM. ............................................................................................ 23

Figura 6. Ciclo XP. ............................................................................................................ 24

Figura 7. Clasificación Crystal methodologies. ............................................................. 25

Figura 8. Regiones y zonas para atribución de bandas de frecuencia. ................... 26

Figura 9.Ejemplo implementación del CNABF en Colombia. ..................................... 26

Figura 10. Esquema básico de una aplicación web. ................................................... 29

Figura 11. Arquitectura de 3 capas de una aplicación web. ....................................... 30

Figura 12. Arquitectura de 3 capas de una aplicación web en PHP. ........................ 30

Figura 13.Arquitectura de la herramienta web Sistema de Simulación en Línea. .. 32

Figura 14.Menu de inicio herramienta web Sistema de Simulación en Línea rol Administrador. .................................................................................................................... 38

Figura 15.Ventana inicio modulo televisión herramienta web Sistema de Simulación en Línea rol Administrador. .............................................................................................. 38

Figura 16.Ventana crear estación herramienta web Sistema de Simulación en Línea rol Administrador. .............................................................................................................. 39

Figura 17.Ventana error crear estación herramienta web Sistema de Simulación en Línea rol Administrador. ................................................................................................... 40

Figura 18. CCTR estación análoga modulo TV herramienta web Sistema de Simulación en Línea rol Administrador. ......................................................................... 41

Figura 19.CCTR estación digital modulo TV herramienta web Sistema de Simulación en Línea rol Administrador. ......................................................................... 41

Figura 20.Menu de inicio herramienta web Sistema de Simulación en Línea rol Operador Mixto. ................................................................................................................. 42

Figura 21.Ventana módulo de simulación Sistema de Simulación en Línea. ......... 42

Figura 22.Ventana modificar objeto Sistema de Simulación en Línea. .................... 43

Figura 23.Ventana mapa de Sistema de Simulación en Línea.................................. 44

Figura 24.Ventana Validar plan canalización de Sistema de Simulación en Línea. .............................................................................................................................................. 44

Figura 25.Ventana matriz itu-r p.1546-4 de Sistema de Simulación en Línea. ....... 45

Figura 26.Potencia recibida DL en Sistema de Simulación en Línea. ...................... 46

Figura 27.Poligonos cubiertos en Sistema de Simulación en Línea. ........................ 47

Figura 28. Importar estaciones existentes en Sistema de Simulación en Línea. ... 48

Figura 29.Posibles interferidos por la estación en Sistema de Simulación en Línea. .............................................................................................................................................. 48

Figura 30.Posibles interferentes de la estación en Sistema de Simulación en Línea. .............................................................................................................................................. 49

Figura 31.Intensidad de campo de la estación en Sistema de Simulación en Línea. .............................................................................................................................................. 49

Figura 32.Contorno de cobertura de la estación en Sistema de Simulación en Línea. .............................................................................................................................................. 50

Figura 33.Potencia recibida UL de la estación en Sistema de Simulación en Línea. .............................................................................................................................................. 51

12

INTRODUCCIÓN

TES América andina SAS es una empresa de tecnología que desde el año 1999 ofrece servicios especializados de ingeniería y desarrolla e integra soluciones a la medida para la industria de las radiocomunicaciones y para la gestión del espectro radioeléctrico. Su nicho de mercado está orientado a los operadores de telecomunicaciones, a la radiodifusión y a los entes reguladores (tesamerica.com.co, 2017). La innovación en TES América andina SAS se fundamenta en la investigación y el desarrollo aplicado y para ello mantiene una larga y estrecha relación de cooperación con grupos de investigación y universidades, ya sea por medio del patrocinio de proyectos, de convenios con grupos de investigación o mediante la financiación brindada en diferentes proyectos por COLCIENCIAS. Por tanto, este trabajo se enmarca dentro de una consulta científico tecnológica llevada a cabo por el Grupo de Investigación en Telecomunicaciones GINTEL en el marco del convenio No. 146 ¨ Convenio marco de cooperación interinstitucional entre la Universidad Pedagógica y Tecnológica de Colombia UPTC y TES América Andina LTDA.¨

Entre los clientes que maneja TES América andina SAS se encuentra la Agencia Nacional del Espectro (ANE), entidad que realiza la planeación, atribución, vigilancia y control del Espectro Radioeléctrico en Colombia. La ANE cuenta con la herramienta web Sistema de Simulación en Línea la cual sirve para determinar de una forma más precisa las frecuencias que los operadores requieren, facilitando con ello el acceso al uso del espectro y minimizando los tiempos de realización de estudios de viabilidad técnica que efectúa la ANE, garantizando la confiabilidad de la información remitida por los proveedores de redes y servicios de telecomunicaciones (PRST). El Sistema de Simulación en Línea requiere un periodo de revisión, monitoreo y actualización por tratarse de un software que ha sido individualizado de conformidad con las necesidades de la entidad, persiguiendo que se adecue de acuerdo con los requerimientos de la ANE, los cuales pueden ser cambiantes debido a la necesidad del servicio.

Este trabajo presenta el proceso mediante el cual TES América andina SAS incorporo a la herramienta web Sistema de Simulación en Línea la posibilidad de simular el servicio punto-multipunto y la automatización para el análisis de ingeniería del servicio de televisión con base en los parámetros técnicos usados por la ANE además del soporte y mantenimiento técnico realizado a la herramienta. En el capítulo 1 se describe la necesidad empresarial y se listan los objetivos de este trabajo, en el capítulo 2 se muestra el marco teórico, en el capítulo 3 se describe la metodología de desarrollo de software implementada en la realización de este trabajo y en el capítulo 4 se muestran los resultados obtenidos al realizar el lanzamiento de la nueva versión de la herramienta web sistema de simulación en línea.

13

1. GENERALIDADES

1.1 DESCRIPCIÓN DE LA NECESIDAD EMPRESARIAL

TES América andina SAS tiene como principal objetivo brindar un apoyo estratégico en la planeación, asignación, optimización y control del espectro radioeléctrico en economías emergentes. TES américa andina SAS es el representante exclusivo para Colombia de la empresa francesa ATDI y como tal, cuenta con respaldo y soporte para distribuir, revender, instalar, enseñar y soportar sus plataformas.

Con la expedición de la ley 1341 de 2009 se creó la ANE, como una unidad administrativa especial de orden nacional, adscrita al ministerio de TIC. Posteriormente el decreto 4169 de 2011, modifico la naturaleza jurídica de la ANE a una unidad administrativa especial de orden nacional, con personería jurídica, autonomía técnica, administrativa, financiera y patrimonio propio, adscrita al ministerio TIC, cuyo objeto es brindar el soporte técnico para la gestión y la planeación, la vigilancia y control del espectro radioeléctrico. El decreto 093 de 2010, establece que la ANE, por medio de la subdirección de gestión y planeación, debe estudiar y tramitar las solicitudes relacionadas con el uso del espectro radioeléctrico. En ese sentido, el decreto 4169 de 2011, le confiere a la ANE la elaboración de los cuadros de características técnicas de la red (CCTR) para el otorgamiento de permisos para el uso del espectro que entrega el ministerio de TIC. Con base en lo estipulado en la mencionada ley, el ministerio de TIC adopto en 2015 la política de espectro, propuesta por la ANE, la cual en su estrategia “Potencializar y democratizar el uso del portal de espectro visible para la optimización de los procesos relativos a su administración” busca continuar con lo dispuesto en el modelo de política de espectro de 2012 que incluía dentro de sus estrategias la del “PORTAL DE ESPECTRO VISIBLE”.

Por lo anterior la ANE diseño y puso a disposición del sector la herramienta web denominada “Sistema de Simulación en Línea”, la cual permite a los usuarios interesados determinar de manera anticipada la disponibilidad del espectro, ya que pueden realizar simulación de potenciales interferencias en las frecuencias que requieran, definiendo con un alto grado de certeza si existe o no alguna interferencia. La implementación de dicho sistema, en su primera etapa permite a los titulares de permisos de redes punto a punto (operadores de radioenlaces de microondas) realizar simulaciones utilizando la base de datos de espectro asignado. Dicha implementación fue realizada por TES América Andina SAS. El Sistema de Simulación en Línea es una aplicación web soportada en el software Spectrum-E© de la empresa ATDI (Atdi.com, 2017).

Posteriormente la ANE busca expandir la aplicación al servicio punto-multipunto (frecuencias para cubrimiento) y automatizar el análisis de ingeniería del servicio de televisión con el propósito de lograr mayor eficiencia, en las labores a cargo de la ANE en lo concerniente a estos servicios además de garantizar un funcionamiento

14

más preciso del sistema, mejorar las capacidades, realizar actualizaciones, así como llevar a cabo una constante revisión y afinación de los distintos elementos y funcionalidades que lo componen por tratarse de un software. Por ello la ANE contacto a TES américa Andina SAS para llevar a cabo la actualización del sistema de simulación en Línea.

1.2 OBJETIVOS

1.2.1 Objetivo general.

Incorporar a la aplicación web Sistema de Simulación en Línea de la agencia nacional del espectro (ANE) la opción de simular coberturas y realizar estudios de análisis de interferencia para las bandas VHF/UHF. Además de una herramienta para el control y análisis técnico de asignación de espectro de televisión, acorde con los lineamientos de la estrategia del Programa de Gobierno en Línea, con presentación gráfica ajustada al propósito de la ANE.

1.2.2 Objetivos específicos.

Implementar en el módulo de simulación de la herramienta web Sistema de Simulación en Línea la opción de simular coberturas y realizar estudios de interferencia para el servicio punto-multipunto, con los parámetros usados por la ANE para determinar las frecuencias a utilizar, su área de cobertura y las potenciales interferencias con base en los datos de espectro asignado.

Desarrollar un módulo para automatizar el análisis de ingeniería del servicio de televisión en la herramienta web Sistema de Simulación en Línea de acuerdo a las necesidades de la ANE.

Prestar el soporte y mantenimiento técnico a la herramienta web “Sistema de Simulación en Línea” 5x8 (de lunes a viernes), solucionando los problemas de funcionamiento de la misma.

15

2. FUNDAMENTOS TEORICOS

2.1 METODOLOGIAS PARA DESARROLLO DE SOFTWARE

Una metodología para el desarrollo de software comprende los procesos a seguir sistemáticamente para idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado. El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte, tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en muchos otros. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo, pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales (Canós et al., 2003). En la Tabla 1 se muestra un cuadro comparativo entre metodologías tradicionales y las metodologías agiles. La Figura 1 compara los ciclos de vida de ambas metodologías y las curvas de comportamiento de los riesgos y costos de cambios a lo largo del ciclo de vida de desarrollo en cada metodología.

16

Tabla 1. Diferencias entre metodologías agiles y tradicionales.

Metodologías Agiles Metodologías Tradicionales

Basadas en heurísticas provenientes de prácticas de producción de código

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo

Especialmente preparados para cambios durante el proyecto

Cierta resistencia a los cambios

Impuestas internamente (por el equipo) Impuestas externamente

Proceso menos controlado, con pocos principios

Proceso mucho más controlado, con numerosas políticas/normas

No existe contrato tradicional o almenos es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones.

Grupos pequeños (<10 integrantes) Grupos grandes posiblemente distribuidos

Pocos artefactos Mas artefactos

Pocos roles Mas roles

Menos énfasis en la arquitectura de software

La arquitectura de software es esencial y se expresa mediante modelos

Figura 1. Comparación metodologías desarrollo de software. a) Ciclos de vida b) costos de cambio.

Fuente: http://www.agilenutshell.com/how_is_it_different

2.1.1 Metodologías tradicionales.

Las metodologías tradicionales buscan imponer disciplina al proceso de desarrollo de software y de esa forma volverlo predecible y eficiente. Para conseguirlo se

17

soportan en un proceso detallado con énfasis en planeación propio de otras ingenierías (Fowler, 2017). Se pueden citar las siguientes metodologías tradicionales en desarrollo de software: CMMI, RUP, MSF.

2.1.1.1 CMMI.

Antes se debe reseñar el modelo de madurez de capacidades CMM por sus siglas en inglés, es un modelo cuyo propósito es la evaluación de la calidad de los procesos de una organización a la vez que suministra guías enfocadas a orientar a dicha organización en la mejora de los mismos, todo esto contribuye a desarrollar mejores productos. Aunque se desarrolló inicialmente para los procesos relacionados con el desarrollo e implementación de software en su evolución se ha extendido a las áreas de adquisición y de servicios.

Su origen se remonta hacia el año 1986 cuando el SEI (software engineering institute), centro de investigación y desarrollo patrocinado por el departamento de defensa de estados unidos y gestionado por la universidad Carnegie-Mellon (Chrissis et al.,2011), inicio a trabajar en los modelos de madurez de los procesos de desarrollo de software a petición del gobierno estadounidense con el objetivo de atacar los problemas que se generaban con el software que le suministraban otras empresas: fechas de entrega extendidas, incremento del costo, liberaciones con errores etcétera (Paulk, 1993). Como resultado en el año siguiente publico el primer documento con la primera definición de estos modelos.

CMM establece un conjunto de prácticas o procesos que son fundamentales y los agrupa en áreas clave de proceso KPA (key process area). Para cada KPA se define un conjunto de buenas prácticas las cuales deben cumplir con las siguientes características:

Estar definidas en un procedimiento documentado.

Estar provistas de los medios y formación necesarios.

Deben ser ejecutadas de un modo sistemático, universal y uniforme.

Se deben medir.

Se deben verificar.

Las KPA´s se clasifican dentro de 5 niveles de madurez, estos se emplean para describir un camino evolutivo recomendado para que una organización busque mejorar sus procesos de desarrollo de productos o servicios (Mary Beth Chrissis, 2012). Los niveles se describen en la Figura 2.

18

Figura 2. Niveles de madurez CMM.

Fuente: http://www.pmvalue.com.ar/newsletters/Newsletter%20-%20CMM.pdf

Con el paso del tiempo y la aplicación de CMM en distintas áreas se crearon diversas versiones de CMM para cada una: people CMM (P-CMM), Software acquisition CMM (SA-CMM), Security systems engineering CMM (SSE-CMM), Systems engineering CMM (SE-CMM), Integrated product development CMM (IPD-CMM) entre otros. Algunas organizaciones implementan varios modelos de forma paralela lo que derivó en la oportunidad y necesidad de integrarlos para hacer más sencilla su implementación. Así surge CMMI que integra SW-CMM, IPD-CMM y SE-CMM.

CMMI se puede implementar de dos formas: escalonada y continua. El primero se centra en la madurez de la organización presentando los 5 niveles de madurez de CMM, pero se cambian los nombres a los niveles 2 y 4; mientras que el segundo se enfoca en la mejora y control de las capacidades que se clasifican en 6 niveles que van de 0 a 5 y se presentan en orden de la siguiente manera:

0-Incompleto: El proceso no se realiza o no se logran los objetivos.

1-Ejecutado: El proceso se ejecuta y se logra su objetivo.

2-Gestionado: Además de ejecutarse, el proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos.

3-Definido: Además de ser un proceso “gestionado” se ajusta a la política de procesos que existe en la organización, alineada con las directivas de la empresa.

4-Cuantitativamente gestionado: Además de ser un proceso definido se controla utilizando técnicas cuantitativas.

5-Optimizado: Además de ser un proceso cuantitativamente gestionado, se revisa sistemáticamente.

19

2.1.1.2 RUP.

Es considerado una metodología para el desarrollo de software que va más allá del análisis y diseño orientado a objetos con el fin de brindar un conjunto técnicas que soportan el ciclo completo de desarrollo de software, dando como resultado un proceso basado en componentes, dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental (Chacón-Córdoba, 2011). La Figura 3 muestra las características principales de RUP.

Figura 3. RUP fases y disciplinas.

Fuente: http://ingenieriadesoftware13.blogspot.com.co/.

El RUP está basado en seis principios clave que son los siguientes:

Adaptar el proceso.

Equilibrar prioridades.

Demostrar valor iterativamente.

Colaboración entre equipos.

Elevar el nivel de abstracción.

Enfocarse en la calidad.

2.1.1.3 MSF.

Es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que pueden adaptarse a cualquier proyecto de tecnología de información (Santimacnet's Blog, 2017). En la Figura 4 se muestran las fases y la relación con el ciclo de vida de un proyecto realizado con MSF.

20

Figura 4.Ciclo de vida de un proyecto MSF.

Fuente: https://santimacnet.wordpress.com/2010/12/20/microsoft-solutions-framework-5-0-msf/

MSF plantea 5 fases:

Visión y alcances.

Equilibrar prioridades.

Desarrollo.

Estabilización.

Implantación.

2.1.2 Metodologías agiles.

En la década de los noventa surgieron metodologías de desarrollo de software ligeras, más adelante nombradas como metodologías ágiles, que buscaban reducir la probabilidad de fracaso por subestimación de costos, tiempos y funcionalidades en los proyectos de desarrollo de software (Fernández et al, 2013). El pilar de las metodologías agiles son los valores y principios del manifiesto ágil que se firmó entre el 11 y el 13 de febrero de 2001 durante una reunión desarrollada en el resort Lodge en Snowbird en Utha (USA) (Uribe and Ayala, 2007). En dicha reunión 17 críticos, empresarios y desarrolladores de software convocados por Kent Beck para debatir y entender las ideas y enfoques de cada uno, como resultado nació el manifiesto ágil cuyos valores se listan a continuación:

“Estamos descubriendo formas mejores de desarrollar Software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

21

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”. (Agilemanifesto.org, 2017).

A continuación, se listan algunas de las metodologías agiles de desarrollo de software: SCRUM, XP, Crystal methodologies.

2.1.2.1 SCRUM.

Es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de productos complejos desde principios de los años 90. SCRUM no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos. SCRUM muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo, de modo que podamos mejorar. SCRUM es

Ligero.

Fácil de entender.

Extremadamente difícil de llegar a dominar.

SCRUM se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. SCRUM emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo. Tres pilares soportan toda la implementación del control de procesos empírico: transparencia, inspección y adaptación.

El marco de trabajo SCRUM consiste en los Equipos SCRUM, roles, eventos, artefactos y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de SCRUM y para su uso. Las reglas de SCRUM relacionan los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos (Schwaber et al., 2013).

El equipo SCRUM.

Son auto organizados, multifuncionales y entregan productos de manera iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. El Equipo SCRUM consiste en un Dueño de Producto (Product Owner-PO), el Equipo de Desarrollo (Development Team -DT) y un Scrum Master (SM).

Roles.

Se clasifican entre comprometidos e involucrados de acuerdo a la fábula del cerdo y la gallina (Keith, 2010). Los comprometidos (cerdos) son el PO, SM y el DT, aunque en ciertos aspectos el PO puede ser considerado como involucrado (gallina), entre estos roles no existe ningún nivel de jerarquía; mientras que los involucrados (gallinas) son los stakeholders (SH).

PO: EL dueño del producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo y la única persona responsable de gestionar la Lista del Producto (Product Backlog -PB).

22

DT: El Equipo de Desarrollo consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de producto Terminado, que potencialmente se pueda poner en producción, al final de cada Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento.

SM: El SCRUM Master es el responsable de asegurar que SCRUM es entendido y adoptado. Los SCRUM Masters hacen esto asegurándose de que el Equipo SCRUM trabaja ajustándose a la teoría, prácticas y reglas de SCRUM.

Eventos SCRUM.

Son eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en SCRUM. Todos los eventos son bloques de tiempo (TB-time box) de tal modo que todos tienen una duración máxima.

Sprint: es un TB de un mes o menos durante el cual se crea un incremento de producto Terminado, utilizable y potencialmente desplegable. Los Sprints contienen y consisten de la Reunión de Planificación del Sprint (Sprint Planning Meeting), los SCRUMs Diarios (Daily SCRUMs), el trabajo de desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective).

Artefactos de SCRUM.

Representan trabajo o valor en diversas formas que son útiles para proporcionar transparencia y oportunidades para la inspección y la adaptación. En SCRUM se pueden listar los dos artefactos siguientes: Lista de Producto (Product Backlog -PB) Lista de Pendientes del Sprint (Sprint Backlog -SB).

PB: es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. EL PO es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación. Una Lista de Producto nunca está completa. El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al principio. La Lista de Producto evoluciona a medida que el producto y el entorno en el que se usará también lo hacen. La Lista de Producto es dinámica; cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Lista de Producto también existe. La Lista de Producto enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras. Los elementos de la Lista de Producto tienen como atributos la descripción, la ordenación, la estimación y el valor.

23

SB: es el conjunto de elementos del PB seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint. La Lista de Pendientes del Sprint es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.

En la Figura 5 se aprecia el proceso necesario para aplicar SCRUM.

Figura 5.Marco de SCRUM.

Fuente: http://metodologiascrum.readthedocs.io/en/latest/Scrum.html

2.1.2.2 XP.

Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico (Extremeprogramming.org, 2017). En la Figura 6 se aprecia el proceso que se debe seguir al utilizar la metodología de desarrollo XP.

24

Figura 6. Ciclo XP.

Fuente: (Extremeprogramming.org, 2017)

2.1.2.3 Crystal methodologies.

Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores (ver Figura 7). Por ejemplo, Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros) (Devx.com, 2017).

25

Figura 7. Clasificación Crystal methodologies.

Fuente: https://www.linkedin.com/pulse/crystal-self-awareness-balaji-sathram-pmi-acp-csp-csm-cspo-

2.2 ESPECTRO RADIOELECTRICO EN COLOMBIA

El espectro radioeléctrico es un recurso natural conformado por el conjunto de ondas electromagnéticas cuya frecuencia se fija convencionalmente por debajo de 3000 GHz, que se propagan por el espacio sin guía artificial. Es propiedad exclusiva del Estado y como tal constituye un bien de dominio público, inajenable e imprescriptible, cuya gestión, administración, vigilancia y control corresponden a la Agencia Nacional del Espectro de conformidad con las leyes y decretos vigentes.

Las facultades de gestión y administración del espectro radioeléctrico, comprenden entre otras, las actividades de planeación, coordinación y establecimiento del cuadro de atribución de frecuencias (CNABF), este último, permite que los diferentes servicios de radiocomunicación del país, operen en bandas de frecuencias definidas previamente para cada uno de ellos, con el fin de asegurar su operatividad, minimizar la probabilidad de interferencias objetables y permitir la coexistencia de servicios de telecomunicaciones dentro de una misma banda de frecuencias, cuando sea del caso. Por lo tanto, la asignación siempre debe coincidir con la atribución de este cuadro (ANE, 2016).

2.2.1 Atribución de frecuencias en Colombia.

Desde el punto de vista de la atribución de las bandas de frecuencias, se ha dividido el mundo en tres Regiones indicadas en el siguiente mapa de la Figura 8, Colombia pertenece a la Región 2.

26

Figura 8. Regiones y zonas para atribución de bandas de frecuencia.

Fuente: (ANE, 2016)

Con base en ello la disposición CNABF será la que se muestra en el ejemplo de la Figura 9

Figura 9.Ejemplo implementación del CNABF en Colombia.

Fuente: (ANE, 2016)

27

2.2.2 Bandas VHF y UHF en Colombia.

El rango de frecuencias que abarca la banda VHF va desde los 30 MHz hasta los 300 MHz, y el rango de la banda UHF va desde los 300 MHz hasta los 3000 MHz, para el desarrollo del proyecto la ANE definió que las frecuencias autorizadas para ser simuladas en el nuevo módulo de simulación de coberturas y estudios de interferencia fueran las tablas del CNABF que se listan a continuación:

tabla 3A PLAN DE BANDA. (138 – 174 MHz)

tabla 11 PLAN DE DISTRIBUCIÓN DE CANALES SERVICIOS FIJO Y MÓVIL (ACCESO TRONCALIZADO) BANDA DE 400 MHz. (412 – 415 MHz y 422 – 425 MHz) 1966 DE 2002, MINISTERIO DE COMUNICACIONES ANCHO DE BANDA DEL CANAL: 0,0125 MHz.

tabla 12 PLAN DE DISTRIBUCIÓN DE CANALES SERVICIOS FIJO Y MÓVIL (ACCESO TRONCALIZADO) BANDA DE 400 MHz. (415 – 420 MHz y 425 – 430 MHz) RESOLUCIÓN 1966 DE 2002, MINISTERIO DE COMUNICACIONES ANCHO DE BANDA DEL CANAL: 0,0250 MHz.

tabla 13 PLAN DE BANDA. (440 – 470 MHz).

2.2.3 Televisión en Colombia.

De acuerdo con el artículo 1º de la ley 182 de 1995, la televisión es un servicio público sujeto a la titularidad, reserva, control y regulación del Estado, cuya prestación corresponderá, mediante concesión, a las entidades públicas a que se refiere esta Ley, a los particulares y comunidades organizadas. Técnicamente, es un servicio de telecomunicaciones que ofrece programación dirigida al público en general o a una parte de él y que está vinculado intrínsecamente a la opinión pública y a la cultura del país, como instrumento dinamizador de los procesos de información y comunicación audiovisuales (ley 182 de 1995).

2.2.3.1 Plan de distribución de canales servicio de radiodifusión de televisión.

El Plan Técnico de Televisión vigente hace parte integral del CNABF actual aprobado por la ANE. El plan de distribución de canales puede apreciarse en la Tabla 2.

28

Tabla 2. Plan de distribución de canales servicio radiodifusión de televisión en Colombia.

Banda Número de canal

Frecuencia Central(MHz)

Banda Número de

canal

Frecuencia Central(MHz)

VHF

I

2 57

IV

27 551

3 63 28 557

4 69 29 563

II 5 79 30 569

6 85 31 575

III

7 177 32 581

8 183 33 587

9 189 34 593

10 195 35 599

11 201 36 605

12 207 37 611

13 213 38 617

UHF IV

14 473 39 623

15 479 40 629

16 485

V

41 635

17 491 42 641

18 497 43 647

19 503 44 653

20 509 45 659

21 515 46 665

22 521 47 671

23 527 48 677

24 533 49 683

25 539 50 689

26 545 51 695

2.3 APLICACIONES WEB

Una aplicación web es un tipo especial de aplicación cliente/servidor, donde tanto el cliente como el servidor y el protocolo mediante el que se comunican están estandarizados y no han de ser creados por el programador de aplicaciones ver Figura 10. Las aplicaciones web se han convertido en pocos años en complejos sistemas con interfaces de usuario cada vez más parecidas a las aplicaciones de escritorio, dando servicio a procesos de negocio de considerable envergadura y

29

estableciéndose sobre ellas requisitos estrictos de accesibilidad y respuesta (Mora, 2002).

Figura 10. Esquema básico de una aplicación web.

Fuente:(Sciatel.wikispaces.com, 2017)

2.3.1 Arquitecturas de tres capas.

El usuario interacciona con las aplicaciones web a través del navegador. Como consecuencia de la actividad del usuario, se envían peticiones al servidor, donde se aloja la aplicación y que normalmente hace uso de una base de datos que almacena toda la información relacionada con la misma. El servidor procesa la petición y devuelve la respuesta al navegador que la presenta al usuario. Por tanto, el sistema se distribuye en tres componentes: el navegador, que presenta la capa de presentación (UI); la aplicación, que se encarga de realizar las operaciones necesarias según las acciones llevadas a cabo por éste, que representa la capa de negocios (BLL) y la base de datos, que representa la capa de datos (DAL) donde la información relacionada con la aplicación se hace persistente. Esta distribución se conoce como el modelo o arquitectura de tres capas y se puede apreciar en la Figura 11 (Garrido, 2004).

En la Figura 12 se aprecia cómo no se mezcla en una capa código correspondiente a otra. Además de que la interacción entre las capas se debe llevar a cabo mediante conectores y la interacción directa entre la capa de datos y la capa de presentación está prohibida. Logrando así sistemas mucho más escalables y de fácil mantenimiento.

30

Figura 11. Arquitectura de 3 capas de una aplicación web.

Fuente: (Mora, 2002 p.57)

Figura 12. Arquitectura de 3 capas de una aplicación web en PHP.

31

3. DESARROLLO DEL PROYECTO

3.1 SISTEMA DE SIMULACIÓN EN LÍNEA

Para el diseño e implementación de los nuevos desarrollos además del soporte y mantenimiento, se debe tener presente que la herramienta web Sistema de Simulación en Línea esta soportada en la aplicación Spectrum-e© de la empresa ATDI y a su vez Spectrum-e© está construida bajo las siguientes herramientas de desarrollo:

NetBeans IDE: Netbeans es un entorno de desarrollo integrado libre y de código abierto que tiene una gran comunidad de usuarios y desarrolladores de todo el mundo (Netbeans.org, 2017).

PHP (acrónimo recursivo de PHP: Hypertext Preprocessor): Es un lenguaje de código abierto muy popular especialmente adecuado para el desarrollo web y que puede ser incrustado en HTML (Php.net, 2017).

MongoDB: Es una base de datos de documentos de código abierto que proporciona alto rendimiento, alta disponibilidad y escalado automático (Docs.mongodb.com, 2017).

Apache HTTP server: El proyecto de servidor HTTP de Apache es un esfuerzo de desarrollo de software colaborativo dirigido a crear una implementación de código fuente robusta, de calidad comercial, funcional y libremente disponible de un servidor HTTP (Group, 2017).

Adicional Sistema de Simulación en Línea se ejecuta desde un servidor con sistema operativo Windows Server 2012R2 y utiliza como Sistema Gestor de Bases de Datos () Microsoft SQL Server 2008. En la Figura 13 se muestra la arquitectura del Sistema de Simulación en Línea.

32

Figura 13.Arquitectura de la herramienta web Sistema de Simulación en Línea.

Fuente: Autor.

3.2 REQUERIMIENTOS

A continuación, se presenta un resumen de los requerimientos considerados más importantes por el autor, obtenidos de la PB final después de lanzar el sistema de simulación en línea a producción.

3.2.1.1 Herramienta simulación servicio punto-multipunto.

Esta herramienta debe estar disponible únicamente para los roles operador mixto, operador cubrimiento y administrador del sistema de simulación en línea.

Los estudios de interferencia se deben presentar de manera similar a los estudios de interferencia de enlaces de microondas.

Se debe validar la información al crear o modificar una estación de acuerdo a los parámetros de la ANE.

Los cálculos deben cumplir con la Recomendación UIT-R P.1546-4.

3.2.1.2 Herramienta análisis de ingeniería servicio de televisión.

Esta herramienta debe estar disponible únicamente para los usuarios con rol administrador del sistema de simulación en línea.

Se deben poder diferenciar entre estaciones análogas y estaciones digitales.

Una estación puede tener solo uno de los siguientes estados: modificado, rechazado, aprobado.

Debe existir un mapa al momento de crear o modificar una estación en donde aparezca la localización geográfica de la estación en dicho mapa.

Se debe poder agregar múltiples estaciones mediante una funcionalidad de carga masiva de datos.

Se debe poder generar CCTR de cada operador.

33

Al momento de crear o modificar una estación en el campo operador se debe poder seleccionar un único operador de la lista operadores y asignar el código del mismo al campo.

Al momento de crear o modificar una estación digital el campo identificador ANE SFN se debe poder seleccionar un único código de una lista donde se muestre toda la información técnica de los identificadores.

La información técnica de la antena de la estación se debe agregar a partir de cargar un archivo .a3d.

Se deben validar todos los campos del formulario de creación o modificación de estaciones para que la información suministrada este acorde a los parámetros de la ANE.

Se debe asignar automáticamente el callsign de la estación.

3.2.1.3 Soporte y mantenimiento.

En el anexo técnico se encuentran los requerimientos básicos sobre los cuales se realizó el soporte y mantenimiento a la herramienta web sistema de simulación en línea.

3.3 DISEÑO Y DESARROLLO DE LOS REQUERIMIENTOS

3.3.1 Capa de presentación ui.

Todas las modificaciones realizadas en el diseño de la herramienta web sistema de simulación en línea fueron implementadas acorde con los lineamientos de la estrategia del Programa de Gobierno en Línea y con la presentación gráfica ajustada al propósito de la ANE. Básicamente la parte grafica esta soportada en HTML5, javascript y CSS3.

3.3.2 Capa de negocios bll.


Es una extensión del módulo de simulación de Spectrum-e©, por tal razón se tuvo que solicitar a ATDI la inclusión de esta herramienta en el sistema de simulación en línea cumpliendo con el requerimiento que los cálculos obtenidos debían ser bajo la Recomendación UIT-R P.1546-4, a partir de la actualización realizada por ATDI a Spectrum-e©, TES AMERICA ANDINA SAS realizo la personalización de la herramienta de simulación del servicio punto-multipunto a las necesidades y parámetros técnicos establecidos por la ANE.


Esta herramienta fue creada en su totalidad por TES AMERICA ANDINA SAS y anexada al sistema de simulación en línea como un nuevo módulo. Para la realización del mismo se mantuvo la misma estructura usada por la herramienta Spectrum-e© (funciones, archivos etc).

34

3.3.3 Capa de datos dal.


El sistema de simulación en línea debe usar la información del SGE para realizar los estudios de interferencia. Por tanto, se debe migrar información desde SQL server 2008 R2 a MongoDB. Para obtener dicha información se implementa una vista en SQL server 2008R2 que entregue la información técnica y administrativa de las estaciones de cubrimiento en el SGE. La información de dicha vista se guarda en un archivo .CSV mediante la utilidad bcp de SQL server ejecutando desde la consola de Windows el siguiente código:

bcp BDSGE.dbo.vistaCubrimiento out C:\anesimulacion\vistaCubrimiento.csv -w -S direciónSGBD -U usuario -P contraseña -t","

Una vez se tiene el archivo .csv con la información de las estaciones de cubrimiento,

se crea una colección en MongoDB con dicha información.


Se crearón las siguientes colecciones dentro de la base de datos de Spectrum-e© en MongoDB para almacenar la información de este módulo:

Colección1.

En esta colección se almaceno la información del CNABF correspondiente al servicio de televisión.

Colección2.

En esta colección se almaceno la información administrativa de los municipios de Colombia.

Colección3.

En esta colección se almacena la información técnica y administrativa de las estaciones ingresadas en el módulo del servicio de televisión.

Colección4.

En esta colección se almacena la información de los operadores de televisión habilitados por la ANTV.

Colección5.

En esta colección se almacenan los identificadores asignados por la ANE a la combinación de características técnicas de las estaciones de televisión digital.

3.4 METODOLOGIA

La metodología implementada se basó en las metodologías agiles de desarrollo de software en especial SCRUM, se debe tener presente que las personas

35

involucradas en este proyecto no se encontraban en el mismo sitio. A continuación, se listan los roles y artefactos usados durante el desarrollo del proyecto:

PO: Persona encargada en TES AMERICA ANDINA SAS de gestionar la PB, expresando claramente los requerimientos de los SH del sistema de simulación en línea además de ordenar los elementos de la PB para alcanzar los objetivos de la siguiente entrega del producto, ubicación Bogotá DC.

SH: ANE (ubicación Bogotá DC), PRST (ubicación Colombia).

PB: Lista actualizada con los requerimientos de los SH.

DT: El equipo de desarrollo estuvo compuesto por un desarrollador de TES AMERICA ANDINA SAS con 100% de disponibilidad en el proyecto (autor, ubicación Sogamoso) y el área de soporte de la empresa (ubicación Bogotá DC), además de contar con el área de soporte y desarrollo de ATDI (ubicación McLean,Virginia (USA)) cuando fuese necesario realizar cambios a Spectrum-e©.

Sprint: Fue imposible fijar un TB fijo debido a que también debía realizarse soporte y mantenimiento a la herramienta durante el desarrollo del proyecto, además que en ocasiones se debió solicitar cambios en Spectrum-e© a ATDI, por lo cual cualquier tipo de Reunión de Planificación del Sprint para fijar el SB podría crear una falsa ilusión de estar haciendo algo mal al final del sprint al no poder completar las metas y tareas fijadas en SB por haber “perdido” tiempo de desarrollo dando soporte o esperando el soporte o desarrollo solicitado a Spectrum-e©.

3.5 APLICACIÓN DE LA METODOLOGIA

A continuación, se presenta el proceso de desarrollo e implementación del requerimiento “Al momento de crear o modificar una estación en el campo operador se debe poder seleccionar un único operador de la tabla operadores y asignar el código del mismo al campo” de la PB mediante la metodología utilizada en este proyecto. Cada nuevo requerimiento consecutivo se obtiene después de entregar un requerimiento. La Tabla 3 se muestra la estructura básica utilizada en la PB del proyecto

Tabla 3. Estructura básica de la PB en el proyecto.

Requerimiento prioridad Tipo encargado estado

A continuación se describen las columnas de la Tabla 3:

Requerimiento: Descripción de lo que pedía el cliente para el modulo, escrito en el lenguaje usado por los SH.

Prioridad: Valor de 1 a 5, siendo 5 la prioridad más alta.

Tipo: Sus valores podían ser: Soporte, Mantenimiento, ajuste o desarrollo.

Encargado: Persona que debía realizar el requerimiento.

36

Estado: Valor que indicaba la condición del requerimiento. Los estados posibles para un requerimiento fueron los siguientes: Terminado, Proceso o en espera.

Para las tareas se usó una estructura similar a la Tabla 3 cambiando la columna requerimiento por una columna tarea (escrita en lenguaje que entendiera el equipo de desarrollo) y agregando las columnas estimación (horas estimadas para realizar la tarea) y observación (donde se escribían novedades no contempladas en la planeación de la tarea).

3.5.1 Requerimiento inicial.

El requerimiento fue el siguiente: “El sistema de simulación en línea debe tener un módulo para el análisis de ingeniería de televisión”. Para cada requerimiento se tuvo que establecer las tareas necesarias para poder implementar dicho requerimiento en el sistema de simulación en línea; así pues, a continuación, se presentan las tareas más relevantes para cumplir con este requerimiento.

3.5.1.1 Tareas.

Establecer quien realizara la estructura básica del nuevo módulo de ingeniería de televisión (TES o ATDI).

Definir con la ANE las características principales de este nuevo módulo.

3.5.2 Requerimiento 2.

El requerimiento fue el siguiente: “El módulo de ingeniería de televisión será un nuevo módulo independiente de los existentes en el sistema de simulación en línea y deberá mostrar la información técnica de las estaciones de televisión”

3.5.2.1 Tareas.

Crear un botón en el menú inicial que permita acceder al módulo de televisión.

Crear una colección en MongoDB para almacenar la información técnica de las estaciones.

Crear una página que muestre la información técnica de las estaciones guardada en MongoDB.

Crear un formulario que permita ingresar la información técnica y administrativa de las estaciones a almacenar en MongoDB.


El requerimiento fue el siguiente: “Al momento de crear o modificar una estación en el campo operador se debe poder seleccionar un único operador de la lista de operadores que muestra la información administrativa de cada operador y asignar el código del mismo al campo operador”.

3.5.3.1 Tareas.

Crear una colección en MongoDB para almacenar la información de los operadores.

37

Agregar un botón a la ventana del módulo de tv que permita agregar o modificar operadores.

Agregar un botón en el formulario de agregar estaciones que permita seleccionar un operador para asignarlo a la estación.


El requerimiento fue el siguiente: “Se debe validar que el campo operador contenga información al momento de crear la estación”.

3.5.4.1 Tareas.

No permitir ingresar de manera manual información en el campo operador.

Validar que al momento de guardar la estación el campo operador contenga información.

38

4. RESULTADOS DEL PROYECTO

4.1 MODULO ANALISIS DE INGENIERÍA SERVICIO DE TELEVISIÓN

Este módulo es para uso exclusivo de usuarios con el rol de administrador en el sistema de simulación en línea. En la Figura 14 se aprecian todos los módulos al que un usuario de rol administrador puede ingresar en la herramienta sistema de simulación en línea.

Figura 14.Menu de inicio herramienta web Sistema de Simulación en Línea rol Administrador.

Fuente: simulacion.ane.gov.co:8088/se/login.php

Al acceder al módulo “Servicio de Televisión” se abre la ventana de la Figura 15. La cual muestra la información técnica de las estaciones del servicio de televisión, discriminándolas entre estaciones análogas y estaciones digitales, además de uno de los 3 estados posibles: modificado, rechazado o autorizado.

Figura 15.Ventana inicio modulo televisión herramienta web Sistema de Simulación en Línea rol Administrador.


En la Figura 15 el botón “Nuevo Registro” permite crear una estación y el botón “importar” permite ingresar varias estaciones mediante un archivo csv, al hacer click

39

en el botón “Nuevo Registro” se accede a la ventana de la Figura 16, Esta ventana posee 3 formularios: información de TV, Información de la señal e información de la antena. En ellos se debe ingresar la información administrativa y la información técnica de la nueva estación.

Figura 16.Ventana crear estación herramienta web Sistema de Simulación en Línea rol Administrador.


La información diligenciada por el usuario en los formularios, debe cumplir con los parámetros técnicos de la ANE de lo contrario la nueva estación no podrá ser creada tal y como se muestra en la Figura 17.

40

Figura 17.Ventana error crear estación herramienta web Sistema de Simulación en Línea rol Administrador.


Una vez creada una estación en el sistema de simulación en línea, esta continúa su trámite y se le asignara el estado rechazado o aprobado. Si es rechazada se podrá modificar la información técnica o administrativa de dicha estación para iniciar de nuevo el proceso en el sistema de simulación en línea, Si la estación es aprobada se puede generar CCTR de dicha estación, dependiendo del tipo de estación: análoga o digital se generara un CCTR similar al de la Figura 18 o al de la Figura 19.

41

Figura 18. CCTR estación análoga modulo TV herramienta web Sistema de Simulación en Línea rol Administrador.


Figura 19.CCTR estación digital modulo TV herramienta web Sistema de Simulación en Línea rol Administrador.


42

4.2 SIMULACIÓN DE COBERTURAS

Es una extensión del módulo de simulación del sistema de simulación en línea. Por tanto, para acceder a la nueva funcionalidad de simulación de coberturas se debe ingresar al módulo de simulación. En la Figura 20 se aprecia el menú de inicio con todos los módulos a los que un usuario de rol operador puede ingresar en la herramienta sistema de simulación en línea.

Figura 20.Menu de inicio herramienta web Sistema de Simulación en Línea rol Operador Mixto.


Al hacer click en el módulo resaltado en rojo de la Figura 20, se accede a la ventana de simulación mostrada en la Figura 21. El recuadro amarillo muestra las opciones principales, El recuadro rojo las funciones técnicas de la plataforma denominadas Gestión de red, el recuadro morado muestra los tipos de red que puede ser simulada denominado tipo de objeto y el recuadro verde los datos técnicos de las redes a simular.

Figura 21.Ventana módulo de simulación Sistema de Simulación en Línea.


43

4.2.1 Gestión de red.

A continuación, se describen las funciones más importantes del menú Gestión de red. Estas funciones cambian dependiendo del tipo de objeto seleccionado (enlace o estación). Todos los resultados son los obtenidos para la estación de la Figura 22.

4.2.1.1 Adicionar/Ver/Editar objeto.

Esta función sirve para ingresar una nueva estación a la red o editar parámetros de una estación existente. En la Figura 22 se aprecia la ventana de esta funcionalidad.

Figura 22.Ventana modificar objeto Sistema de Simulación en Línea.


4.2.1.2 Modificar objetos.

Esta función permite modificar el contenido de uno de los datos técnicos de una estación.

44

4.2.1.3 Mapear objetos seleccionados.

Esta función permite mostrar en el mapa la estación seleccionada en el área de datos técnicos. En la Figura 23 se muestra la ubicación de la estación en estudio.

Figura 23.Ventana mapa de Sistema de Simulación en Línea.


4.2.1.4 Validar plan de canalización.

Esta función permite validar que la frecuencia de la estación pertenezca al CNABF vigente. En la Figura 24 se presenta el resultado obtenido para la estación de estudio.

Figura 24.Ventana Validar plan canalización de Sistema de Simulación en Línea.


4.2.1.5 Actualizar msnm.

Esta función calcula los m.s.n.m de la estación de acuerdo con las coordenadas y la cartografía del sistema de simulación en línea.

45

4.2.1.6 Calcular pra.

Pese a que cuando se está creando la estación el campo pra puede ser llenado manualmente, se puede utilizar esta herramienta que toma los datos de la estación seleccionada, realiza el cálculo automáticamente y lo actualiza en la información del objeto.

4.2.1.7 Calcular haat.

Luego de seleccionar las estaciones a las que se les desea hacer el cálculo de la altura de la antena sobre el nivel medio del terreno, el sistema almacena el resultado en la columna “haat” de los objetos seleccionados.

4.2.1.8 Matriz itu-r p.1546-4.

El sistema de simulación en línea requiere de la matriz resultante de esta funcionalidad para poder realizar los cálculos de intensidad de campo, Potencia recibida (dl y ul), crear contorno de cobertura y polígonos cubiertos. Por tanto, se sugiere que, para obtener los resultados, primero se realice el cálculo antes de hacer cualquier otro proceso. Para realizar el cálculo de las pérdidas de trayecto del modelo itu-r p.1546-4, se debe seleccionar la estación. Posteriormente se abre un menú donde se puede ingresar la altura de la antena de recepción y la distancia para el cálculo como se aprecia en la Figura 25. Además de esto se puede abrir una ventana de Parámetros que le permite realizar el cálculo de la matriz para distintos propósitos: 50% como valor típico en porcentaje de localización, y en porcentaje de tiempo 50% para realizar el cálculo de las áreas de servicio y 10% para el cálculo de áreas interferentes.

Figura 25.Ventana matriz itu-r p.1546-4 de Sistema de Simulación en Línea.


46

4.2.1.9 Potencia recibida (dl).

Esta función muestra la cobertura downlink para la estación en el mapa tal y como se aprecia en la Figura 26.

Figura 26.Potencia recibida DL en Sistema de Simulación en Línea.


4.2.1.10 Polígonos cubiertos.

Esta función arroja una tabla con los municipios cubiertos y el porcentaje de cobertura después de usar la función de Potencia recibida (dl), como la que se aprecia en la Figura 27.

47

Figura 27.Poligonos cubiertos en Sistema de Simulación en Línea.


4.2.1.11 Importar estaciones existentes.

A través de esta función se pueden importar las estaciones autorizadas por el Ministerio de TIC, también se permite filtrar las estaciones según su posición (tomando inicialmente la posición de la estación seleccionada) y frecuencia máxima y mínima, en un rango de búsqueda. Además se da la opción de eliminar las estaciones existentes previamente cargadas, de esta manera se ofrece tener un mayor control sobre las estaciones a importar y las importadas, mediante la gestión de los mismos tal y como se aprecia en la Figura 28.

48

Figura 28. Importar estaciones existentes en Sistema de Simulación en Línea.


4.2.1.12 Posibles interferidos.

En esta función se puede saber si la nueva estación puede causar interferencia a las redes existentes, primero se selecciona la estación propuesta y luego click en la función. El sistema hace el análisis y almacena su resultado en las columnas de “Resultado” y “Solapamiento”, indicando si fue exitoso y el porcentaje de solapamiento respectivamente como se aprecia en la Figura 29.

Figura 29.Posibles interferidos por la estación en Sistema de Simulación en Línea.


4.2.1.13 Posibles interferentes.

En esta función se puede saber si la nueva estación podría verse interferida por las estaciones existentes, primero se selecciona la estación propuesta y luego click en la función. El sistema hace el análisis y almacena su resultado en la columna de

49

“Resultado”, indicando si la estación es interferida o no como se aprecia en la Figura 30.

Figura 30.Posibles interferentes de la estación en Sistema de Simulación en Línea.


4.2.1.14 Intensidad de campo.

Esta funcionalidad permite obtener de la estación seleccionada su área de radiación y la intensidad de campo calculada, diferenciada por colores como se aprecia en la Figura 31.

Figura 31.Intensidad de campo de la estación en Sistema de Simulación en Línea.


4.2.1.15 Crear contorno cobertura.

Esta función genera el contorno con los datos de la estación seleccionada y lo muestra en el mapa como se aprecia en la Figura 32.

50

Figura 32.Contorno de cobertura de la estación en Sistema de Simulación en Línea.


4.2.1.16 Potencia recibida (ul).

Esta función genera la cobertura uplink para la estación seleccionada y la muestra en el mapa como se aprecia en la Figura 33.

51

Figura 33.Potencia recibida UL de la estación en Sistema de Simulación en Línea.


4.3 SOPORTE Y MANTENIMIENTO TÉCNICO

A continuación en la Tabla 4 se presenta el resumen del soporte técnico dado por

el autor al sistema de simulación en línea durante el desarrollo del proyecto con

base en la Tabla 5 del anexo técnico.

En las fallas de prioridad 1 se tiene que el promedio en que se daba solución a un

soporte de este tipo fue de 3 horas. Para las fallas de prioridad 2 el promedio de

tiempo que se tardó en solucionar un soporte de este tipo fue de aproximadamente

10 horas. De los 13 soportes realizados de este tipo, en 2 debió realizarse nuevos

desarrollos para solucionar los soportes.

52

Tabla 4. Resumen soporte técnico Sistema de simulación en Línea.

Prioridad

Falla

Tiempo promedio

diagnostico falla(horas)

Tiempo promedio en

solucionar falla(Horas)

Numero de

soportes realizados

1 1 2 3

2 2 8 13

3 NA 22 20

En los soportes de fallas de prioridad 3 solo 4 soportes requirieron la realización de

cambios en los componentes de bajo nivel de la herramienta, teniendo un tiempo

promedio de 50 horas para solucionar la falla reportada, con lo cual para las fallas

que solo requerían cambios en la interfaz se tuvo un tiempo promedio en la solución

de la falla reportada de 15 horas.

53

5. CONCLUSIONES

Se presenta la aplicación de metodologías agiles de desarrollo de software en la

implementación en el sistema de simulación en línea de la ANE, de un módulo para

automatizar el análisis de ingeniería del servicio de televisión además de agregar la

opción de simular coberturas y realizar estudios de interferencia en las bandas

VHF/UHF con los parámetros técnicos utilizados por la ANE.

Al usar las metodologías agiles de desarrollo de software en un proyecto debemos

tener presente que estas no son un marco de trabajo rígido por lo cual no debemos

adaptar el proyecto de software a una metodología ágil de software específica, por

el contrario, debemos adaptar las metodologías al proyecto pues se tiene la

versatilidad de poder combinar varias metodologías dentro de un mismo proyecto

tal y como se hizo en la implementación de los nuevos módulos. Una de las

características en la aplicación de metodologías agiles de desarrollo de software es

la falta de documentación acerca del desarrollo del proyecto, la cual se suple con la

interacción continua de los involucrados en el mismo.

Al realizar el módulo de simulación se tuvo que trabajar conjuntamente entre TES

américa andina SAS y ATDI. La interacción entre los desarrolladores fue poca

debido a que se debían comunicar a través de terceros (área comercial de las 2

empresas). Por ello ATDI se encargó de realizar los desarrollos de componentes de

bajo nivel en dicho modulo y entregar una herramienta funcional básica para realizar

simulaciones de cobertura y estudios de interferencia en las bandas VHF/UHF con

base en la Recomendación UIT-R P.1546-4 y TES américa andina SAS se encargó

de adaptarlo a las necesidades de la ANE.

La metodología implementada fue importante para adaptar el proyecto ante las

modificaciones constantes en los requerimientos que generaba el cliente. Además

de los cambios que se tuvieron en las condiciones en que se debía realizar el

proyecto.

Al realizar el soporte de la herramienta se evidencio que alrededor de la mitad de

las fallas de tipo 1 reportadas fueron causadas por el mal uso del sistema de

simulación en línea. Por ello, se realizó una capacitación a los funcionarios de la

ANE y los PRST en el manejo de la herramienta. Además, de realizar el cambio de

los manuales de usuario del sistema de simulación en línea para hacerlos más

54

didácticos. En cuanto a las fallas de tipo 2, se tuvo que algunas fallas ocurrían de

manera sistemática en el sistema de simulación en línea, debido a que los usuarios

ingresaban información no válida para la herramienta. Al no utilizar o utilizar de

manera errónea los módulos para estas acciones con las que cuenta el sistema de

simulación en línea. Por ello, se sugirió mejorar dichos módulos agregando

validaciones que no permitan almacenar en la base de datos del sistema

información errónea para la herramienta.

55

LISTA DE ACRONIMOS

ANE: Agencia Nacional del Espectro.

ANTV: Autoridad Nacional de Televisión.

BLL: Bussines Logic Layer.

CCTR: Cuadro de Características Técnicas de la ed.

CMMI: Capability Maturity Model Integration.

CNABF: Cuadro Nacional de Atribución de Bandas de Frecuencias.

DAL: Data Acces Layer.

DT: Development Team.

HAAT: Altura de la Antena Sobre el Promedio del Terreno.

ITU: International Telecommunication Union.

MSF: Microsoft Solution Framework.

Ministerio TIC: Ministerio de Tecnologías de la Información y las Comunicaciones.

MSNM: Metros Sobre el Nivel del Mar.

PB: Product Backlog.

PO: Product Owner.

PRA: Potencia Radiada Aparente.

PRST: Proveedores de Redes y Servicios de Telecomunicaciones.

SB: Sprint Backlog.

SH: Stakeholders.

SGE: Sistema de Gestión del Espectro.

UI: User Interface.

XP: Extrem Programming.

56

REFERENCIAS BIBLIOGRÁFICAS

Agilemanifesto.org. (2017). Manifiesto por el Desarrollo Ágil de Software. [online] Available at: http://agilemanifesto.org/iso/es/manifesto.html [Accessed 15 May 2017].

Atdi.com. (2017). Spectrum-E | ATDI. [online] Available at: http://www.atdi.com/spectrum-e/ [Accessed 4 May 2017].

Canós, J. H., Letelier, P., & Penadés, M. C. (2003). Metodologías ágiles en el desarrollo de software. Metodologías Ágiles en el Desarrollo de Software, 1(10), 1-8.

Paulk, M. (1993). Capability maturity model for software. Encyclopedia of Software Engineering.

Chacón-Córdoba, R. A. (2011). Metodología base de gestión de proyectos para una empresa de desarrollo de software.

Chrissis, M. B., Konrad, M., & Shrum, S. (2011). CMMI for development: guidelines for process integration and product improvement. Pearson Education.

Chrissis, M. B., Konrad, M., & Shrum, S. (2012). CMMI® para desarrollo: guía para la integración de procesos y la mejora de productos. Editorial Universitaria Ramón Areces.

COLOMBIA. Decreto N° 4169.Diario Oficial de la Republica de Colombia. Bogotá, Colombia. 3 de noviembre de 2011.

COLOMBIA. Ley N° 1285.Diario Oficial de la Republica de Colombia. Bogotá, Colombia. 20 de enero de 1995.

COLOMBIA. Ley N° 1341.Diario Oficial de la Republica de Colombia. Bogotá, Colombia. 30 de julio de 2009.

ANE, A. (2016). CUADRO NACIONAL DE ATRIBUCIÓN DE BANDAS DE FRECUENCIA ACTUALIZACIÓN JULIO 2016. Bogota: ANE.

Devx.com. (2017). A Practical Guide to Seven Agile Methodologies, Part 2: Page 2. [online] Available at: http://www.devx.com/architect/Article/32836/0/page/2 [Accessed 12 May 2017].

Docs.mongodb.com. (2017). Introduction to MongoDB — MongoDB Manual 3.4. [online] Available at: https://docs.mongodb.com/manual/introduction/ [Accessed 4 May 2017].

Extremeprogramming.org. (2017). Extreme Programming: A Gentle Introduction.. [online] Available at: http://www.extremeprogramming.org/ [Accessed 12 May 2017].

Fernández Martínez, J. D., Cadavid, A. N., & Morales Vélez, J. (2013). Revisión de metodologías ágiles para el desarrollo de software.

57

Fowler, M. (2017). The New Methodology. [online] martinfowler.com. Available at: https://www.martinfowler.com/articles/newMethodology.html [Accessed 12 May 2017].

Garrido, J. C. (2004). Arquitectura y diseño de sistemas Web modernos. InforMAS, Revista de Ingeniería Informática del CIIRM, (1).

Group, D. (2017). About the Apache HTTP Server Project - The Apache HTTP Server Project. [online] Httpd.apache.org. Available at: http://httpd.apache.org/ABOUT_APACHE.html [Accessed 16 May 2017].

Mora, S. L. (2002). Programación de aplicaciones web: historia, principios básicos y clientes web. Editorial Club Universitario.

Netbeans.org. (2017). NetBeans IDE - Overview. [online] Available at: https://netbeans.org/features/index.html [Accessed 16 May 2017].

Php.net. (2017). PHP: ¿Qué es PHP? - Manual. [online] Available at: http://php.net/manual/es/intro-whatis.php [Accessed 4 May 2017].

Santimacnet's Blog. (2017). Microsoft Solutions Framework 5.0 (MSF). [online] Available at: https://santimacnet.wordpress.com/2010/12/20/microsoft-solutions-framework-5-0-msf/ [Accessed 12 May 2017].

Sciatel.wikispaces.com. (2017). sciatel - APLICACIÓN WEB. [online] Available at: https://sciatel.wikispaces.com/APLICACI%C3%93N+WEB [Accessed 16 May 2017].

Schwaber, K., & Sutherland, J. (2013). La guía de scrum: La guía definitiva de scrum, las reglas del juego.

Tesamerica.com.co. (2017). Quienes somos - tesamerica.com.co. [online] Available at: http://www.tesamerica.com.co/ [Accessed 4 May 2017].

Uribe, E. H., & Ayala, L. E. V. (2007). Del manifiesto ágil sus valores y principios. Scientia et technica, 1(34).

Wells, C. (2017). Development Methodologies. [online] Technologyuk.net. Available at: https://www.technologyuk.net/computing/sad/methodologies.shtml [Accessed 12 May 2017].

58

ANEXOS

ANEXO TECNICO

Las características del servicio a prestar, deben cumplir con las siguientes especificaciones:

1. A continuación se relacionan las condiciones del soporte técnico a ser prestado para la atención a fallas:

a. La disponibilidad para el soporte en el evento que se presente alguna falla debe ser de 5x8 de lunes a viernes.

b. Tiempo de atención y solución de fallas.

La columna Tipo 1, muestra el tiempo máximo que dispone el proveedor para recibir y diagnosticar fallas en un servicio, una vez éste haya sufrido una indisponibilidad. Su métrica se da en horas y depende del tipo de falla.

La columna Tipo 2, muestra el tiempo máximo que dispone el proveedor para solucionar la falla. Este tiempo se computa desde el momento del diagnóstico de la falla.

Para establecer los indicadores correspondientes, se han definido 3 niveles de falla de acuerdo con la afectación o severidad del problema presentado y la prioridad que debe dársele a la solución de la misma.

Tabla 5. Tipos de fallas.

Caracterización de la Falla

Prioridad Efecto Descripción Tipo 1 Tipo 2

1 Falla grave

Se entiende que el servicio prestado por el aplicativo ha dejado de funcionar y no se puede

acceder al mismo, o accediendo no se permiten el uso de todas sus funcionalidades.

1 horas 3 horas

2 Operación degradada

Servicio restringido; presenta fallas intermitentes que impiden a algunos usuarios el uso del

aplicativo y la solución no requiere desarrollo 3 horas 5 horas

Servicio restringido; presenta fallas intermitentes que impiden a algunos usuarios el uso del aplicativo y la solución requiere desarrollo

3 horas 48 horas

3 Mejora no funcional Se entiende como la que no afecta ni degrada la

prestación del servicio.

El tiempo de respuesta se acordara entre las

partes.

Se aclara que las fallas de prioridad 3 cuyo efecto es una mejora o modificación no funcional, la cual se entiende como la que no afecta ni degrada la prestación del

59

servicio. Se definen dos clases de fallas de prioridad 3: aquellas que se solucionan modificando únicamente la interfaz gráfica de la aplicación y aquellas que requieren intervención en los componentes de bajo nivel de la misma.

Para las fallas que se solucionan modificando únicamente la interfaz de la aplicación se define un tiempo máximo de entrega de una (1) semana para un máximo de 15 solicitudes por semana. Para una cantidad mayor se establecerá de mutuo acuerdo los tiempos de entrega.

Para las fallas que se solucionan modificando los componentes de bajo nivel se define un tiempo máximo de solución de dos (2) semanas para un máximo de 5 solicitudes por semana. Para una cantidad mayor se establecerá de mutuo acuerdo los tiempos de entrega.

c. Todo requerimiento deberá ser coordinado previamente con el supervisor del contrato, con el fin de no generar traumatismos en la normal prestación de los servicios de la entidad.

d. El proveedor deberá prestar el servicio de soporte a través de medio telefónico o a través de la web o por correo electrónico o presencial en la administración, configuración, resolución de problemas de software, de manera ilimitada durante el tiempo de garantía de la solución implementada.

e. Todo soporte técnico que requiera apagado del equipo donde se encuentre instalada la solución implementada deberá ser coordinado previamente con el supervisor del contrato, con el fin de no generar traumatismos en la normal prestación de los servicios de la entidad.

f. Los costos en que incurra el contratista para atender cualquier solicitud de soporte, mantenimiento correctivo o preventivo, ya sea mano de obra, traslados, e insumos necesarios para garantizar el correcto funcionamiento de la herramienta de desarrollo y la solución implementada, durante la ejecución y el período de soporte y garantía de estos software, correrán por cuenta del contratista, por lo tanto, no tendrá costo adicional para la entidad.

El proveedor deberá informar oportunamente sobre las vulnerabilidades que afecten la herramienta de desarrollo y la solución implementada, aplicando los correctivos necesarios ajustándose al modelo de seguridad implementado en la entidad, durante el periodo de ejecución del contrato.

2. Actividades de mantenimiento:

a) El contratista realizará las actualizaciones que requiera el Sistema de Simulación en Línea, ya sea por actualizaciones propias de los servidores donde se encuentra alojada la herramienta o por actualización o cambio de alguno de los infraestructura tecnológica de la ANE, por ajustes que el Ministerio TIC realice a la herramienta SGE y que influyan al normal funcionamiento de la herramienta, por cambios en los navegadores web o por cambios en los protocolos de internet que pueda realizar la entidad.

60

b) El contratista, incluirá mejoras continuas y soporte preventivo de los componentes y funcionalidades de la herramienta.

c) Actualización, administración, monitoreo, reindexación, compactación de la base de datos del módulo de Televisión en caso que se necesite.

3. El contratista realizará la siguiente mejora: en la herramienta en el módulo de microondas para que existan advertencias de asignación bajo condiciones “Hi-Lo violation”, entre el enlace propuesto y los enlaces existentes.

4. Se deberán ajustar los parámetros de interferencia de acuerdo con los resultados de las pruebas de simulación que se realicen entre el supervisor y el contratista, lo anterior, para robustecer los parámetros a valores más restrictivos.

5. Agregar al módulo de simulación la opción de simular señales digitales en las bandas VHF/UHF (Tabla 3A, Tabla 11, Tabla 12, Tabla 13 del CNABF) Mediante parámetros ITU.RP1546-5 (servicio punto- multipunto).

Evaluación del ciclo de vida del aceite de motor como producto … · 2018-09-26 · 2.1...

Documents

Transcript of Evaluación del ciclo de vida del aceite de motor como producto … · 2018-09-26 · 2.1...