1
Universidad de las Ciencias Informáticas Facultad 2
Gestión de Acceso a Equipos Telefónicos.
TRABAJO DE DIPLOMA
PARA OPTAR POR EL TÍTULO DE INGENIERO EN CIENCIAS INFORMÁTICAS
Autores:
Maykel Yáñez Pérez.
René Serrano Pérez.
Tutor(s): René Yáñez de la Rivera Víctor Marín Contreras
Ciudad de la Habana Junio 2009
2
Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber.
Albert Einstein
3
DECLARACIÓN DE AUTORÍA
Declaramos ser autores del presente Trabajo de Diploma, de esta forma reconocemos y autorizamos a la Universidad de las Ciencias Informáticas a hacer uso del mismo como considere necesario.
Para que así conste, firmamos la presente a los 27 días del mes Junio de 2009.
__________________________ __________________________
Firma de los autores Firma de los autores Maykel Yáñez Pérez René Serrano Pérez
__________________________ ________________________
Firma del tutor Firma del tutor René Yáñez de la Rivera Víctor Marín Contreras
4
OPINIÓN DE USUARIO DEL TRABAJO DE DIPLOMA
El Trabajo de Diploma titulado “Gestión de Acceso a Equipos Telefónicos” fue realizado en la Universidad de las Ciencias Informáticas. Esta entidad considera que en correspondencia con los objetivos trazados el trabajo realizado le satisface:
Totalmente ____
Parcialmente en un ______ %Los resultados de este Trabajo de Diploma le reportan a esta entidad los beneficios siguientes:
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
_______________________________________________________________________________________________
______________________________________________________________________________________
Y para que así conste, se firma la presente a los ____ días del mes de ______ del 2009.
____________________________ ______________________
Representante de la entidad Cargo
_____________________ _______________
Firma Cuño
5
OPINIÓN DE LOS TUTORES DEL TRABAJO DE DIPLOMA
Título: Gestión de Acceso a Equipos Telefónicos Autores: Maykel Yáñez Pérez
René Serrano Pérez
El tutor del presente Trabajo de Diploma considera que durante su ejecución los estudiantes mostraron las cualidades que a continuación se detallan:
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
________________________________________________________________
Por todo lo enunciado anteriormente considero que los estudiantes están aptos para ejercer como Ingenieros en Ciencias Informáticas; de esta forma propongo que se le otorgue al Trabajo de Diploma la calificación de ______.
___________________________ ___________________________
Dr. René Yáñez de la Rivera Dr. Víctor Marín Contreras
______de Junio del 2009.
6
AGRADECIMIENTOS
No resulta fácil agradecer a todas las personas que han estado conmigo brindándome su apoyo en cada momento en estos 5 cursos aquí en la UCI, pero de una manera u otra quiero agradecerles de todo corazón por haber estado conmigo en los momentos buenos y malos. En especial quiero agradecer a mi madre que ha sido mi guía y es la fuerza de mi inspiración desde que era un niño y ha estado ahí siempre para aconsejarme y brindarme todo su cariño incondicional. Agradecer a mis tutores el Dr. René Yáñez y Dr. Víctor Marín por todo el apoyo que nos dieron durante el desarrollo de este trabajo brindándonos su conocimiento y ayuda a lo largo de nuestra tesis, en especial agradecer al tutor el Dr. René Yáñez que más que tutor es mi padre y a quien le debo gran parte de mi formación, no solo como ingeniero sino como hombre. Agradecer a mis hermanos por preocuparse cada día por mí a lo largo de mi carrera como estudiante desde que era un niño. Quiero agradecer también a mi compañero de tesis René, un amigo a quien aprecio mucho quien me ha ayudado a adquirir gran parte del los conocimientos que he aprendido a lo largo de mi carrera aquí en la universidad. Agradecer de forma especial a mis amigos del alma (Nino, Rega, Alain Yanet, Esneil, Malena, Toledo, Elier, Dayán y Yasel) que siempre han estado ahí para brindarme su ayuda y apoyo en todos los momentos de la vida en esta universidad y en especial agradecer al Nino por ser el mejor de los mejores amigos y más que amigo un hermano para mí.
Maykel Yáñez Pérez.
Quiero agradecer a todas las personas que ayudaron a que fuera posible el desarrollo de este trabajo, a todos aquellos que estuvieron presentes cuando más se les necesitaba, y que siempre demostraron su disposición de brindarnos su ayuda. En especial quiero agradecer a mi madre y a mi hermana, quienes han sido mis guías y siempre han tenido plena confianza en mí, que me han ayudado, en mi formación como profesional y se han sentido orgullosas de mí. Quisiera agradecer también a mi novia, quien me ha ayudado mucho en estos meses, quien siempre ha estado a mi lado para darme consejos y darme su apoyo, a mis tutores el Dr. René Yáñez y Dr. Víctor Marín, quienes en este tiempo nos han aportado gran parte de sus conocimientos y les debemos en gran parte el desarrollo de este trabajo, a todo el equipo de GKT, que siempre estuvieron dispuestos a brindarnos su ayuda.
Agradecer de manera especial a mis amigos (Repa, Chistian, Luis, Yasel, Yadier, Alejandro, Rayner) y en
7 especial a mi compañero de tesis Maykel, que es un excelente amigo y es el tipo de persona con la que me gustaría trabajar en un futuro.
René Serrano Pérez.
8
DEDICATORIA
Dedico mi tesis a mi familia en especial a mi madre a quien quiero con todas las fuerzas de mi corazón y es la luz de mi inspiración y guía en la vida. Dedico también este trabajo a mi sobrina Camila María que me ha llenado de alegría y amor desde el día que nació.
Maykel Yáñez Pérez.
Quiero dedicar este trabajo a mi familia en especial para aquellos que no están y que se que les gustaría mucho verme graduado, a mis padres y a mi hermana, quienes me han servido como guía en el proceso de formación como profesional y como persona y a mi novia quien me ha dado muchas alegrías desde el momento en que la conocí.
René Serrano Pérez.
9
RESUMEN
La estrategia de investigación-desarrollo del Ministerio de la Informática y las Comunicaciones (MIC) está dirigida a la búsqueda de soberanía tecnológica y seguridad en su esfera de acción correspondiente. En tal sentido, todo Saber-Hacer (Know-How) que permita disponer de un producto de denominación nacional puede ser válido, si además, encuentra aplicación y nicho de mercado.
El área de Investigación y Desarrollo (I+D) de la empresa mixta Gran Kaiman Teleco (GKT S.A.), de conjunto con el Instituto Politécnico Superior “José Antonio Echeverría” (ISPJAE) y la Universidad de Pinar del Río, Hermanos Saíz, lleva adelante un proyecto con el propósito de obtener una gama de productos a introducir en el nivel de acceso de la red de telecomunicaciones del país en aplicaciones tales como centrales telefónicas privadas (PBX) y pasarelas de voz sobre IP (VoIP).
En el país coexisten múltiples marcas comerciales de PBX, con prestaciones en muchos casos sobre dimensionadas para las necesidades de pequeñas empresas, establecimientos y centros escolares. En la mayoría de los casos el costo es también elevado.
Sobre esta base, las instituciones mencionadas se han propuesto el desarrollo de una Central Telefónica Privada (PBX) para su introducción en dos posibles escenarios: uno, en entidades que requieran de un servicio de telefonía de mínimas prestaciones; y el segundo, como solución a la telefonía pública en poblados donde el número de usuarios sea relativamente pequeño.
En el diseño de este tipo de equipos un aspecto importante a tener en cuenta son las facilidades que deben incorporarse para la configuración de los servicios, la operación, el cobro de las llamadas correspondientes y la supervisión general del sistema. Estos aspectos pertenecen al tema denominado
“gestión” con implementaciones al nivel de desarrollo de paquetes de programas o software.
Bajo estas consideraciones es que se ha convocado el presente Diploma, cuyos objetivos son los siguientes:
1. Implementar una Software de configuración de mínimas prestaciones el cual permita la operación y el mantenimiento de una centralita digital privada o PBX de dimensiones reducidas desarrollada en el país.
10 2. Adquirir experiencias en la concepción de Software de configuración para su aplicación posterior
en sistemas de mayor complejidad.
Los resultados más relevantes del trabajo serán su contribución al desarrollo de productos de origen cubano, así como la experiencia a adquirir por las partes en la integración de un equipo de proyecto multidisciplinario.
11
INDICE
DECLARACIÓN DE AUTORÍA ... 3
OPINIÓN DE USUARIO DEL TRABAJO DE DIPLOMA ... 4
OPINIÓN DE LOS TUTORES DEL TRABAJO DE DIPLOMA ... 5
AGRADECIMIENTOS ... 6
DEDICATORIA ... 8
RESUMEN 9 INDICE 11 INTRODUCCION ... 14
CAPITULO 1: FUNDAMENTACION TEORICA. ... 18
1.1. Introducción. ... 18
1.2. Análisis de trabajos existentes. ... 18
1.3. Herramientas: ... 19
1.4. Tecnologías, lenguajes de programación y API... 20
1.4.1. Lenguaje de programación... 20
1.4.2. API ... 22
1.5. Lenguaje de modelado y metodología de desarrollo ... 22
1.5.1. Lenguaje de modelado UML. ... 22
1.5.2. Metodología de desarrollo RUP. ... 22
1.6. Conclusiones del Capítulo ... 23
CAPÍTULO 2: CARACTERÍSTICAS DEL SISTEMA. ... 24
2.1. Introducción. ... 24
2.2 Descripción General de los procesos que intervienen en el negocio ... 24
2.3. Objeto de estudio. ... 24
2.4. Situación problémica. ... 24
2.5. Objeto de automatización. ... 25
2.6. Información que se maneja ... 25
12
2.7. Propuesta del sistema. ... 26
2.8. Modelo del Negocio. ... 26
2.8.1. Realización de los casos de uso del negocio. ... 26
2.8.2. Modelo Objetos. ... 27
2.8.3. Reglas del Negocio. ... 27
2.9. Captura de requisitos ... 27
2.9.1. Requisitos Funcionales ... 28
2.9.2. Requisitos no Funcionales... 28
2.9.3. Modelo de casos de uso del sistema ... 30
2.9.4. Actores del sistema ... 30
2.9.5. Descripción de los casos de uso del sistema... 30
2.10. Conclusiones del capítulo ... 30
CAPITULO 3: ANÁLISIS Y DISEÑO ... 32
3.1. Introducción ... 32
3.2. Modelo de análisis ... 32
3.3. Modelo de diseño... 35
3.4. Diagramas de interacción ... 41
3.4.1. Diagramas de Comunicación. ... 41
CAPITULO 4: IMPLEMENTACIÓN ... 45
4.1. Introducción ... 45
4.2. Diagrama de despliegue ... 45
4.3. Diagrama de componentes ... 46
4.4. Conclusiones del capítulo ... 47
CAPITULO 5: ESTUDIO DE LA FACTIBILIDAD ... 48
5.1. Introducción ... 48
5.2. Planificación ... 48
5.2.1. Método de Estimación por Puntos de Casos de Uso ... 48
5.2.1.2.Factor de Peso de los Actores sin ajustar (UAW): ... 49
5.2.1.3. Factor de Peso de los Casos de Uso sin ajustar (UUCW) ... 49
5.2.1.5. Factor de Complejidad Técnica (TCF)... 51
5.2.1.6. Factor de ambiente (EF)... 52
13
5.2.1.7.Estimación del esfuerzo a través de los puntos de casos de uso ... 53
5.3. Factor de conversión (CF)... 54
5.3.1. Calcular esfuerzo de todo el proyecto ... 55
5.4. Beneficios tangibles e intangibles ... 56
5.5. Análisis de costos y beneficios ... 56
5.6. Conclusiones ... 57
CONCLUSIONES ... 58
RECOMENDACIONES ... 59
BIBLIOGRAFIA ... 60
ANEXOS 62 Anexo #1 Diagrama de Caso de Uso del Negocio. ... 62
Anexo #2 Descripción textual del CU del negocio Configurar pizarra telefónica privada (PBX). ... 62
Anexo #3 Modelo de Objeto ... 64
Anexo #4 Descripción de los actores del Negocio ... 64
Anexo #5 Diagrama de Casos de Usos del Sistema ... 65
Anexo #6 Descripciones de los Casos de Usos del Sistema... 65
Anexo #7 Explicación a través de los Tutoriales I y II de todo el proceso de información para la realización del software. ... 90
GLOSARIO DE TERMINOS ... 99
14
INTRODUCCION
El departamento de telecomunicaciones y el CIME del ISPJAE, desarrollan de conjunto con la empresa mixta cubano-china GKT S.A., un proyecto de nivel ramal denominado “Plataforma de conmutación de paquetes” que responde a las líneas priorizadas de los programas del Ministerio de Informática y Telecomunicaciones (MIC).
El proyecto en cuestión tiene como propósito el desarrollo de productos de origen cubano en el campo de la Voz sobre IP (VoIP) y redes de próxima generación (NGN), que encuentren nichos de mercado y aplicación en la digitalización de zonas con características especiales, como pueden ser los pueblos de baja densidad poblacional donde pudieran no justificarse grandes inversiones.
El trabajo es muy amplio y se ha divido en varias tareas: una de estas ha sido el diseño de una Interfaz Digital de abonados que no es más que el módulo o tarjeta que da servicio a los terminales telefónicos analógicos, con facilidades de señalización y de conmutación, previo al proceso de paquetización en sí.
Actualmente se dispone de tarjetas de cuatro abonados controladas por lógica programable con las cuales se puede obtener un producto independiente como es una Pizarra telefónica privada (PBX) de bajas prestaciones que puede tener aplicación en pequeños establecimientos o empresas.
Para convertir tales resultados en un prototipo serie cero con aplicación a clientes, se requiere realizar un cúmulo de trabajo, entre los cuales estaría la implementación de un Software de configuración de mínimas prestaciones, sin el cual no sería posible la explotación del equipo.
Dado lo anterior, surge la siguiente situación problémica:
No existe un método para realizar configuraciones en la central telefónica privada (PBX) y de esta manera lograr su explotación.
Necesidad de visualizar la información que se maneja en la central.
15 Lo que nos conduce a la siguiente interrogante: ¿Cómo mejorar los procesos de configuración y gestión de información en la central?
Por tal razón el objeto de estudio está relacionado con los procesos para la configuración de una PBX.
Teniendo en cuenta el objeto de estudio expuesto se infiere que el campo de acción va a estar enfocado hacia procesos automatizados para la configuración y control de una PBX.
Para el desarrollo de la investigación se trazó el siguiente objetivo general: Desarrollar un software de configuración de mínimas prestaciones, el cual permita la operación y el mantenimiento de una central digital privada o PBX de dimensiones reducidas desarrollada en el país.
Objetivos específicos:
Desarrollar un software de configuración a operar como una aplicación en una PC de propósito general, que permita el acceso y configuración de una central privada digital (PBX) cuyos bloques principales son una tarjeta de Interfaz de abonado digital, diseñada con circuitos integrados comerciales de uso en telefonía, y un controlador basado en la familia de dispositivos lógicos programables de la familia MAX II de la firma Altera.
Implementar dicho software de manera que la comunicación con la PBX se realice por puerto serie, facilidad de la que se dispone en la tarjeta o Kit de desarrollo que contiene el dispositivo programable utilizado, en este caso un CPLD (Dispositivo de Lógica Programables Complejo) de la familia MAX II, mencionada anteriormente.
Tomar en cuenta en el diseño que el acceso será a una base de datos contenida en la memoria de usuario de dicho CPLD, la cual se conoce como UFM (User Flash Memory). La misma tiene sus especificidades a considerar, entre estas, la limitación a 1024 localizaciones y la organización en dos sectores, el 0 y el 1, siendo necesario para el borrado y escritura, operar con sectores completos.
Concebir una primera versión del software de configuración que contemple prestaciones básicas:
- Asignación de números a extensiones y troncales.
- Derechos de usuarios a recibir o salir por uniones externas o troncales.
- Listar información de extensiones y troncales de la central.
Garantizar una operación segura de manera que el impacto de la configuración, en una operación
16 de escritura, sea el mínimo si se produce una falla. Esto significa el disponer de un mecanismo que permita recurrir a una posible configuración por defecto la cual siempre podrá ser activada.
Implementar otras medidas de seguridad informática basadas en la identificación o autenticación del personal autorizado a entrar en el sistema.
Concebir un software en un ambiente gráfico ameno y sencillo desde el punto de vista de su operación que sea fácil de usar por los usuarios finales.
Tareas de la Investigación.
1. Realizar un análisis de la información precedente respecto al tema de investigación.
2. Realizar un estudio de los principales sistemas para la configuración de centrales telefónicas privadas (PBX), identificando sus características fundamentales y limitaciones.
3. Realizar un estudio de las tecnologías, lenguajes, metodologías y herramientas propuestas por el cliente para el desarrollo de la aplicación.
4. Trabajar de conjunto, en equipo multidisciplinario, interpretando la documentación elaborada por los encargados del diseño de la parte electrónica o hardware, especialmente aquella en donde se acuerdan los protocolos de comunicación entre los módulos que conforman la PBX, y la interfaz del software de configuración.
5. Realizar la implementación de un software de configuración para la central telefónica privada (PBX).
Para la realización y cumplimiento de los objetivos y las tareas propuestas se utilizó el siguiente método teórico:
Analítico sintético: Son dos procesos inherentes al pensamiento, operaciones lógicas importantes; que nos permiten; como métodos teóricos, buscar la esencia de los fenómenos, los rasgos que los caracterizan y los distinguen.
Su objetivo en una investigación es analizar las teorías, documentos, etc.; permitiendo la extracción de los elementos más importantes que se relacionan con el objeto de estudio.
17 El documento quedó estructurado de la siguiente forma:
En el Capítulo 1 “Fundamentación Teórica”: Se desarrolla un estudio de sistemas para la configuración de centrales telefónicas, se exponen los conceptos fundamentales relacionados con el tema de investigación y se describen los lenguajes, las herramientas y metodologías a utilizar para el desarrollo de la aplicación.
En el Capítulo 2 “Características del Sistema”: Se realiza la descripción del sistema a implementar, se especifican los procesos del negocio, los requisitos de software y el modelo de casos de uso del sistema.
En el Capítulo 3 “Análisis y Diseño del Sistema”: Se desarrolla el flujo de trabajo de Análisis y Diseño, mediante la representación de los diagramas de clases y de interacción correspondiente, el modelo lógico y físico de datos.
En el Capítulo 4 “Implementación”: Se representan los diagramas de componentes y despliegue correspondientes al flujo de trabajo de implementación.
En el Capítulo 5 “Estudio de la Factibilidad”: Se realiza un estudio de la factibilidad del proyecto, empleando para ello el método de estimación por Puntos de Casos de Uso.
18
CAPITULO 1: FUNDAMENTACION TEORICA.
1.1. Introducción.
En el presente capítulo se tratarán una serie de temas que ayudarán a familiarizarse con el problema planteado, con los que se espera que se comprenda la propuesta de solución dada y la importancia de la misma. Se caracterizan las tendencias, herramientas, tecnologías y metodologías usadas para desarrollo de la aplicación y se realiza un breve estudio de los diferentes sistemas de configuración para Pizarras telefónicas privada (PBX) existentes en el ámbito nacional e internacional así como la propuesta de desarrollo de un software de configuración a realizar.
1.2. Análisis de trabajos existentes.
En la Universidad de las Ciencias Informáticas están en desarrollo dos proyectos un poco relacionados con el software a desarrollar, sus nombres son PBX y Call Center.
1. Los Softwares de gestión de Pizarras telefónicas privadas (PBX) son desarrollados por el mismo fabricante, o sea que un fabricante de una marca solo hace el software para que se adapte solo al hardware de su propia marca por lo que es imposible que un software desarrollado por otra compañía se acople al equipo desarrollado por otro fabricante, debido a esta limitante el proyecto PBX de la UCI está desarrollando un sistema que se adapte a cualquier PBX sin importar la marca.
Permitiendo así poder visualizar la información que se maneja en la central. Debido a que la PBX antes planteada es la única de su tipo, la solución propuesta por el proyecto en cuestión no se puede adoptar. Este software no nos conviene por la simple razón que la PBX a la que se le va a hacer un software para su explotación es de origen cubano desarrollada en la CUJAE.
2. El proyecto Call Center se enfoca hacia el trabajo con la plataforma Asterick mejorando entre otras cosas la parte de gestión, se realizó un análisis para valorar la posibilidad de adoptar la gestión de Asterick, pero debido a una serie de inconvenientes, se decidió no hacer uso de esta.
19
Sistemas de configuración para PBX.
SOPHO IPC 100 Pro de la Philips:
Es una herramienta que permite la configuración y administración de las Pizarras telefónicas privadas (PBX) pertenecientes a la marca Philips. Este software es específico para la versión IPC 100 aunque puede servir para cualquier PBX que pertenezca a la misma familia.
Programmator de la Panasonic:
Es una herramienta que permite la programación, configuración y administración remota para la familia de PBX de la marca Panasonic. Con una interfaz gráfica fácil de comprender se puede ajustar los parámetros de la Pizarras telefónicas privadas (PBX). Casi todas las características de PBX pueden ser fácilmente modificados mediante acciones simples, conocidas por todos los usuarios de Windows. El sistema de ayuda del instalador puede resolver muchos problemas difíciles.
BusinessPhone Management Suite (BMS) de la Ericsson:
Es una herramienta para la configuración, administración, actualización y mantenimiento de la familia de sistemas BusinessPhone. Es una suite completa y sencilla de instalar y de utilizar y dispone de una muy amplia gama de alternativas de configuración. El software de servidor puede instalarse tanto en las dependencias del cliente como en las del distribuidor o del centro de servicio, y se puede acceder a él tanto local como remotamente mediante una interfaz de navegador web. El paquete admite múltiples usuarios y múltiples sistemas BusinessPhone.
1.3. Herramientas:
Netbeans 6.5 (IDE para la programación en java):
El IDE NetBeans es un galardonado entorno de desarrollo integrado para Windows, Mac, Linux y Solaris.
NetBeans consta de un IDE de código abierto y una plataforma de aplicaciones que permiten a los desarrolladores crear rápidamente aplicaciones Web y escritorio utilizando la plataforma Java, así como PHP, Java Script, Ajax, Ruby y C / C + +. Cuenta con el apoyo de una vibrante comunidad de desarrolladores.
20 JDK 6.0: Java Development Kit (JDK) 6. Paquete de desarrollo en java.
JRE 6.0: Java Runtime Environment (JRE) 6, Para la ejecución de aplicaciones en Java.
Visual Paradigm para UML (VP-UML):
Es una poderosa herramienta CASE multiplataforma (Windows/Linux/Mac OS X) que soporta el ciclo de vida completo del desarrollo de software. Está diseñado para un amplio rango de usuarios, que estén interesados en la construcción de sistemas de software confiables mediante el uso de la Orientación a Objetos.
Este software facilita una rápida construcción de aplicaciones de calidad y a un menor coste. Visual Paradigm para UML soporta un conjunto de lenguajes (Java, C++, PHP y Python), tanto en generación de código como ingeniería inversa.
Entre sus características principales se pueden citar:
• Soporta UML en su versión 2.1.
• Facilita la comunicación de todo el equipo de desarrollo mediante el uso de un lenguaje estándar común.
• Posibilita el desarrollo de la ingeniería directa e inversa.
• Durante todo el ciclo de desarrollo el modelo y el código permanecen sincronizados, permitiendo la generación de código a partir de diagramas y viceversa.
1.4. Tecnologías, lenguajes de programación y API
1.4.1. Lenguaje de programación.
Java:
Java es un lenguaje de programación orientado a objetos. El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria.
21 Características de Java:
Lenguaje simple
Java posee una curva de aprendizaje muy rápida. Debido a su semejanza con C y C++, y dado que la mayoría de la gente los conoce aunque sea de forma elemental, resulta muy fácil aprender Java.
Orientado a objetos
Java fue diseñado como un lenguaje orientado a objetos desde el principio. Los objetos agrupan en estructuras encapsuladas tanto sus datos como los métodos (o funciones) que manipulan esos datos. La tendencia del futuro, a la que Java se suma, apunta hacia la programación orientada a objetos, especialmente en entornos cada vez más complejos y basados en red.
Interpretado y compilado a la vez
Java es compilado, en la medida en que su código fuente se transforma en una especie de código máquina, los bytecodes, semejantes a las instrucciones de ensamblador.
Indiferente a la arquitectura
Java está diseñado para soportar aplicaciones que serán ejecutadas en los más variados entornos de red, desde Unix a Windows, pasando por Mac y estaciones de trabajo, sobre arquitecturas distintas y con sistemas operativos diversos. Para acomodar requisitos de ejecución tan variopintos, el compilador de Java genera bytecodes: un formato intermedio indiferente a la arquitectura diseñada para transportar el código eficientemente a múltiples plataformas hardware y software.
Portable
La indiferencia a la arquitectura representa sólo una parte de su portabilidad. Además, Java especifica los tamaños de sus tipos de datos básicos y el comportamiento de sus operadores aritméticos, de manera que los programas son iguales en todas las plataformas.
Estas dos últimas características se conocen como la Máquina Virtual Java (JVM).
Dinámico
El lenguaje Java y su sistema de ejecución en tiempo real son dinámicos en la fase de enlazado.
Las clases sólo se enlazan a medida que son necesitadas. Se pueden enlazar nuevos módulos de código bajo demanda, procedente de fuentes muy variadas, incluso desde la Red.
22
1.4.2. API
Rxtx-2.1: API que trae implementada una serie de funciones que permiten el trabajo con los puertos serie y paralelo de la computadora.
1.5. Lenguaje de modelado y metodología de desarrollo
1.5.1. Lenguaje de modelado UML.
UML es un lenguaje utilizado para el modelado de un sistema, permitiendo en mayor o menor medida representar todas las fases de un proyecto informático: desde el análisis con los casos de uso, hasta la implementación y configuración con los diagramas de despliegue.
UML permite:
Visualizar gráficamente un sistema de manera que otros puedan entenderlo.
Especificar cuáles son las características de un sistema antes de su construcción.
Construir sistemas diseñados a partir de modelos especificados.
Documentar los elementos gráficos del sistema desarrollado para futuras revisiones.
Además, aporta las siguientes ventajas:
El modelado con UML es independiente del lenguaje de implementación, de tal forma que los diseños realizados se pueden implementar en cualquier lenguaje.
Permite generar código a partir de los modelos y a la inversa, lo que posibilita la constante actualización.
1.5.2. Metodología de desarrollo RUP.
RUP (Rational Unified Process, en español Proceso Unificado del Software) es un proceso de desarrollo de software que junto al Lenguaje Unificado de Modelado (UML), constituye una metodología estándar muy utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
• Se utiliza en proyectos que se desarrollan a largo plazo.
• Genera un volumen considerable de documentación, posibilitando que los cambios realizados en los miembros del equipo no resulte un factor negativo para el avance del proyecto.
23
• Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros necesitan, lo cual se capta cuando se modela el negocio y se representa a través de los requerimientos. A partir de este momento los casos de uso guían el proceso de desarrollo, pues los modelos que se obtienen en los diferentes flujos de trabajo, representan la realización de los casos de uso.
• Centrado en la arquitectura: La arquitectura muestra la visión común del sistema en la que el equipo del proyecto y los usuarios deben estar de acuerdo. RUP se desarrolla mediante iteraciones, comenzando por los CU relevantes desde el punto de vista de la arquitectura.
• Iterativo e incremental: Propone que cada fase se desarrolle en iteraciones que involucran actividades de todos los flujos de trabajo. Es práctico dividir el trabajo en partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta un incremento. Las iteraciones hacen referencia a pasos en los flujos de trabajo, y los incrementos, al crecimiento del producto.
1.6. Conclusiones del Capítulo
Después de realizar el estudio de los sistemas utilizados en el mundo y en Cuba, para la configuración de Pizarras telefónicas privadas (PBX), se llegó a la conclusión de que los mismos presentan una serie de características interesantes, pero también limitaciones que impiden administrar de la forma deseada el hardware antes planteado. Por tanto se decidió elaborar una aplicación de escritorio sencilla, fácil de usar, multiplataforma, que reúna todos los requisitos propuestos por el cliente y permita una administración eficaz de nuestra Pizarra telefónica privada (PBX).
En la confección de la misma se utilizará RUP como metodología de desarrollo, UML como lenguaje de modelado empleando para la representación de sus diagramas la herramienta Visual Paradigm, Java como lenguaje de programación y RXTX-2.1, API para el trabajo con los puertos serie y paralelo de la computadora.
24
CAPÍTULO 2: CARACTERÍSTICAS DEL SISTEMA.
2.1. Introducción.
Es de suma importancia analizar las características y organización de los procesos que se desarrollan y que se pretenden automatizar, esto es un aspecto fundamental antes de empezar a desarrollar el sistema y se hace con el fin de lograr una mayor comprensión del problema que se desea resolver.
El presente capítulo tiene como premisa fundamental explicar el problema que da origen al tema de investigación (Software para la configuración de una Pizarra Telefónica Privada (PBX), desarrollada en la ISPJAE), exponer la propuesta del sistema a desarrollar, identificar los procesos que intervienen en el negocio y definir requerimientos funcionales, no funcionales, actores y casos de uso del sistema con sus respectivas descripciones.
2.2 Descripción General de los procesos que intervienen en el negocio
El proceso se inicia cuando el configurador o personal de mantenimiento comienza a consultar o configurar datos en la central, estos datos son todo lo referente al proceso de configuración.
2.3. Objeto de estudio.
Procesos relacionados para la configuración de una PBX.
2.4. Situación problémica.
El departamento de telecomunicaciones y el CIME del ISPJAE, desarrollan de conjunto con la empresa mixta cubano-china GKT S.A., un proyecto de nivel ramal denominado “Plataforma de conmutación de paquetes” que responde a las líneas priorizadas de los programas del Ministerio de Informática y Telecomunicaciones (MIC).
Una de las tareas de este proyecto consiste en la obtención de un producto independiente como es una PBX (Pizarra telefónica privada) de bajas prestaciones que puede tener aplicación en pequeños
25 establecimientos o empresas y un software que permita la configuración y el mantenimiento de dicho dispositivo.
Actualmente en el mundo existen un grupo de softwares que permiten a los usuarios interactuar con estos dispositivos telefónicos, pero estos tienen sus limitantes, como son: que cada software interactúa con un dispositivo específico, cuando más, con uno de la misma familia, estos softwares, al ser propietarios tienen un alto valor en el mercado.
Teniendo en cuenta las limitantes antes planteadas, pudimos llegar a la conclusión de que para dar solución a nuestra problemática, se requiere desarrollar un software que permita interactuar con el dispositivo antes planteado.
2.5. Objeto de automatización.
Con la realización del software de configuración que se espera obtener, se pretende automatizar los siguientes procesos:
Procesos de lectura.
Ver números de abonados de la central.
Ver números de troncales.
Listar abonados (puertos, extensiones, Entrada/Salida).
Listar troncales (puertos, numeración, Entrada/Salida).
Procesos de escritura.
Cambiar asignación de extensiones a una nueva numeración (Personalizada).
Dar derecho a extensiones y troncales.
2.6. Información que se maneja.
La información que se maneja es toda la referente a la Pizarra telefónica privada (PBX).
26
2.7. Propuesta del sistema.
Con el objetivo de mejorar las dificultades que existen en el proceso de configuración se decidió realizar una aplicación de escritorio sencilla, que se encargue de controlar eficientemente los parámetros requeridos y permita una fácil interacción con el cliente.
Dicha aplicación debe ser capaz de brindar diferentes servicios como:
Conocer el número de abonados de la PBX.
Conocer el número de troncales de la central.
Listar información de los abonados.
Listar información de los troncales.
Cambiar asignación de extensiones a una nueva numeración.
Cambiar los permisos de extensiones y troncales.
2.8. Modelo del Negocio.
Caso de Uso de Estudio del negocio: “Configurar Pizarra telefónica Privada (PBX)”. (Anexo #1)
El modelo de casos de uso del negocio, se describe mediante diagramas de casos de uso. Es una técnica que permite la descripción de los procesos de negocio de una organización en términos de casos de uso y actores del negocio ya definidos anteriormente, que se corresponden con los procesos del negocio y los clientes, respectivamente.
(Anexo #2)
El modelado de los casos de uso brinda una panorámica del proceso como tal del negocio pero para detallar el flujo de sucesos así como la forma de interactuar de los actores con proceso en si, por lo que es necesaria la realización de los casos de uso del negocio.
2.8.1. Realización de los casos de uso del negocio.
Al detallar los casos de uso del negocio, se sabe cuando comienza un caso de uso y cómo termina, brindando así una mayor comprensión de los procesos del negocio a clientes y desarrolladores.
Se describe de forma textual como se llevan a cabo las actividades dentro del negocio y quienes las realizan. (Anexo #4)
27
2.8.2. Modelo Objetos.
El modelo de objetos del negocio, es un modelo interno a un negocio, muestra la relación entre los trabajadores y entidades del negocio dentro del flujo de trabajo de modelo del negocio. (Anexo #3)
Una vez realizado el modelo de objetos es preciso definir las reglas que regirán el negocio, que no son más que las restricciones que existen en un negocio dado; entiéndase por esto las acciones no válidas que la aplicación debe controlar para que el negocio no colapse.
2.8.3. Reglas del Negocio.
Las reglas del negocio son aspectos que describen políticas que deben cumplirse o condiciones que deben ser satisfechas.
El usuario no podrá ver extensiones, troncales y puertos si no está conectado a la central.
Para descargar o subir configuración debe haberse autenticado antes.
Cuando se lleve a cabo una nueva configuración a los números de extensiones o troncales debe de ser de una forma organizada.
Solo una extensión podrá tener permiso de salida a las líneas de telefonía pública.
Una vez terminada toda la fase del modelado del negocio se hace indispensable la captura de requisitos, porque en él se establece qué tiene que hacer exactamente el sistema y como, también todo lo relacionado con la integridad del sistema.
2.9. Captura de requisitos
El flujo de trabajo de requerimientos es uno de los más importantes. Pudiera verse a los requisitos como al contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que se especifiquen. Los requisitos se dividen en dos grupos:
1. Requisitos funcionales 2. Requisitos no funcionales.
28
2.9.1. Requisitos Funcionales
Los requisitos funcionales son condiciones que el producto de software debe cumplir pues a partir de de estos requisitos es lo que se va a resolver en el sistema que se va desarrollar.
RF1: Listar extensiones, troncales y puertos de la central.
1.1: Conocer información de extensiones: puerto, No-extensión y entrada/Salida.
1.2: Conocer información de troncos: puerto, numeración y Entrada/Salida.
1.3: Conocer información de puertos: número, time-Slot y trama.
RF2: Autenticar usuario.
RF3: Cambiar usuario y contraseña.
RF4: Personalizar numeración y permisos de las extensiones.
4.1: Cambiar número de extensiones.
4.2: Cambiar permisos de extensiones.
RF5: Personalizar numeración y permisos de troncales.
5.1: Cambiar número de troncales.
5.2: Cambiar permisos de troncales.
2.9.2. Requisitos no Funcionales
Los requerimientos no funcionales especifican propiedades o cualidades que el producto de software debe tener, como restricciones del entorno o de la implementación, rendimiento, dependencias de la plataforma y facilidad de mantenimiento.
Requerimientos de Seguridad
El uso y manejo del sistema estará controlado; ya que la información podrá ser consultada y modificada solamente por el personal autorizado; estableciendo para ello un usuario y una contraseña para el administrador o personal de mantenimiento.
29 Requerimientos de Software
Las estaciones de trabajo clientes utilizarán como sistema operativo GNU/Linux en sus diversas distribuciones o la familia de Windows superior a Windows 98.
Tener instalado una máquina virtual de Java (Java Runtime Environment (JRE) 6.0).
Tener la DLL rxtxSerial.dll en el directorito Java\ jre\ bin
Requerimientos de Hardware La PC cliente tendrá como mínimo:
- Un computador Pentium IV o superior.
- 256 Mb de RAM o superior.
- Espacio libre en disco de 1 Gb.
Restricciones en el diseño y la implementación - Lenguaje de Programación Java.
- Herramienta de desarrollo NetBeans 6.5, JDK y JRE.
- Utilización del API RXTX-2.1.
Requerimientos de apariencia o interfaz externa - Interfaz sencilla y amigable.
Requerimientos de Usabilidad
La interfaz será fácil de usar para los diversos usuarios que interactúen con ella. El sistema estará bien documentado, con el fin de lograr un mejor uso de los servicios que este ofrecerá,
Requerimientos de Soporte
Se realizarán pruebas, mantenimiento, configuraciones, instalación. El sistema contará con la documentación apropiada para agilizar su mantenimiento y configuración. Se ofrecerán servicios de adiestramiento al personal que trabajará con el software.
Requerimientos legales
El producto y la documentación son propios de la UCI y la CUJAE.
30 Ya identificados y definidos los requisitos tanto funcionales como no funcionales que debe cumplir el sistema y haciendo uso de ellos se comienza la etapa del modelado del sistema
2.9.3. Modelo de casos de uso del sistema
Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema y cliente, resultando especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo. (Anexo #5)
2.9.4. Actores del sistema
Los Actores del Sistema definen el comportamiento y responsabilidades (rol) de un individuo, grupo de individuos, sistema automatizado o máquina, que interactúan con el sistema. Ellos realizan las actividades y son propietarios de elementos.
La descripción de los casos de uso del sistema, detallan las acciones que tienen lugar durante la interacción actor-sistema, es decir, describe el flujo de actividades que realiza el actor al hacer uso del sistema y las correspondientes respuestas del mismo.
2.9.5. Descripción de los casos de uso del sistema
Las descripciones de casos de uso son reseñas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso. (Anexo #6)
2.10. Conclusiones del capítulo
Para la realización de un software con calidad es necesario, tener un conocimiento avanzado de los principales procesos que intervienen en la investigación y una amplia visión del desarrollo del proyecto.
31 Por lo cual, en este capítulo quedaron reflejados: los principales procesos del negocio, los requerimientos funcionales y no funcionales que representan las características fundamentales de la aplicación a desarrollar, la propuesta del software y el diagrama de casos de uso del sistema con la descripción detallada de cada uno de ellos. Para una mejor comprensión de cómo fue todo el intercambio de información remitirse al Anexo #7 donde se explica el protocolo de comunicación utilizado para y la organización de la memoria de la central.
32
CAPITULO 3: ANÁLISIS Y DISEÑO
3.1. Introducción
El principal objetivo de este capítulo es representar el flujo de trabajo de Análisis y Diseño, mediante el modelo de clases del análisis, los diagramas de clases del diseño, los diagramas de secuencia del diseño para los casos de uso más significativos,
3.2. Modelo de análisis
Durante el análisis, se analizan los requisitos que se describen en la captura de requisitos; refinándolos y estructurándolos. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que ayude a estructurar el sistema entero, incluyendo su arquitectura.
33 Diagrama de Clases del Análisis: “CU Listar extensiones, troncos y puertos de la central”
Figura #4
Diagrama de Clases del Análisis: “CU Autenticar”
Figura #5
34 Figura #6
Diagrama de Clases del Análisis: “CU Personalizar numeración y permisos de los troncales”
Figura #7
Figura #8 Diagrama de Clases del Análisis: “CU Cambiar Contraseña”
35 En el diseño modelamos el sistema y encontramos su forma para que soporte los requisitos, incluyendo los no funcionales y otras restricciones que se le suponen. Una entrada esencial en el diseño es el resultado del análisis.
Diagrama de clases del diseño
36
37
38
39
40
41 Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un sistema, lo que conlleva modelar instancias concretas o prototípicas de clases interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento.
Un diagrama de Comunicación es un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de comunicación muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes. Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común. Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
3.4.1. Diagramas de Comunicación.
Diagrama de Comunicación: “CU Listar extensiones, troncos y puertos de la central” Escenario 1
Figura #14
Diagrama de Comunicación: “CU Listar extensiones, troncos y puertos de la central” Escenario 2
Figura #15
42 Diagrama de Comunicación: “CU Listar extensiones, troncos y puertos de la central” Escenario 3
Figura #16
Diagrama de Comunicación: “CU Personalizar numeración y permisos de las extensiones”
Figura #17
43 Figura #18
Diagrama de Comunicación: “CU Autenticar”
Figura #19
44 Figura #20
3.5. Conclusiones del capítulo
En este capítulo se mostraron los resultados obtenidos en el desarrollo del flujo de trabajo de análisis y diseño. Definiéndose los diagramas de clases del análisis, los diagramas de interacción y de clases del diseño, utilizando para ello el Lenguaje unificado de Modelado (UML) y la herramienta case Visual Paradigm.
45
CAPITULO 4: IMPLEMENTACIÓN
4.1. Introducción
En el presente capítulo se aborda lo referente al flujo de trabajo Implementación, para ello se exponen los diagrama de componente, representando la implementación de las clases del diseño en términos de componentes y el modelo de despliegue, informando los nodos en que estará distribuida la aplicación.
4.2. Diagrama de despliegue
El Modelo de Despliegue se utiliza para capturar los elementos de configuración del procesamiento y las conexiones entre esos elementos. También se utiliza para visualizar la distribución de los componentes de software en los nodos físicos.
Diagrama de Despliegue
Figura #20: Diagrama de despliegue
46
4.3. Diagrama de componentes
Es un diagrama que muestra un conjunto de elementos del modelo tales como componentes, subsistemas de implementación y sus relaciones.
Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las dependencias lógicas entre un conjunto de componentes software, sean éstos componentes de código fuente, librerías, binarios o ejecutables. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
Lo que distingue a un diagrama de componentes de otros tipos de diagramas es su contenido.
Normalmente contienen componentes, interfaces y relaciones entre ellos. Y como todos los diagramas, también puede contener paquetes utilizados para agrupar elementos del modelo.
Figura #21 Diagrama de Componentes
47
4.4. Conclusiones del capítulo
En este capítulo se presentó el diagrama de despliegue el cual servirá de apoyo para la implantación del sistema, ya que representa los nodos físicos sobre los que funciona la aplicación y los diagrama de componentes, donde quedan reflejadas las clases del diseño en ficheros reales con sus respectivas dependencias.
48
CAPITULO 5: ESTUDIO DE LA FACTIBILIDAD
5.1. Introducción
Para la realización de un proyecto es de vital importancia el análisis del costo y los beneficios que el mismo reportará. Como resultado de este análisis se obtiene el costo, el tiempo de desarrollo en meses y la cantidad de personas que se necesitan para desarrollar la aplicación. Por tanto, en este capítulo se describe la estimación de costos del sistema propuesto y sus beneficios.
5.2. Planificación
5.2.1. Método de Estimación por Puntos de Casos de Uso
La estimación mediante el análisis de Puntos de Casos de Uso es un método de estimación del tiempo de desarrollo de un proyecto, mediante la asignación de "pesos" a un cierto número de factores que lo afectan, para finalmente, contabilizar el tiempo total estimado para el proyecto a partir de esos factores.
5.2.1.1. Cálculo de Puntos de Casos de Uso sin ajustar
Los puntos de casos de uso sin ajustar se calculan a partir de la siguiente ecuación:
UUCP = UAW + UUCW Donde:
UUCP: Puntos de casos de uso sin ajustar
UAW: Factor de peso de los actores sin ajustar
UUCW: Factor de peso de los casos de uso sin ajustar
49 5.2.1.2. Factor de Peso de los Actores sin ajustar (UAW):
El Factor de Peso de los Actores sin ajustar se calcula mediante un análisis de la cantidad de Actores presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los mismos se establece teniendo en cuenta en primer lugar si se trata de una persona o de otro sistema, y en segundo lugar, la forma en la que el actor interactúa con el sistema.
Tipo de
Actor
Descripción Factor de
Peso
Cantidad de Actores
Cant*Peso
Simple Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación.
(API: Application Programming Interface)
1 0 0*1
Medio Otro sistema que interactúa con el sistema a desarrollar mediante un protocolo o una interfaz basada en texto
2 1 1*2
Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica
3 1 1*3
Total 5
Tabla #8: Factor de peso de los actores sin ajustar UAW=∑Cantidad de Actores * Factor de Peso
UAW
=5
5.2.1.3. Factor de Peso de los Casos de Uso sin ajustar (UUCW)
El Factor de Peso de los Casos de Uso sin ajustar se calcula mediante un análisis de la cantidad de Casos de Uso presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Casos de Uso se establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo,
50 donde una transacción se entiende como una secuencia de actividades atómicas, es decir, se efectúa la secuencia de actividades completa, o no se efectúa ninguna de las actividades de la secuencia.
Tipo de Caso de Uso
Descripción Factor de
Peso
Cantidad de
Casos de Uso
Cant*Peso
Simple El Caso de Uso contiene de 1 a 3 transacciones
5 5 5*5
Medio El Caso de Uso contiene de 4 a 7 transacciones
10 0 0*10
Complejo El Caso de Uso contiene más de 8 transacciones
15 0 0*15
Total 25
Tabla #9: Factor de peso de los casos de uso sin ajustar UUCW=∑ Cantidad de CU * Factor de Peso
UUCW
= 25
Finalmente el cálculo de los puntos de casos de uso sin ajustar queda:
UUCP
= UAW + UUCW
UUCP
=5+25
UUCP=30
5.2.1.4. Cálculo de Puntos de Casos de Uso ajustados
Una vez que se tienen los Puntos de Casos de Uso sin ajustar, se debe ajustar éste valor mediante la siguiente ecuación:
UCP = UUCP * TCF * EF Donde:
51 UCP: Puntos de casos de uso ajustados
UUCP: Puntos de casos de uso sin ajustar
TCF: Factor de complejidad técnica
EF: Factor de ambiente
5.2.1.5. Factor de Complejidad Técnica (TCF)
Factor de Complejidad Técnica se calcula mediante la cuantificación de un conjunto de factores que determinan la complejidad técnica del sistema. Cada uno de los factores se cuantifica con un valor de 0 a 5, donde 0 significa un aporte irrelevante y 5 un aporte muy importante.
Factor Descripción Peso Valor Pesoi * Valori
T1 Sistema distribuido 2 2 2*2
T2 Tiempo de respuesta 1 4 1*4
T3 Eficiencia del usuario final 1 4 1*4
T4 Procesamiento interno complejo 1 3 1*3
T5 El código debe ser reutilizable 1 4 1*4
T6 Facilidad de instalación 0.5 5 0.5*5
T7 Facilidad de uso 0.5 5 0.5*5
T8 Portabilidad 2 5 2*5
T9 Facilidad de cambio 1 3 1*3
T10 Concurrencia 1 3 1*3
52
T11 Incluye objetivos especiales de seguridad 1 3 1*3
T12 Provee acceso directo a terceras partes 1 1 1*1
T13 Se requieren facilidades especiales de entrenamiento a los usuarios.
1 1 1*1
Total 45
Tabla #10: Factor de complejidad técnica TCF= 0.6+0.01*∑ (Pesoi * Valori)
TCF
= 0.6+0.01*45 TCF= 1.05
5.2.1.6. Factor de ambiente (EF)
El factor de ambiente está relacionado con las habilidades y entrenamiento del grupo de desarrollo que realiza el sistema. Cada factor se cuantifica con un valor de 0 a 5 al igual que en el Factor de Complejidad Técnica.
Factor Descripción Peso Valor Pesoi * Valori
E1 Familiaridad con el modelo de proyecto utilizado 1.5 1 1.5*1
E2 Experiencia en la aplicación 0.5 1 0.5*1
E3 Experiencia en orientación a objetos 1 4 1*4
E4 Capacidad del analista líder 0.5 3 0.5*3
E5 Motivación 1 5 1*5
E6 Estabilidad de los requerimientos 2 3 2*3
53
E7 Personal part-time -1 3 -1*3
E8 Dificultad del lenguaje de programación -1 3 -1*3
Total 12.5
Tabla #11: Factor de ambiente EF= 1.4 - 0.03 * ∑ (Pesoi * Valori)
EF
= 1.4 - 0.03 * 12.5
EF= 1.025
Finalmente el cálculo de los puntos de casos de uso ajustados queda:
UCP = UUCP * TCF * EF
UCP
= 30*1.05*1.025
UCP= 32.288
5.2.1.7. Estimación del esfuerzo a través de los puntos de casos de uso El esfuerzo en horas-hombre viene dado por:
E = UCP * CF
Donde:
E: Esfuerzo estimado en horas-hombre
UCP: Puntos de Casos de Uso ajustados
CF: Factor de conversión
54
5.3. Factor de conversión (CF)
Para obtener el factor de conversión se cuentan cuantos valores de los que afectan el factor ambiente (E1...E6) están por debajo de la media (3), y los que están por arriba de la media para los restantes (E7, E8).
Si el total es 2 o menos se utiliza el factor de conversión 20 Horas-Hombre / Punto de casos de uso.
Si el total es 3 o 4 se utiliza el factor de conversión 28 Horas-Hombre / Punto de casos de uso.
Si el total es mayor o igual que 5 se recomienda efectuar cambios en el proyecto ya que se considera que el riesgo de fracaso del mismo es demasiado alto.
Total
EF = Cant EF < 3 (entre E1 –E6) + Cant EF > 3 (entre E7, E8) Total
EF = 2+0 Entonces si Total
EF = 2:
CF= 20 Horas-Hombre / Punto de casos de uso
Finalmente el esfuerzo en Horas-Hombre queda:
E = UCP * CF
E = 32.288* 20 Horas-Hombre E = 645.76 Horas-Hombre
55 5.3.1. Calcular esfuerzo de todo el proyecto
Actividad Porcentaje Horas-Hombre
Análisis 10% 161.44 Horas-Hombre
Diseño 20% 322.88 Horas-Hombre
Implementación 40% 645.76 horas-hombre
Prueba 15% 242.16 Horas-Hombre
Sobrecarga 15% 242.16 Horas-Hombre
Total 100% 1614.4 Horas-Hombre
Tabla #12: Esfuerzo del proyecto
ET = 1614.4 Horas-Hombre y se estima que cada mes tiene como promedio 240 horas laborables eso daría un ET = 6.73 Mes-Hombre.
Esto quiere decir que 1 persona puede realizar el problema analizado en 6 meses aproximadamente.
Costo del Proyecto
.
Se asume como salario promedio mensual $100.00
CH: Cantidad de hombresCHM: Costo por hombres - mes
Tiempo: Tiempo total del proyecto
CH = 2 hombres
CHM
= 2 * Salario Promedio
CHM
= 200.00 $/mes
56 Costo
= CHM * E
T/ CH
Costo
= 200.00 * 6.73 / 2
Costo= $ 673
Tiempo
= E
T/ CH
Tiempo= 6.73 / 2
Tiempo= 3.365
De los resultados obtenidos se interpreta que con 2 hombres trabajando en el proyecto el mismo se desarrolla en 3 meses y medio aproximadamente y su costo total se estima que sea $673.
5.4. Beneficios tangibles e intangibles
El sistema para la configuración de una pizarra privada telefónica (PBX) es un producto con fines comerciales, su principal objetivo es distribuir este software primeramente por Cuba y en un futuro vendérselo al mundo. De esta manera el país lograría vender su propia pizarra privada telefónica (PBX) incluyendo su software ambos desarrollados en el país.Por tanto, los beneficios que este sistema aporta son generalmente tangibles:
5.5. Análisis de costos y beneficios
Desarrollar de un producto informático en la actualidad es muy costoso; justificar entonces su desarrollo depende de los beneficios que reportarían su implantación y utilización. La aplicación que se propone está dirigida a la CUJAE y GKT.SA, para la configuración de una pizarra privada telefónica (PBX), por tanto su mayor beneficio será el de elevar la eficiencia en la configuración de dicho equipo de origen cubano.
La tecnología empleada para el desarrollo de la aplicación es en su mayoría libre, por tanto no hay que incurrir en los gastos del pago de licencias de uso.
Analizando el costo del proyecto y los numerosos beneficios que reportará, se puede concluir entonces que es factible su desarrollo.
57
5.6. Conclusiones
En este capítulo se describió el estudio de factibilidad realizado al sistema propuesto, teniendo en cuenta el costo estimado y los beneficios que reportará al ser utilizado. El método empleado fue el de Estimación por Puntos de Casos de Uso.
Dado los resultados obtenidos en la estimación realizada, podemos concluir que la aplicación propuesta reportará beneficios significativos e importantes para la configuración de una Pizarra privada telefónica (PBX) de origen cubano desarrollada en la CUJAE y financiada por la empresa GKT.SA.
58
CONCLUSIONES
En el desarrollo del presente trabajo de tesis pueden plantearse las siguientes conclusiones:
Se ha obtenido un sistema de configuración que aporta valor práctico-comercial a un equipo para el servicio de telefonía, de origen cubano, del tipo central privada o PBX, como se conoce en el mercado.
Se ha logrado un trabajo de equipo multidisciplinario, con la participación de dos importantes universidades y una empresa del Ministerio de Informática y Comunicaciones (MIC).
Se ha realizado la simulación del sistema lo que permite modelar, con una aproximación satisfactoria, el ambiente real de operación del sistema.
Por primera vez se ha adquirido experiencia entre las diferentes etapas de desarrollo de un equipo de comunicaciones moderno, estableciéndose los nexos entre el diseño electrónico o hardware propiamente y los posibles software de configuración asociados.
Las habilidades adquiridas así como las soluciones propuestas poseen aplicación en etapas más avanzadas del proyecto, en específico cuando se incorporen al mismo las funcionalidades previstas de Voz sobre IP (VoIP). Incluso, pueden aplicarse a otros productos similares a operar en la red de telecomunicaciones.
Los resultados obtenidos están en consonancia con la estrategia de soberanía tecnológica trazada por el Ministerio de Informática y Comunicaciones.