UNIVERSIDAD SALESIANA DE BOLIVIAINGENIERÍA DE SISTEMAS
PROYECTO DE GRADO
“SISTEMA DE INFORMACIÓN ADMINISTRATIVO”CASO: SAR-FAB ILLIMANI”
POSTULANTE : GONZALO JHAMIL MUJICA PACOSILLO
DOCENTE GUÍA : LIC. GLADYS FRANCISCA CHUQUIMIA MAMANI
DOCENTE REVISOR : LIC. CARMEN ROSA MOLLINEDO
LA PAZ – BOLIVIA2015
ÍNDICE DE CONTENIDOS
1. MARCO REFERENCIAL 1
1.1 INTRODUCCIÓN 11.2 ANTECEDENTES 21.2.1 ANTECEDENTES INSTITUCIONALES 21.2.2 ESTRUCTURA ORGÁNICA DE LA INSTITUCIÓN 31.2.3 ANTECEDENTES DE TRABAJOS AFINES AL PROYECTO 31.3 PLANTEAMIENTO DEL PROBLEMA 41.3.1 ANÁLISIS DEL PROBLEMA 41.3.2 PROBLEMA CENTRAL 51.3.3 PROBLEMAS ESPECÍFICOS 51.4 OBJETIVOS 61.4.1 OBJETIVO GENERAL 61.4.2 OBJETIVOS ESPECÍFICOS 61.5 JUSTIFICACIÓN 71.5.1 JUSTIFICACIÓN ACADÉMICA 71.5.2 JUSTIFICACIÓN SOCIAL 71.5.3 JUSTIFICACIÓN ECONÓMICA 71.6 ALCANCES Y APORTES 81.6.1 ALCANCES 81.6.2 APORTES 81.6.2.1 Aportes académicos 81.6.2.2 Aportes institucionales 81.6.3 METODOLOGÍAS Y TÉCNICAS 91.6.3.1 Métodos 91.6.3.2 Técnicas 9
2. MARCO TEÓRICO 10
2.1 INTRODUCCIÓN 102.2 SISTEMA 102.2.1 CONCEPTO DE SISTEMA 102.2.2 DEFINICIÓN DE SISTEMA 112.3 INFORMACIÓN 112.3.1 DEFINICIÓN DE LA INFORMACIÓN 112.3.2 CARACTERÍSTICAS DE LA INFORMACIÓN 112.4 SISTEMA DE INFORMACIÓN 122.4.1 DEFINICIÓN DE SISTEMA DE INFORMACIÓN 122.4.2 ELEMENTOS DE LOS SISTEMAS DE INFORMACIÓN 132.4.3 CLASIFICACIÓN DE LOS SISTEMAS DE INFORMACIÓN 132.4.3.1 Sistemas de información administrativos 13
2.4.3.2 Sistemas de información organizacionales 142.5 SOFTWARE 142.5.1 DEFINICIONES DE SOFTWARE 142.6 INGENIERÍA DE SOFTWARE 152.6.1 DEFINICIÓN DE INGENIERÍA DE SOFTWARE 152.6.2 ETAPAS DEL PROCESO DE INGENIERÍA DE SOFTWARE 152.6.3 METODOLOGÍAS DE DESARROLLO DE SOFTWARE 172.6.4 MODELO RUP (RATIONAL UNIFIED PROCESS) 182.7 ANÁLISIS Y DISEÑO DE SISTEMAS 202.7.1 ANÁLISIS DE SISTEMAS 202.7.1.1 Conceptos y análisis 202.7.1.2 Objetivos del análisis 212.7.2 DISEÑO DE SISTEMAS 242.7.2.1 Conceptos y principios 242.7.2.2 Etapas del diseño de sistemas 242.7.2.3 Herramientas para el diseño de sistemas 252.8 MODELO ORIENTADO A OBJETOS 262.8.1 CONCEPTOS ORIENTADOS A OBJETOS 262.8.2 LENGUAJE UNIFICADO DE MODELADO (UML) 272.8.3 Diagramas UML 282.8.3.1 Diagramas de clase 292.8.3.2 Diagramas de casos de uso 302.8.3.3 Diagramas de secuencia 312.9 BASE DE DATOS 322.9.1 DEFINICIÓN DE BASE DE DATOS 322.9.2 TIPOS DE BASE DE DATOS 332.9.3 MODELOS DE BASES DE DATOS 342.9.4 HERRAMIENTAS DE RECOLECCIÓN DE DATOS 352.9.4.1 Diccionario de datos 352.10 FASES DE IMPLEMENTACIÓN, PRUEBAS Y MANTENIMIENTO DEL SOFTWARE 352.10.1 IMPLEMENTACIÓN DEL SOFTWARE 352.10.2 WINDOWS PRESENTATION FOUNDATION (WPF) 352.10.3 LIBRERÍA MAHAPP.METRO CON WPF 362.10.4 PROGRAMACIÓN POR CAPAS 362.10.5 PRUEBAS DEL SOFTWARE 382.10.5.1 Métodos de prueba 382.10.5.2 Calidad de software 402.10.5.3 Métricas de calidad de software 402.10.5.4 El modelo McCall 422.10.5.5 Modelo de estimación de costos COCOMO 452.10.5.5.1 Modelos de estimación 452.10.5.5.2 Modelo básico 472.10.5.5.3 Modelo intermedio 472.10.5.5.4 Modelo detallado 48
2.10.6 MANTENIMIENTO DE SOFTWARE 482.10.6.1 Técnicas de mantenimiento de software 49
3. FACTIBILIDAD DEL PROYECTO 51
3.1 INTRODUCCIÓN 513.2 FACTIBILIDAD ECONÓMICA 513.2.1 DETERMINANDO BENEFICIOS DEL PROYECTO 513.2.2 DETERMINANDO COSTOS ESTIMADOS DEL PROYECTO 543.2.3 MODELO PARA EL CÁLCULO DE COSTOS COCOMO 553.3 FACTIBILIDAD TÉCNICA 553.3.1 HARDWARE Y SOFTWARE DESIGNADOS 553.3.1.1 Hardware 553.3.1.2 Software 553.4 FACTIBILIDAD OPERACIONAL 56
4. INGENIERÍA DEL PROYECTO 58
4.1 INTRODUCCIÓN 584.2 ANÁLISIS Y DISEÑO DEL SISTEMA 584.2.1 RECOPILACIÓN DE INFORMACIÓN 584.2.1.1 Entrevistas 604.2.1.2 Preguntas y cuestionarios 614.3.1.3. Solicitud del cliente 614.2.1.3 Determinación de requerimientos 614.2.2 DISEÑO DEL SISTEMA 644.2.2.1 Diagramas de contexto 644.2.2.2 Casos de uso 66
CAPÍTULO 1
1. MARCO REFERENCIAL
1.1 Introducción
Al pasar los años todos hemos sido testigos de distintos eventos adversos y no
gratos para la población como ser desastres naturales, catástrofes y accidentes
ocurridos en nuestro país y en todo el mundo; eventos en los cuales siempre ha
sobresalido la labor de algún personal de ayuda capacitado para este tipo de
emergencias.
Nuestro país no puede estar excluido de sufrir alguno de este tipo de incidentes, más
aún y concretamente en la ciudad de La Paz ya que: “Estudios geológicos,
geotécnicos y topográficos demuestran de sobra que La Paz es una ciudad de y en
riesgo. Se caracteriza por una topografía marcada por pendientes y laderas muy
empinadas, con arrastre de agua en época de lluvia, mala calidad de suelos y áreas
reacondicionadas. Por debajo pasan 364 ríos, riachuelos y afluentes que hacen que
la ciudad sea sumamente vulnerable”, según la ex directora de Cultura Ciudadana
del municipio paceño Patricia Grossman.1
Es por eso que existe la Institución militar llamada Grupo de Búsqueda y Rescate
SAR2-FAB “ILLIMANI” perteneciente a la Fuerza Aérea Boliviana; este grupo de
voluntarios se desempeña en una labor de ayuda para casos de emergencia y
desastres que puedan ocurrir en la ciudad de La Paz.
Siendo este grupo de vital importancia para la población, conociendo también el tipo
de manejo de datos en el grupo SAR-FAB “ILLIMANI” y existiendo la necesidad de
sistematizar la información de la institución con el fin de brindar un mejor servicio a la
colectividad en casos de emergencias, surge este proyecto de grado.
El sistema de información administrativa SAR-FAB “ILLIMANI”, manejará datos
militares e institucionales de manera que facilite el manejo de información en
distintas áreas como son: información personal, sección logística y finanzas.
1 Periódico Digital PIEB (2011) Estudios ratifican que La Paz es una ciudad de riesgo. Recuperado de: http://www.pieb.com.bo/sipieb_notas.php?idn=6424
2 Acrónimo de las palabras en inglés Search and Rescue que significan Búsqueda y Rescate.
1
1.2 Antecedentes
1.2.1 Antecedentes institucionales
El Grupo SAR-FAB “ILLIMANI” nace un 12 de mayo del año 1994 conformado por un
grupo de personas aficionados al rescate y ayuda humanitaria que tiene la idea de
formar una institución militar que ofrezca ayuda a la población en búsqueda y rescate
de personas.
Es así que un 20 de mayo del mismo año se inicia el Grupo de Búsqueda y Rescate
SAR-FAB “ILLIMANI” a cargo de varios voluntarios y bajo el mando del ahora
Rescatista Comando3 Vladimir Chino, quien aún sigue en su labor de rescatista
especialista e Instructor.
Por órdenes del entonces Presidente de la República, Gral. Hugo Bánzer Suárez, se
le había otorgado un espacio territorial propio al grupo SAR dentro del cuartel de la
Fuerza Aérea ubicada en la ciudad de El Alto, por tanto este grupo pertenece a las
Fuerzas Armadas de la Nación.
Al paso de los años existe un notable crecimiento de infraestructura, así también del
personal voluntario y el equipo logístico de búsqueda y rescate financiado antes por
aportes voluntarios y convenios con otras instituciones y actualmente dependiente de
la Fuerza Aérea de la Nación.
A lo largo de la existencia del Grupo SAR-FAB “ILLIMANI” han habido distintos tipos
de operativos en los cuales se ha demostrado las habilidades de cada rescatista y
sus áreas de especialidad como son: montañismo, andinismo, supervivencia, rescate
en agua, rescate con canes, primeros auxilios, etc.; operativos realizados a nivel
local, nacional e internacional.
Es por eso que para cualquier tipo de emergencia se recurre al “plan de llamadas”
que consiste en la recopilación de datos de los rescatistas, datos personales e
institucionales y sus áreas de especialidad para que, en casos de emergencia, se
recurra al personal rescatista más preparado de acuerdo a la necesidad de la
emergencia.
3 Rescatista Comando es el puesto jerárquico militar más alto dentro de los rangos internos en el grupo SAR-FAB “ILLIMANI”
2
1.2.2 Estructura orgánica de la institución
Figura 1. Estructura organizacional del grupo SAR-FAB “ILLIMANI”Fuente: Sección instrucción Grupo SAR-FAB “ILLIMANI”
1.2.3 Antecedentes de trabajos afines al proyecto
Actualmente el Grupo SAR-FAB “ILLIMANI” no cuenta con un sistema automatizado
que maneje la información de la institución, los datos se manejan en papel y
mediante un sistema semi manual apoyado por un software de aplicación horizontal
(Microsoft Excel).
1.3 Planteamiento del problema
1.3.1 Análisis del problema
El manejo de información interno del Grupo SAR-FAB “ILLIMANI” se realiza de forma
semi manual, en ocasiones recurriendo al método manuscrito y almacenado en hojas
3
sueltas; por tanto se presentan sinfines de problemas en el procesamiento4 de la
información personal de los rescatistas y en ocasiones se llega a sufrir la pérdida de
los mismos.
Existen dos tipos de control de asistencia semanal: el primero se realiza todos los
sábados; la asistencia semanal está controlada bajo una lista. El segundo incurre en
el servicio de guardia que cada voluntario está obligado a realizar un día a la
semana. En ambos casos no existe un buen control debido al tipo de manejo de
información, lo cual provoca errores en planillas de asistencia.
Cuando surge una emergencia de cualquier tipo, se necesitan los datos personales
de los rescatistas y de manera urgente, para así ubicar al personal más capacitado
de acuerdo al tipo de emergencia, lo cual resulta dificultoso y se presentan
problemas en el plan de llamadas retardando así la acción inmediata de los
rescatistas.
En distintos operativos y de acuerdo al suceso, siempre se necesitan materiales y
recursos de salvamento los cuales están almacenados en sección logística y bajo un
inventario manuscrito, el problema en este tipo de control manual son los errores en
reportes de materiales usados y por tanto la pérdida o robo de los mismos. Asimismo
se crea un peligro constante al no tener un detalle exacto del material desgastado o
sin uso ya que en operativos de rescate en los cuales se necesite material logístico,
se puede poner en peligro la vida de los mismos rescatistas al usar equipo en malas
condiciones.
También se ha experimentado sinsabores en cuanto a la entrega de libretas de
servicio militar, provocados por la inexistencia de datos personales de los rescatistas
o la presencia de errores en los mismos; todos estos aspectos han influido para la
demora en la entrega de las libretas o el gasto insulso en repeticiones de libretas mal
hechas.
Otro problema a analizar es la falta de comunicación directa e instantánea entre las
distintas secciones dentro del Grupo SAR-FAB “ILLIMANI” como son: sección
4 Aplicación sistemática de una serie de operaciones sobre un conjunto de datos, generalmente por medio de máquinas, para explotar la información que estos datos representan
4
personal, sección instrucción, sección operaciones, sección logística y sección
finanzas ya que para cualquier actividad debe existir una completa coordinación
entre las distintas secciones, para un buen desempeño de la misión asignada en
cualquier operativo u actividad.
Finalmente, no está por demás recalcar que el Grupo SAR-FAB “ILLIMANI” no
cuenta con muchos recursos económicos, subsiste bajo un presupuesto bajo
dependiente de la Fuerza Aérea y convenios con otras instituciones lo cual causa la
falta de equipos o la desactualización de los mismos.
1.3.2 Problema central
Luego de un estudio previo y un análisis de problemas se ha diseñado el árbol de
problemas [ver ANEXO A] donde se ha podido identificar el problema principal que
es el siguiente:
“La información del personal de voluntarios y rescatistas, datos de materiales
logísticos y recursos económicos y financieros son llevados de forma semi manual, lo
cual provoca que la información no sea fiable, ineficiente e inoportuna.”
1.3.3 Problemas específicos
a.) Desorganización en el proceso de recopilación, almacenaje y
recuperación de datos de los rescatistas
No se encuentran datos e información personal de manera
oportuna provocando ineficiencia en el plan de llamadas y lentitud
en la entrega de libretas de servicio militar.
b.) Deficiente manejo y registro del control de asistencia
El manejo de información semi manual provoca registros
erróneos en reportes de asistencia semanal y asistencia al
servicio de guardia.
c.) Registro manual de inventarios y material logístico
5
La información de material logístico utilizado en una determinada
actividad es manual, lo que provoca robos, pérdida de materiales
y uso de equipo indebido.
d.) Datos financieros erróneos
Los aportes semanales y distintos pagos realizados por los
postulantes, voluntarios y rescatistas son llevados de forma
manuscrita lo que provoca reportes económicos falsos. Los
gastos realizados en operativos y actividades son realizados de
forma ambigua provocando incertidumbre y confusión.
1.4 Objetivos
1.4.1 Objetivo general
Luego de un análisis de problemas se ha elaborado un árbol de objetivos [ver
ANEXO B], lo que ha permitido determinar el objetivo general.
“Desarrollar un sistema de información administrativo que permita al usuario contar
con información oportuna y fiable de los datos personales de los rescatistas y
materiales logísticos, además de información pertinente de recursos financieros,
para así mejorar de manera eficaz la administración de información en la institución
militar SAR-FAB ILLIMANI”.
1.4.2 Objetivos específicos
Organizar adecuadamente la información personal de cada postulante,
voluntario y rescatista de manera que se pueda obtener fácilmente datos
precisos de los mismos, evitando la ineficiencia del plan de llamadas y
agilizando la entrega de libretas de servicio militar.
Desarrollar un sistema que permita el registro, control y seguimiento exacto de
la asistencia semanal de los rescatistas conforme a los aportes semanales y
elaborando planillas e informes de asistencia al servicio de guardia.
Sistematizar el proceso de recopilación, almacenaje y recuperación de los
datos logísticos e información de materiales evitando extravíos, robos y poner
en peligro la vida de los rescatistas.
6
Organizar adecuadamente la información financiera de manera que existan
reportes semanales, mensuales y anuales de ingresos y egresos para un
mejor control de los gastos internos del Grupo SAR-FAB “ILLIMANI”.
1.5 Justificación
1.5.1 Justificación académica
El sistema propuesto tiene como finalidad mejorar el manejo de información dentro
de la institución, es adecuado porque va a servir de herramienta para el personal
administrativo de manera que puedan recurrir instantáneamente a datos de los
Rescatistas y sus áreas de especialidad en casos de emergencia.
Se emplearán todos los conocimientos obtenidos en áreas de análisis y diseño de
sistemas, base de datos, programación e ingeniería de software para implementar el
sistema informático que va a contribuir en diferentes ámbitos administrativos.
1.5.2 Justificación social
El área de influencia del proyecto está delimitada para un buen funcionamiento
interno del Grupo SAR, pero éste a su vez tiene importancia social ya que se trata de
un Grupo de voluntarios que ayudan a la sociedad sean éstos del área local, nacional
o internacional, siempre ayudando en casos de desastres y emergencias, por lo tanto
el sistema beneficiará a toda la colectividad.
1.5.3 Justificación económica
En este aspecto podemos mencionar que año tras año se ha evidenciado que
existen gastos insulsos en reposición de libretas de servicio militar, ya que por la falta
de sistematización de la información y por la existencia de datos erróneos, se ha
procedido al llenado de libretas con datos erróneos y se tuvo que reponer los mismos
con recursos propios de la institución.
En el marco del proyecto, tampoco se cuenta con un equipo de última generación,
esto debido a los bajos recursos económicos del GRUPO SAR y por tanto se
implementará un sistema con un software que requiera bajos recursos de hardware.
7
1.6 Alcances y aportes
1.6.1 Alcances
El proyecto contempla el análisis, diseño e implementación de un sistema informático
que administrará: registro de datos de todo el personal rescatista, control y reportes
semanales de asistencia, registro de datos de materiales logísticos y planillas de
recursos financieros de aportes y gastos de la institución.
1.6.2 Aportes
1.6.2.1 Aportes académicos
Los aportes académicos van delimitados:
Como prototipo de un nuevo software de sistemas informáticos para
instituciones militares.
El uso del Análisis y Diseño de sistemas aplicado en la Ingeniería de Software.
La aplicación de herramientas tecnológicas e informáticas en una institución
militar.
1.6.2.2 Aportes institucionales
Los aportes institucionales se verán reflejados de la siguiente manera:
Reducción de la desorganización en datos personales.
Organización en el manejo y registro de la información de todo el personal de
rescate.
Confiabilidad en la información obtenida, del personal y los rescatistas, para
un excelente traslado de datos a libretas de servicio militar.
Manejo sistematizado del registro, control y seguimiento de la asistencia
semanal y asistencia a servicio de guardia.
Recopilación, almacenaje y recuperación de datos adecuado para una buena
ejecución e incremento en la efectividad del plan de llamadas.
Disminución de pérdidas y extravíos de materiales de la institución y gastos
vanos.
Productividad de uso con los bajos recursos computacionales de la institución.
8
1.6.3 Metodologías y técnicas
1.6.3.1 Métodos
Para el desarrollo del proyecto se utilizan las siguientes metodologías de
investigación:
Método científico
Método inductivo
Método deductivo
Para el desarrollo del proyecto se utilizan los siguientes modelos:
Modelo RUP (Rational Unified Process)5
Modelo Orientado a Objetos (UML)
Modelo de estimación de costos COCOMO
1.6.3.2 Técnicas
Para el desarrollo del proyecto se utilizan las siguientes técnicas:
Entrevistas, cuestionarios, observaciones y encuestas
Diccionario de datos
Diagramas de casos de uso
CAPÍTULO 2
2. MARCO TEÓRICO
2.1 Introducción
En el siguiente capítulo se dará a conocer los conceptos básicos, herramientas y
metodologías que se utilizarán en todo el desarrollo del trabajo de investigación y en
la aplicación del mismo. Estos conceptos tienen diferentes fuentes de investigación.5 Rational Unifed Process, en español Proceso Racional Unificado
9
2.2 Sistema
Implícitamente el término “sistema” fue conocido por Aristóteles en su famoso
enunciado “El todo es más que la suma de sus partes” y a lo largo de la historia el
movimiento de los sistemas tuvo contribuciones importantes hasta concebir toda una
teoría de sistemas. Hoy en día el término sistema es utilizado con mucha frecuencia
en diferentes ámbitos tanto técnicos, económicos, políticos y sociales.
2.2.1 Concepto de sistema
Una primera aproximación a la comprensión de lo que significa, un sistema es una
“caja negra”, donde se identifica las entradas, el proceso y las salidas.
Figura 2. Representación esquemática de un sistemaFuente: Elaboración propia
La entrada es el flujo de materia, información o energía que van del medio
ambiente al sistema y constituyen el componente impulsor con el cual
funciona el sistema
El proceso es la actividad que posibilita la transformación del sistema.
La salida es aquel flujo que va del interior del sistema hacia afuera. Este
componente se define como el fin por el cual se unen los elementos y las
relaciones del sistema.
2.2.2 Definición de sistema
Por la generalidad de este término, han sido varios autores que intentan explicar su
significado en consideración a sus características:
“Conjunto de cosas que relacionadas entre sí ordenadamente contribuyen a
determinado objeto6”.
6 Diccionario de la Real Academia de la lengua Española (DRAE)
10
“Conjunto de partes coordinadas y en interacción para alcanzar un conjunto de
objetivos7”.
“Conjunto de cosas que ordenadamente relacionadas entre sí, contribuyen a
un determinado objetivo”. (Senn J.,1992)
Por último cabe recalcar que un “sistema” puede clasificarse desde dos grandes
grupos, los sistemas naturales y los sistemas artificiales; los sistemas de información
son parte de este último.
2.3 Información
2.3.1 Definición de la información
Información es un conjunto ordenado de datos que tienen un determinado
valor o significado; es la unidad básica del conocimiento
Información son datos procesados en forma significativa, para el receptor, con
valor real y perceptible para decisiones presentes o futuras. (Davis, 1974)
2.3.2 Características de la información
La información puede caracterizarse de varias formas; ciertas clases de información
son más adecuadas que otras para un problema de decisión. Se debe verificar que
las características de la información se ajuste a la situación y al modelo de
interpretación del tomador de decisiones.
La información puede ser:
Histórica o predicativa
Anticipada o inesperada
Resumida o detallada
Actualizada o relativamente antigua
Estructurada poco o mucho
Para que un sistema pueda proporcionar información correcta, en el momento
oportuno y en la medida suficiente, se necesita, en todo momento, que la información
sea programada y controlada.
La programación y el control de la información por consiguiente, deben proporcionar
a éstas ciertas características de orden práctico, que se resumen a continuación.7 Johansen, B. O. (2001). Introducción a la Teoría General de Sistemas: Qué es un sistema (Cap. 3, p. 54). México: Grupo Noriega-Editorial Limusa S.A. de C.V.
11
Ser sintética
Ser formal
Ser fidedigna
Ser de fácil comprensión
Ser de fácil utilización
Tener una finalidad definida e identificada
Ser emitida con claridad
Ser recibida sin dificultades
2.4 Sistema de información
2.4.1 Definición de sistema de información
“Todo sistema de información (SI) se diseña a fin de satisfacer las necesidades de
información de una organización (empresa o cualquier tipo de institución pública o
privada) y está inmerso en ella. El SI ha de tomar los datos del entorno (la propia
organización así como fuentes externas) y sus resultados han de ser la información
que dicha organización necesita para su gestión y toma de decisiones8.”
2.4.2 Elementos de los sistemas de información
Los componentes más importantes de un sistema de información son los siguientes:
Financieros: Es el aspecto económico que permite la adquisición, contratación
y mantenimiento de los demás recursos que integran un sistema de
información.
Administrativos: Es la estructura orgánica de objetivos, lineamientos,
funciones, procedimientos, departamentalización, dirección y control de las
actividades; que sustenta la creación y uso de los sistemas.
Humanos: Está compuesto por dos grupos:
o El técnico: es quien posee los conocimientos especializados en el
desarrollo de sistemas, siendo estos los: Administradores, Líderes de
Proyecto, Analistas, Programadores, Operadores y Capturistas.
8 Piattini, M. G., Marcos, E., Calero, C., y Vela, B. (2007). Tecnología y diseño de bases de datos: Sistemas de información y bases de datos (Cap. 1, p. 9). México: Alfaomega Grupo Editor S. A. de C. V.
12
o El usuario: representado por las personas interesadas en el manejo de
información vía cómputo, como apoyo al mejor desempeño de sus
actividades, siendo éstos los: Encargados de sección, Comandante del
Grupo SAR, etc.
Materiales: Son aquellos elementos físicos que soportan el funcionamiento de
una sistema de información, por ejemplo; local de trabajo, instalaciones
eléctricas y aire acondicionado, medios de comunicación, mobiliario,
maquinaria, papelería, etc.
Tecnológicos: Es el conjunto de conocimientos, experiencias, metodologías y
técnicas; que orientan la creación, operación y mantenimiento de un sistema.
2.4.3 Clasificación de los sistemas de información
2.4.3.1 Sistemas de información administrativos
Estos sistemas de información manejan los datos orientados a la toma de decisiones
para resolver problemas por parte de los administradores. La información que surge,
sirve para ayudar a la toma de decisiones administrativas.
Los datos que se manejan son transacciones, del procesamiento de éstas surgirán
informes que darán idea de la situación. Se analizarán las posibles decisiones a
tomar, se estudiarán las posibles consecuencias de las diferentes acciones y se
optará por la más adecuada.
2.4.3.2 Sistemas de información organizacionales
Es la clasificación de los sistemas de información en relación a las funciones
organizacionales que utilizan su información. Entendiéndose por función a una serie
de actividades relacionadas en forma cercana.
2.5 Software
Vamos a tratar un concepto tan importante como es el software. Es importante entender este concepto antes de pasar a definir lo que es la ingeniería de software.
2.5.1 Definiciones de software
“Conjunto de programas, instrucciones y reglas informáticas que permiten
ejecutar ciertas tareas en un computadora9”.
9 RAE Real Academia Española. (2014). Diccionario de la lengua española (23.aed.). Madrid, España
13
“El software se puede definir como el conjunto de tres componentes:
o Programas (instrucciones): este componente proporciona la
funcionalidad deseada y el rendimiento cuando se ejecute
o Datos: este componente incluye los datos necesarios para manejar y
probar los programas y las estructuras requeridas para mantener y
manipular estos datos.
o Documentos: este componente describe la operación y uso del
programa.10”
Figura 3. Representación esquemática de un sistemaFuente: Elaboración propia
2.6 Ingeniería de software
Es la disciplina o área de la informática que ofrece métodos y técnicas para
desarrollar y mantener software de calidad.
Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la
computación, tales como construcción de compiladores, sistemas operativos, o
desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del
desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de
áreas (negocios, investigación científica, medicina, producción, logística, banca,
control de tráfico, meteorología, derecho, Internet, Intranet, etc.)
2.6.1 Definición de ingeniería de software
“La ingeniería de software es una disciplina de la ingeniería que comprende todos los
aspectos de la producción de software desde las etapas iniciales de la especificación
del sistema, hasta el mantenimiento de éste después que se utiliza11”.
10 Laboratorio Nacional de Calidad del Software, (2009), Ingeniería de Software Metodologías y Ciclos de Vida, España, Instituto Nacional de Tecnologías de la Comunicación.
14
2.6.2 Etapas del proceso de ingeniería de software
La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas
como las siguientes:
Análisis de requerimientos
Se extraen los requisitos del producto de software. En esta etapa la habilidad
y experiencia en la ingeniería del software es crítica para reconocer requisitos
incompletos, ambiguos o contradictorios. Usualmente el cliente/usuario tiene
una visión incompleta/inexacta de lo que necesita y es necesario ayudarle
para obtener la visión completa de los requerimientos. El contenido de
comunicación en esta etapa es muy intenso ya que el objetivo es eliminar la
ambigüedad en la medida de lo posible.
Especificación
La Especificación de Requerimientos describe el comportamiento esperado en
el software una vez desarrollado. Es la tarea de describir detalladamente el
software a ser escrito, de una forma rigurosa. Se describe el comportamiento
esperado del software y su interacción con los usuarios y/o otros sistemas.
Diseño y Arquitectura
Determinar cómo funcionará de forma general sin entrar en detalles
incorporando consideraciones de la implementación tecnológica, como el
hardware, la red, etc. Consiste en el diseño de los componentes del sistema
que dan respuesta a las funcionalidades descritas en la segunda etapa
también conocidas como las entidades de negocio. Generalmente se realiza
en base a diagramas que permitan describir las interacciones entre las
entidades y su secuenciado.
Nosotros utilizaremos diagramas de casos de uso y diagramas de secuencia.
Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de
ingeniería de software, pero no necesariamente es la que demanda mayor
11 Sommerville, I., (2005). Ingeniería del Software: Introducción a las computadoras (Cap. 1, p. 6). España: Pearson Educación, S. A.
15
trabajo y ni la más complicada. La complejidad y la duración de esta etapa
está íntimamente relacionada al o a los lenguajes de programación utilizados,
así como al diseño previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas
indicadas en la especificación del problema. Una técnica de prueba es probar
por separado cada módulo del software, y luego probarlo de forma integral,
para así llegar al objetivo. Se considera una buena práctica el que las pruebas
sean efectuadas por alguien distinto al desarrollador que la programó. En
general hay dos grandes formas de organizar un área de pruebas, la primera
es que esté compuesta por personal inexperto y que desconozca el tema de
pruebas, de esta forma se evalúa que la documentación entregada sea de
calidad, que los procesos descritos son tan claros que cualquiera puede
entenderlos y el software hace las cosas tal y como están descritas.
El segundo enfoque es tener un área de pruebas conformada por
programadores con experiencia, personas que saben sin mayores
indicaciones en qué condiciones puede fallar una aplicación y que pueden
poner atención en detalles que personal inexperto no consideraría.
Documentación
Es la realización del manual de usuario, y posiblemente un manual técnico con
el propósito de mantenimiento futuro y ampliaciones al sistema. Las tareas de
esta etapa se inician ya en la primera fase pero sólo finalizan una vez
terminadas las pruebas.
Mantenimiento
Conlleva todo lo relacionado con mantener y mejorar el software para
enfrentar errores descubiertos y nuevos requisitos. Esto puede abarcar más
tiempo incluso que el desarrollo inicial del software. Alrededor de dos tercios
de toda la ingeniería de software tiene que ver con dar mantenimiento. Una
16
pequeña parte de este trabajo consiste en arreglar errores, o bugs12. La mayor
parte consiste en extender el sistema para hacer nuevas cosas.
2.6.3 Metodologías de desarrollo de software
La ingeniería de software, con el fin de ordenar el caos que era anteriormente el
desarrollo de software, dispone de varias metodologías, paradigmas y filosofías de
desarrollo, estos los conocemos principalmente como modelos de ciclo de vida del
desarrollo de software, esto incluye el proceso que se sigue para construir, entregar y
hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el
retiro del sistema
Los modelos de desarrollo de software son una representación abstracta de una
manera en particular. Realmente no representa cómo se debe desarrollar el software,
sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las
necesidades del software en proceso de desarrollo. Hay varios modelos para perfilar
el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El
proyecto debería escoger el más apropiado para sus necesidades. En ocasiones
puede que una combinación de varios modelos sea apropiado.
Entre los distintos modelos podemos citar dos grupos:
Metodologías no ágiles
o Modelo lineal
o Modelo en cascada
o Modelo de prototipos
o Modelo evolutivo
o Modelo incremental
o Modelo espiral
o Modelo RUP
Metodologías ágiles
Extreme programing13 (XP)
12 Error o defecto en el software o hardware que hace que un programa funcione incorrectamente.
13 Extreme Programing, en español Programación Extrema
17
SCRUM
Dynamic Systems Development Method (DSDM)
2.6.4 Modelo RUP (Rational Unified Process)
RUP – Proceso Racional Unificado, es un proceso de desarrollo de software y junto
con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar
más utilizada para el análisis, implementación y documentación de sistemas
orientados a objetos.
Las características esenciales de la metodología RUP son tres: dirigida por casos de
uso, iterativos e incrementales y centrados en la arquitectura.
Caso de uso
Los casos de uso describen cómo los usuarios interactúan con el sistema a
desarrollar; donde un usuario puede ser una persona u otro sistema que utilice
las funcionalidades del sistema a desarrollar. Un caso de uso representa una
funcionalidad puntual del sistema.
Iterativo e incremental
RUP se basa en la evolución de prototipos ejecutables o versiones del
producto final que se muestran a los usuarios e inversionistas del proyecto.
Cada paso por el ciclo de vida produce una versión del producto que
incrementalmente se va refinando en las iteraciones de las diferentes fases.
Si llegado el final del ciclo de vida de RUP, el producto no cumple con los
objetivos planteados, se puede realizar un ciclo más para refinar, corregir y
agregar funcionalidades que lleven al software a cumplir con las expectativas
o cancelar el proyecto en base a los resultados obtenidos. Lo que indica que
con un enfoque iterativo e incremental, se tiene un mejor manejo de los
riesgos y un refinamiento más efectivo del producto final.
Centrado en la arquitectura
En RUP e proceso se basa en diseñar tempranamente una arquitectura base
ejecutable. La arquitectura de un sistema, es la organización o estructura de
sus partes (componentes) más relevantes dejando de lado los detalles, incluye
los aspectos estáticos y dinámicos del sistema.
18
Figura 4. Tabla de esfuerzos en actividades modelo RUPFuente: http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
2.7 Análisis y diseño de sistemas
“Dentro de las organizaciones, el análisis y diseño de sistemas se refiere al proceso
de examinar la situación de una empresa con el propósito de mejorarla con métodos
y procedimientos más adecuados14”
2.7.1 Análisis de sistemas
2.7.1.1 Conceptos y análisis
Es un conjunto o disposición de procedimientos o programas relacionados de
manera que juntos forman una sola unidad. Un conjunto de hechos, principios y
reglas clasificadas y dispuestas de manera ordenada mostrando un plan lógico en la
unión de las partes. Un método, plan o procedimiento de clasificación para hacer
algo. También es un conjunto o arreglo de elementos para realizar un objetivo
predefinido en el procesamiento de la información. Esto se lleva a cabo teniendo en
cuenta ciertos principios:
14 Senn, J. (1992). Análisis y Diseño de Sistemas: Introducción al desarrollo de sistemas de información (Cap. 1, p. 11). México: Mc-Graw Hill.
19
Debe presentarse y entenderse el dominio de la información de un problema.
Defina las funciones que debe realizar el software
Represente el comportamiento del software a consecuencia de
acontecimientos externos
Divida en forma jerárquica los modelos que representan la información,
funciones y comportamiento.
El proceso debe partir desde la información esencial hasta el detalle de la
implementación.
La función del análisis puede ser, dar soporte a las actividades de un negocio, o
desarrollar un producto que pueda venderse para generar beneficios. Para
conseguir este objetivo, un sistema basado en computadoras hace uso de seis
elementos fundamentales:
Software, son programas de computadora, con estructuras de datos y su
documentación hacen efectiva la logística, metodología o controles de
requerimientos del programa.
Hardware, dispositivos electrónicos y electromecánicos, que proporcionan
capacidad de cálculos y funciones rápidas, exactas y efectivas (computadoras,
sensores, maquinarias, bombas, lectores, etc.), que proporcionan una función
externa dentro de los sistemas.
Personal, son los operadores o usuarios directos de las herramientas del
Sistema (en algunos casos los RRHH de la institución).
Base de datos, una gran colección de informaciones organizadas y enlazadas
al sistema a las que se accede por medio del software.
Documentación, son los manuales, formularios, y otra información descriptiva
que detalla o da instrucciones sobre el empleo y operación del programa.
Procedimientos, o pasos que definen el uso específico de cada uno de los
elementos o componentes del sistema y las reglas de su manejo y
mantenimiento.
20
2.7.1.2 Objetivos del análisis
Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en
mente:
Identificación de necesidades
Es el primer paso del análisis del sistema, en este proceso el analista se reúne
con el(los) cliente(es) y/o usuario(os), e identifican las metas globales, se
analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre
la planificación temporal y presupuestal, líneas de mercadeo y otros puntos
que puedan ayudar a la identificación y desarrollo del proyecto.
Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y lo
dividen en cinco partes:
Reconocimiento del problema
Evaluación y síntesis
Modelado
Especificación
Revisión
Estudio de viabilidad
Muchas veces cuando se emprende el desarrollo de un proyecto de sistemas
los recursos y el tiempo no son realistas para su materialización sin tener
pérdidas económicas y frustración profesional. La viabilidad y el análisis de
riesgos están relacionados de muchas maneras, si el riesgo del proyecto es
alto, la viabilidad de producir software de calidad se reduce, sin embargo se
deben tomar en cuenta tres áreas principales de interés:
o Viabilidad económica
Una evaluación de los costos de desarrollo, comparados con los
ingresos netos o beneficios obtenidos del producto o sistema
desarrollado.
o Viabilidad técnica
Un estudio de funciones, rendimiento y restricciones que puedan
afectar la realización de un sistema aceptable.
o Viabilidad legal
21
Es determinar cualquier posibilidad de infracción, violación o
responsabilidad legal en que se podría incurrir al desarrollar el sistema.
Análisis económico y técnico
El análisis económico incluye lo que llamamos, el análisis de costos-
beneficios, significa una valoración de la inversión económica comparado con
los beneficios que se obtendrán en la comercialización y utilidad del producto
o sistema.
Muchas veces en el desarrollo de sistemas de computación, éstos son
intangibles y resulta un poco dificultoso evaluarlos; esto varía de acuerdo a las
características del sistema. El análisis de costos-beneficios es una fase muy
importante y de ella depende la posibilidad de desarrollo del proyecto.
En el análisis técnico, el analista evalúa los principios técnicos del sistema y al
mismo tiempo recoge información adicional sobre el rendimiento, fiabilidad,
características de mantenimiento y productividad.
Los resultados obtenidos del análisis técnico son la base para determinar
sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione,
no tenga el rendimiento deseado, o si las piezas no encajan perfectamente
unas con otras.
Modelado de la arquitectura del sistema
Cuando queremos dar a entender mejor lo que vamos a construir en el caso
de edificios, herramientas, aviones, máquinas, se crea un modelo idéntico,
pero en menor escala (más pequeño).
Sin embargo cuando aquello que construiremos es un software, nuestro
modelo debe tomar una forma diferente, se deben representar todas las
funciones y sub funciones de un sistema.
Los modelos se concentran en lo que debe hacer el sistema no en cómo lo
hace, éstos modelos pueden incluir notación gráfica, información y
comportamiento del sistema.
22
Todos los Sistemas basados en computadoras pueden modelarse como
transformación de la información empleando una arquitectura del tipo entrada
y salida.
Especificaciones del sistema
Es un documento que sirve como fundamento para la ingeniería hardware,
software, bases de datos, e ingeniería humana. Describe la función y
rendimiento de un sistema basado en computadoras y las dificultades que
estarán presentes durante su desarrollo. Las especificaciones de los requisitos
del software se producen en la terminación de la tarea del análisis.
En Conclusión un proyecto de desarrollo de un sistema de información comprende
varios componentes o pasos llevados a cabo durante la etapa del análisis, el cual
ayuda a traducir las necesidades del cliente en un modelo de sistema que utiliza uno
más de los componentes: software, hardware, personas, base de datos,
documentación y procedimientos.
2.7.2 Diseño de sistemas
2.7.2.1 Conceptos y principios
El diseño de sistemas define el proceso de aplicar ciertas técnicas y principios con el
propósito de especificar un dispositivo, un proceso o un sistema, con suficientes
detalles como para permitir su interpretación y realización física.
2.7.2.2 Etapas del diseño de sistemas
La etapa del diseño de sistemas encierra cuatro fases:
Diseño de los datos
Trasforma el modelo de dominio de la información, creado durante el análisis,
en las estructuras de datos necesarios para implementar el Software.
Diseño arquitectónico
Define la relación entre cada uno de los elementos estructurales del programa.
Diseño de la interfaz
Describe cómo se comunica el software consigo mismo, con los sistemas que
operan junto con él y con los operadores y usuarios que lo emplean.
23
Diseño de los procedimientos
Transforma elementos estructurales de la arquitectura del programa. La
importancia del diseño del software se puede definir en una sola palabra
Calidad; dentro del diseño es donde se fomenta la calidad del proyecto. El
diseño es la única manera de materializar con precisión los requerimientos del
cliente.
Diseño de la salida
En este caso salida se refiere a los resultados e informaciones generadas por
el sistema. Para la mayoría de los usuarios la salida es la única razón para el
desarrollo de un sistema y la base de evaluación de su utilidad. Sin embargo
cuando se realiza un sistema, como analista se debe realizar lo siguiente:
Determine qué información presentar. Decidir si la información será
presentada en forma visual, verbal o impresa y seleccionar el medio de
salida.
Disponga la presentación de la información en un formato aceptable.
Decida cómo distribuir la salida entre los posibles destinatarios.
2.7.2.3 Herramientas para el diseño de sistemas
Las herramientas para el diseño de sistemas nos apoyan en el proceso de
formulación de las características que el sistema debe tener para satisfacer los
requerimientos detectados durante las actividades del análisis.
Herramientas de especificación
Apoyan el proceso de formulación de las características que debe tener una
aplicación, tales como entradas, salidas, procesamiento y especificaciones de
control. Muchas incluyen herramientas para crear especificaciones de datos.
Herramientas para presentación
Se utilizan para describir la posición de los datos, mensajes y encabezados
sobre las pantallas de las terminales, reportes y otros medios de entrada y
salida.
Herramientas para el desarrollo de sistemas
Estas herramientas nos ayudan como analistas a trasladar diseños en
aplicaciones funcionales.
24
Herramientas para ingeniería de software
Apoyan en el proceso de formular diseños de software, incluyendo
procedimientos y controles, así como la documentación correspondiente.
Generadores de códigos
Producen el código fuente y las aplicaciones a partir de especificaciones
funcionales bien articuladas.
Herramientas para pruebas
Apoyan la fase de la evaluación de un sistema o de partes del mismo contra
las especificaciones. Incluyen facilidades para examinar la correcta operación
del sistema así como el grado de perfección alcanzado en comparación con
las expectativas.
2.8 Modelo Orientado a Objetos
2.8.1 Conceptos orientados a objetos
“Debido a que el análisis y diseño orientado a objetos está fuertemente relacionado
con la programación orientada a objetos debemos explorar brevemente el contexto
de P.O.O15”.
Son seis las ideas básicas que caracterizan a la programación orientada a objetos:
Objetos
“Un objeto es una representación en computadora de alguna cosa o evento
del mundo real”.
Clases
“Una clase es una categoría de objetos similares. Los objetos se agrupan en
clases”.
Mensajes
Se refiere al proceso de enviado de información, de un objeto a otro
Encapsulación
15 Piattini, M. G., Marcos, E., Calero, C., y Vela, B. (2007). Tecnología y diseño de bases de datos: Análisis y Diseño de Sistemas Orientado a Objetos (Cap. 22, p. 860). México: Alfaomega Grupo Editor S. A. de C. V.
25
Esta característica es la que denota la capacidad del objeto de responder a
peticiones a través de sus métodos sin la necesidad de exponer los medios
utilizados para llegar a brindar estos resultados.
Herencia
Es la característica por la cual los objetos para su creación se basan en una
clase de base, heredando todas sus propiedades, métodos y eventos; los
cuales a su vez pueden o no ser implementados y/o modificados.
Polimorfismo
El término de polimorfismo define la capacidad de que más de un objeto
pueda crearse usando la misma clase de base para lograr dos conceptos de
objetos diferentes.
2.8.2 Lenguaje Unificado de Modelado (UML)
UML, por sus siglas en inglés, Unified Modeling Language; es el lenguaje de
modelado de sistemas de software más conocido y utilizado en la actualidad; está
respaldado por el OMG16. Es un lenguaje gráfico para visualizar, especificar, construir
y documentar un sistema. UML ofrece un estándar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocio y funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y componentes
reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o
para describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas
para dar soporte a una metodología de desarrollo de software, tal como el Proceso
16 Del acrónimo Object Management Group, es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos
26
Unificado Racional o RUP17, pero no especifica en sí mismo qué metodología o
proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad
de una utilización en un requerimiento. Mientras que, programación estructurada, es
una forma de programar como lo es la orientación a objetos, sin embargo, la
programación orientada a objetos viene siendo un complemento perfecto de UML,
pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos
de las entidades representadas.
2.8.3 Diagramas UML
En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera
concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la
siguiente figura:
Figura 5. Jerarquía de los diagramas UML 2.0Fuente: Recuperado de: http://es.wikipedia.org/wiki/UML
17 Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
27
Diagramas de estructura
Enfatizan en los elementos que deben existir en el sistema modelado:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagramas de comportamiento
Enfatizan en lo que debe suceder en el sistema modelado:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados
Diagramas de interacción
Son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo
de control y de datos entre los elementos del sistema modelado:
Diagrama de secuencia
Diagrama de comunicación, que es una versión simplificada del
Diagrama de colaboración (UML 1.x)
Diagrama de tiempos (UML 2.0)
Diagrama global de interacciones o Diagrama de vista de interacción
(UML 2.0)
2.8.3.1 Diagramas de clase
Es un tipo de diagrama estático que describe la estructura de un sistema mostrando
sus clases, orientados a objetos y sus interrelaciones (incluyendo herencia,
agregación, asociación, etc.). Los diagramas de clase son el pilar básico de
modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede
hacer (análisis), como para mostrar cómo puede ser construido (diseño).
NOTACION.
Cada clase se representa en un rectángulo con tres compartimientos:
28
Nombre de la Clase
Atributo 1
Atributo 2
.................
Operacion1( )
Operacion2( )
.................
Figura 6. Notación de una claseFuente: Elaboración propia
Nombre de la clase
Atributos de la clase
Métodos u operaciones de la clase
Atributos:
Los atributos de una clase no deberían ser manipulables directamente por el resto de
objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son:
Privado (-): es el más fuerte. Esta parte es totalmente invisible (excepto para
clases friends en terminología C++).
Protegido (#): Los atributos/operaciones protegidos están visibles para las
clases friends y para las clases derivadas de la original.
Público (+): Los atributos/operaciones públicos son visibles a otras clases
(cuando se trata de atributos se está transgrediendo el principio de
encapsulación).
Métodos:
Los métodos u operaciones de una clase son la forma en como ésta interactúa con
su entorno, éstos pueden tener las características:
Privado (-): Indica que el método sólo será accesible desde dentro de la clase
(sólo otros métodos de la clase lo pueden acceder).
29
Protegido (#): Indica que el método no será accesible desde fuera de la clase,
pero si podrá ser accesado por métodos de la clase además de métodos de
las subclases que se deriven (ver herencia).
Público (+): Indica que el método será visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.
2.8.3.2 Diagramas de casos de uso
Las tres relaciones principales entre los casos de uso son soportadas por el estándar
UML, el cual describe notación gráfica para esas relaciones:
Inclusión
Es una forma de interacción o creación, un caso de uso dado puede "incluir"
otro caso de uso. El primer caso de uso a menudo depende del resultado del
caso de uso incluido. Esto es útil para extraer comportamientos
verdaderamente comunes desde múltiples casos de uso a una descripción
individual (si el actor realiza el caso de uso base tendrá que realizar también el
caso de uso incluido), desde el caso de uso.
Extensión
Es otra forma de interacción, un caso de uso dado (la extensión)
puede extender a otro. Esta relación indica que el comportamiento del caso de
la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre
debe tener extensión o inclusión. El caso de uso extensión puede ser
insertado en el caso de uso extendido bajo ciertas condiciones. La notación,
es una flecha de punta abierta con línea discontinua, desde el caso de uso
extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser
útil para lidiar con casos especiales, o para acomodar nuevos requisitos
durante el mantenimiento del sistema y su extensión.
Generalización
La Generalización es la actividad de identificar elementos en común entre
conceptos y definir las relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de construir clasificaciones
30
entre conceptos que entonces se representan en jerarquías de clases. Las
subclases conceptuales son conformes con las superclases conceptuales en
cuanto a la intención y extensión."
2.8.3.3 Diagramas de secuencia
Un diagrama de secuencia es una representación de las interacciones que muestran
los objetos entre sí a lo largo de su vida en el tiempo, estas interacciones son
llamados mensajes y gráficamente están representadas como flechas desde la línea
de vida origen hasta la línea de vida destino.
Su función es la de mostrar qué objetos se comunican con qué otros objetos y qué
mensajes disparan esas comunicaciones, esto se debe de modelar para cada caso
de uso existente en el diseño de la aplicación.
Los diagramas de secuencia están compuestos por:
Línea de vida
Es una representación de un participante individual, esta línea por lo general
se representan con una línea punteada que contiene a su inicio un rectángulo
con el nombre del objeto.
Los que interactúan pueden ser de diferentes y cada uno de ellos tendrá una
línea de vida mientras dure su interacción dentro de la funcionalidad del caso
de uso representado.
Mensajes
Los mensajes es aquello que se intercambian los objetos en la Línea de Vida,
su representación gráfica es una flecha; los mensajes pueden ser de
diferentes formas, donde:
o Mensajes síncronos: se representan con una flecha de punta oscura.
o Mensajes asíncronos: se representan con una flecha en línea, los
mensajes de retornos asíncronos son denotados por una línea punteada.
Fragmentos
31
Los fragmentos son aquellas secciones que cumplen determinada
funcionalidad en un diagrama de secuencia y es necesario tener controlado a
través de mecanismos que permiten agregar un grado de lógicas de
procedimientos a los diagramas.
2.9 Base de datos
2.9.1 Definición de base de datos
“Colección o depósito de datos integrados, almacenados en soporte secundario (no
volátil) y con redundancia controlada. Los datos, que han de ser compartidos por
diferentes usuarios y aplicaciones, deben mantenerse independientes de ellos, y su
definición (estructura de la base de datos) única y almacenada junto con los datos,
se ha de apoyar en un modelo de datos, el cual ha de permitir captar las
interrelaciones y restricciones existentes en el mundo real. Los procedimientos de
actualización y recuperación, comunes y bien determinados facilitarán la seguridad
del conjunto de los datos18“.
2.9.2 Tipos de base de datos
Las bases de datos pueden clasificarse de diversa forma de acuerdo al contexto que
maneja y a la diversidad de la misma. Vamos a mencionar dos tipos de clasificación:
Según la variabilidad de los datos almacenados
Bases de datos estáticas
Éstas son bases de datos de sólo lectura, utilizadas primordialmente
para almacenar datos históricos que posteriormente se pueden utilizar
para estudiar el comportamiento de un conjunto de datos a través del
tiempo, realizar proyecciones y tomar decisiones.
Base de datos dinámicas
Éstas son bases de datos donde la información almacenada se
modifica con el tiempo, permitiendo operaciones como actualización,
borrado y adición de datos, además de las operaciones fundamentales
18 Piattini, M. G., Marcos, E., Calero, C., y Vela, B. (2007). Tecnología y diseño de bases de datos: Sistemas de información y bases de datos (Cap. 1, p. 26). México: Alfaomega Grupo Editor S. A. de C. V.
32
de consulta. Un ejemplo de esto puede ser la base de datos utilizada en
un sistema de información de una tienda de abarrotes, una farmacia, un
videoclub.
Según el contenido
Bases de datos bibliográficas
Solo contienen un representante de la fuente primaria, que permite
localizarla. Un registro típico de una base de datos bibliográfica
contiene información sobre el autor, fecha de publicación, editorial,
título, edición, de una determinada publicación, etc.
Bases de datos de texto complejo
Almacenan las fuentes primarias, como por ejemplo, todo el contenido
de todas las ediciones de una colección de revistas científicas.
Directorios
Un ejemplo son las guías telefónicas en formato electrónico.
Bases de datos de información química o biológica
Son bases de datos que almacenan diferentes tipos de información
proveniente de la química, las ciencias de la vida o médicas. Se pueden
considerar en varios subtipos:
Las que almacenan secuencias de nucleótidos o proteínas.
Las bases de datos de rutas metabólicas.
Bases de datos de estructura, comprende los registros de datos
experimentales.
Bases de datos clínicas.
Bases de datos bibliográficas (biológicas, químicas, médicas y
de otros campos.
2.9.3 Modelos de bases de datos
Además de la clasificación por la función de las bases de datos, éstas también se
pueden clasificar de acuerdo a su modelo de administración de datos.
Un modelo de datos es básicamente una "descripción" de algo conocido como
contenedor de datos (algo en donde se guarda la información), así como de los
métodos para almacenar y recuperar información de esos contenedores.
33
Algunos modelos con frecuencia utilizados en las bases de datos:
Bases de datos jerárquicas
Bases de datos de red
Bases de datos transaccionales
Bases de datos relacionales
Bases de datos multidimensionales
Bases de datos orientadas a objetos
Bases de datos documentales
Bases de datos deductivas
2.9.4 Herramientas de recolección de datos
2.9.4.1 Diccionario de datos
“El diccionario de datos es una aplicación especializada de los tipos de diccionarios
usados como referencias en la vida diaria. El diccionario de datos es un trabajo de
referencia de datos acerca de ellos (esto es, metadatos) compilados por el analista
de sistemas para guiarse a través del análisis y diseño.
Como documento, el diccionario de datos recolecta, coordina y confirma lo que
significa un término de datos específico para diferentes personas de la organización.
Los diagramas de flujo de datos son un punto de arranque para la recolección de
entradas del diccionario de datos19”.
2.10 Fases de implementación, pruebas y mantenimiento del software
2.10.1 Implementación del software
Es la fase de programación o escritura del código, en el lenguaje de programación
elegido, una vez que se tenga completo el diagrama de diseño.
2.10.2 Windows Presentation Foundation (WPF)
Es una tecnología de Microsoft que permite el desarrollo de interfaces ricas de
usuario ofreciéndonos una potencia gráfica con la que es posible desarrollar
aplicaciones visualmente muy atractivas. Dicha interfaz se desarrolla por medio del
lenguaje declarativo XAML (eXtensible Application Markup Language)
19 Piattini, M. G., Marcos, E., Calero, C., y Vela, B. (2007). Tecnología y diseño de bases de datos: Análisis y diseño utilizando diccionario de datos (Cap. 10, p. 293). México: Alfaomega Grupo Editor S. A. de C. V.
34
separadamente de la lógica de negocio de la aplicación que podemos programarla
mediante cualquier lenguaje .NET, ya sea VB o C#.
WPF se puede utilizar para desarrollar software del siguiente tipo:
Aplicaciones independientes, al estilo tradicional de Windows Forms que se
instalan en el equipo cliente y se ejecutan desde él. Modalidad que se va a
utilizar para este proyecto.
Aplicaciones denominadas XAML Browser Applications (XBAPs). Son
aplicaciones compuestas de páginas de navegación que se compilan y se
alojan en exploradores web como Internet Explorer o Mozilla.
El uso de WPF está enfocado a aplicaciones que hagan uso desde contenido
multimedia (videos, audio, texto enriquecido) como para facilitar la creación de
aplicaciones empresariales de “tipo escritorio” o aplicaciones web enriquecidas.
WPF nos permite a los desarrolladores reutilizar el código y crear rápidamente
versiones web y de cliente de las aplicaciones.
Se recomienda usar WPF sobre Windows Forms porque Microsoft está enfocando
está tecnología como la plataforma para el desarrollo de interfaces de última
generación a los que aporta una mayor riqueza visual y nuevos componentes.
2.10.3 Librería MahApp.Metro con WPF
Desde que salió Windows 8 se empezó a dar también importancia no solamente a la
funcionalidad de una aplicación, sino al diseño de interfaces de usuario. Por lo tanto
la tecnología más adecuada para poder realizar una interfaz de usuario lo más rica
visualmente es WPF con su librería MahApp.Metro.[VER ANEXO D]
MahApp.Metro es un proyecto de Paul Jenkins que comenzó en 2011 como una
forma sencilla de llevar una interfaz de usuario de estilo Metro en aplicaciones WPF,
desde entonces ha evolucionado con contribuciones de la comunidad de
programadores.
2.10.4 Programación por capas
La programación por capas es una arquitectura de programación en el que el objetivo
primordial es la separación de la lógica de negocios de la lógica de diseño; un
35
ejemplo básico de esto consiste en separar la capa de datos de la capa de
presentación al usuario.
La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en
varios niveles y, en caso de que sobrevenga algún cambio, solo se ataca al nivel
requerido sin tener que revisar entre código mezclado. Además, permite distribuir el
trabajo de creación de una aplicación por niveles; de este modo, cada grupo de
trabajo está totalmente abstraído del resto de niveles, de forma que basta con
conocer la API que existe entre niveles.
En el diseño de sistemas informáticos actual se suelen usar las arquitecturas
multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le
confía una misión simple, lo que permite el diseño de arquitecturas escalables (que
pueden ampliarse con facilidad en caso de que las necesidades aumenten).
En este proyecto utilizaremos 4 capas:
Capa de entidades: En esta capa es donde vamos a declarar todos los
atributos de nuestras clases, esta capa es la encargada de recibir y enviar los
parámetros que serán añadidos al atributo correspondiente para el negocio,
Capa de presentación: la que ve el usuario (también se la denomina "capa
de usuario"), presenta el sistema al usuario, le comunica la información y
captura la información del usuario en un mínimo de proceso (realiza un filtrado
previo para comprobar que no hay errores de formato). También es conocida
como interfaz gráfica y debe tener la característica de ser "amigable"
(entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente
con la capa de negocio.
Capa de negocio: es donde residen los programas que se ejecutan, se
reciben las peticiones del usuario y se envían las respuestas tras el proceso.
Se denomina capa de negocio (e incluso de lógica del negocio) porque es
aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se
comunica con la capa de presentación, para recibir las solicitudes y presentar
los resultados, y con la capa de datos, para solicitar al gestor de base de
36
datos almacenar o recuperar datos de él. También se consideran aquí los
programas de aplicación.
Capa de modelo: es donde residen los datos y es la encargada de acceder a
los mismos. Está formada por uno o más gestores de bases de datos que
realizan todo el almacenamiento de datos, reciben solicitudes de
almacenamiento o recuperación de información desde la capa de negocio.
2.10.5 Pruebas del software
El programa obtenido se depura y prueba, y ya se tiene una parte del sistema
funcionando que se puede probar con los futuros usuarios, e incluso poner en
producción si se ha planificado una instalación gradual.
Una vez se tiene una versión estable se pasa al siguiente ciclo de desarrollo para
implementar el sistema con los casos de uso asignados a tal ciclo.
2.10.5.1 Métodos de prueba
Se llama prueba de software al proceso en el que se ejecuta un programa con el
objetivo de detectar fallos o errores.
Un defecto provoca un fallo, por lo tanto se llama depuración al proceso en el que se
localiza el defecto (que es la causa del fallo), se determina la forma de corregirlo, de
evalúa el efecto de la corrección y se lleva a cabo la corrección.
Existen enfoques sistemáticos que ayudan a encontrar buenos conjuntos de casos
de prueba y a determinar su grado de cobertura, son los siguientes:
Técnica de prueba de caja negra
En esta técnica se comprueban las funcionalidades sin tener en cuenta la
estructura interna.
Una prueba de Caja Negra examina algunos aspectos del modelo
fundamental del sistema sin tener mucho en cuenta la estructura lógica
interna del software.
No se utilizan frente a las pruebas de Caja Blanca, sino que constituyen
un conjunto de técnicas que tratan de detectar errores de diferentes
37
tipos. Se centran sobre el dominio de información frente a los detalles
de control. Los errores que se pretenden detectar mediante las pruebas
de caja negra son:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en las estructuras de datos.
Errores de rendimiento
Errores de inicialización o terminación.
Las ventajas que presentan este tipo de métodos de prueba son dos:
Reducen el número de casos de prueba que se deben diseñar.
Detectan clases de errores en vez de errores simples.
Algunos métodos de caja negra son:
Clases de equivalencia
Valores límite
Grafo causa-efecto
Representación de un grafo
Técnica de prueba de caja blanca
Con esta metodología se comprueban los componentes internos (módulos,
subprogramas, bucles, condiciones, etc.).
El programa que se desea probar se ve como una caja transparente y la
elección de los casos de prueba se basará en el conocimiento que se tenga
acerca de la estructura del programa dependiendo del grado de cobertura que
se desea lograr (ordenados de menos a más exhaustivos):
Cobertura de sentencias
Cobertura de decisiones
Cobertura de condiciones
Cobertura de decisiones/condiciones
Cobertura de condiciones múltiples
Cobertura de caminos
38
La técnica de prueba de caja blanca es una metodología de prueba que
se basa en las estructuras de control del diseño procedimental para
generar los casos de prueba de manera que:
Se garantice que se recorren por lo menos una vez todos los caminos
independientes de cada módulo.
Se ejecuten todas las decisiones lógicas en su parte verdadera y
en su parte falsa.
Se recorran todos los bucles.
Se utilicen las estructuras de datos internas para garantizar su
validez.
Se invierte tiempo y esfuerzo en los detalles de control debido a que:
Los errores suelen estar en situaciones fuera de las normales.
A menudo caminos que pensamos que t ienen pocas
posibi l idades de recorrerse, son recorridos regularmente.
Los errores tipográficos son aleatorios. Puede que no sean detectados
por los procesadores de la sintaxis del lenguaje particular y
estar presentes en cualquier camino lógico.
2.10.5.2 Calidad de software
Es la concordancia con los requisitos funcionales y de rendimiento explícitamente
establecidos con los estándares de desarrollo explícitamente documentados y con
las características implícitas que se espera de todo software desarrollado
profesionalmente” (Pressman, R. S., 1992).
Uno de los problemas que se afrontan actualmente en la esfera de la computación es
la calidad del software. Desde la década del 70, este tema ha sido
motivo de preocupación para especialistas, ingenieros, investigadores y
comercializadores de software, los cuales han realizado gran cantidad de
investigaciones al respecto con dos objetivos fundamentales:
¿Cómo obtener un software con calidad?
¿Cómo evaluar la calidad del software?
39
Ambas interrogantes conllevan amplias respuestas, pero están estrechamente
ligadas con el concepto de la calidad del software.
La calidad está de moda, en todos los aspectos, pero especialmente en el desarrollo
de software. El interés por la calidad crece de forma continua a medida
que los clientes se vuelven más selectivos y comienzan a rechazar los
productos poco confiables o que realmente no dan respuesta a sus necesidades.
2.10.5.3 Métricas de calidad de software
Muchos investigadores han intentado desarrollar una sola métrica que
proporcione una medida completa de la complejidad del software. Aunque se
han propuesto docenas de métricas o medidas, cada una de éstas tiene un
punto de vista diferente; y por otro lado, aunque bien se sabe que existe la
necesidad de medir y controlar la complejidad del software, es difícil de obtener
un solo valor de estas métricas de calidad. Aun así debería ser posible
desarrollar medidas de diferentes atributos internos del programa.
Aunque todos estos obstáculos son motivo de preocupación, no son
motivo de desprecio hacia las métricas. Es por eso que se dice que la
medición es esencial, si es que se desea realmente conseguir la calidad en
software.
Existen distintos tipos de métricas para poder evaluar, mejorar y clasificar
al software final en donde serán manejadas dependiendo del entorno de
desarrollo del software al cual pretendan orientarse:
Clasificación de métricas de software
La clasificación de una métrica de software refleja o describe la conducta
del software. Todas las clasificaciones de métricas fortalecen la idea,
de que más de una métrica puede ser deseable para valorar la complejidad
y la calidad del software. A continuación se muestra una breve
clasificación de métricas de software:
Métricas de complejidad
Son todas las métricas de software que definen de una u otra
forma la medición de la complejidad; Tales como volumen,
40
tamaño, anidaciones, costo (estimación), agregación,
configuración, y flujo. Estas son los puntos críticos de la concepción,
viabilidad, análisis, y diseño de software.
Métricas de calidad
Son todas las métricas de software que definen de una u otra
forma la calidad del software; Tales como exactitud,
estructuración o modularidad, pruebas, mantenimiento,
reusabilidad, cohesión del módulo, acoplamiento del módulo,
etc. Estas son los puntos críticos en el diseño, codificación,
pruebas y mantenimiento.
Métricas de competencia
Son todas las métricas que intentan valorar o medir las
actividades de productividad de los programadores o
practicantes con respecto a su certeza, rapidez, eficiencia y
competencia.
Métricas de desempeño
Corresponden a las métricas que miden la conducta de módulos y
sistemas de un software, bajo la supervisión del sistema operativo o
hardware. Generalmente tienen que ver con la eficiencia de
ejecución, tiempo, almacenamiento, complejidad de algoritmos
computacionales, etc.
Métricas estilizadas
Son las métricas de experimentación y de preferencia; Por ejemplo:
estilo de código, las convenciones denominando de datos, las
limitaciones, etc. No se deben confundir con las métricas de
calidad o complejidad.
2.10.5.4 El modelo McCall
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los
cuales el usuario puede contemplar la calidad de un producto, basándose en once
41
factores de calidad organizados en torno a los tres ejes y a su vez cada factor se
desglosa en otros criterios:
Figura 7. Factores de la calidad del software de McCallFuente: Ingeniería de Software de Roger. S. Pressman
Operación del producto
Corrección
Completitud
Consistencia
Trazabilidad
Fiabilidad
Precisión
Consistencia
Tolerancia
Modularidad
Simplicidad
Exactitud
Eficiencia
Eficiencia en ejecución
42
Eficiencia en mantenimiento
Integridad
Control de accesos
Facilidad de auditoría
Seguridad
Facilidad de uso
Facilidad de operación
Facilidad de comunicación
Facilidad de aprendizaje
Formación
Revisión del producto
Facilidad de mantenimiento
Modularidad
Simplicidad
Consistencia
Concisión
Auto descripción
Facilidad de prueba
Modularidad
Simplicidad
Auto descripción
Instrumentación
Flexibilidad
Auto descripción
Capacidad de expansión
Generalidad
Modularidad
Transición del producto
Interoperabilidad
Modularidad
Compatibilidad de comunicación
43
Compatibilidad de datos
Estandarización de los datos
Portabilidad
Auto descripción
Modularidad
Independencia entre sistema y software
Independencia de hardware
Reusabilidad
Auto descripción
Generalidad
Modularidad
Independencia entre sistema y software
Independencia de hardware
2.10.5.5 Modelo de estimación de costos COCOMO
El Modelo Constructivo de Costes o COCOMO20 es un modelo matemático de base
empírica utilizado para estimación de costos de software. Incluye tres sub modelos,
cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que
avanza el proceso de desarrollo del software: básico, intermedio y detallado. Este
método Pertenece a la categoría de modelos de subestimaciones basados en
estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo
el "tamaño" del proyecto, en líneas de código principalmente.
2.10.5.5.1 Modelos de estimación
Las ecuaciones que se utilizan en los tres modelos son:
, en persona-mes
, en meses
, en personas
20 Del acrónimo en inglés COnstructive COst MOdel
44
Donde:
E es el esfuerzo requerido por el proyecto, en persona-mes
Tdev es el tiempo requerido por el proyecto, en meses
P es el número de personas requerido por el proyecto
a, b, c y d son constantes con valores definidos en una tabla, según cada
submodelo.
Kl es la cantidad de líneas de código, en miles.
m(X) Es un multiplicador que depende de 15 atributos.
A la vez, cada submodelo también se divide en modos que representan el tipo de
proyecto, y puede ser:
modo orgánico: un pequeño grupo de programadores experimentados
desarrollan software en un entorno familiar. El tamaño del software varía
desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles
(medio).
modo semilibre o semiencajado: corresponde a un esquema intermedio
entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla
de personas experimentadas y no experimentadas.
modo rígido o empotrado: el proyecto tiene fuertes restricciones, que
pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El
problema a resolver es único y es difícil basarse en la experiencia, puesto que
puede no haberla.
45
2.10.5.5.2 Modelo básico
Se utiliza para obtener una primera aproximación rápida del esfuerzo,2 y hace uso de
la siguiente tabla de constantes para calcular distintos aspectos de costes:
MODO a b c d
Orgánico 2.40 1.05 2.50 0.38
Semi - Orgnánico
3.00 1.12 2.50 0.35
Empotrado 3.60 1.20 2.50 0.32
Tabla 1. Tabla de constantes para el cálculo de distintos aspectos de costes(MODELO BÁSICO)
Fuente: Recuperado de: http://es.wikipedia.org/wiki/COCOMO
Estos valores son para las fórmulas:
Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
Costo total del proyecto (CosteM) = CosteH * Salario medio entre los
programadores y analistas.
Se puede observar que a medida que aumenta la complejidad del proyecto (modo),
las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo
del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se
obvian muchas características del entorno.
2.10.5.5.3 Modelo intermedio
Este añade al modelo básico quince modificadores opcionales para tener en cuenta
en el entorno de trabajo, incrementando así la precisión de la estimación.
Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente
surgido de aplicar los atributos que se decidan utilizar.
46
Los valores de las constantes a reemplazar en la fórmula son:
MODO a b
Orgánico 3.20 1.05
Semi - Orgánico
3.00 1.12
Empotrado 2.80 1.20
Tabla 2. Tabla de constantes para el cálculo de distintos aspectos de costes(MODELO INTERMEDIO)
Fuente: Recuperado de: http://es.wikipedia.org/wiki/COCOMO
Se puede observar que los exponentes son los mismos que los del modelo básico,
confirmando el papel que representa el tamaño; mientras que los coeficientes de los
modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del
semi libre con respecto al efecto multiplicador de los atributos de coste.
2.10.5.5.4 Modelo detallado
Presenta principalmente dos mejoras respecto al anterior:
Los factores correspondientes a los atributos son sensibles o dependientes de la
fase sobre la que se realizan las estimaciones. Aspectos tales como la
experiencia en la aplicación, utilización de herramientas de software, etc., tienen
mayor influencia en unas fases que en otras, y además van variando de una
etapa a otra.
Establece una jerarquía de tres niveles de productos, de forma que los aspectos que
representan gran variación a bajo nivel, se consideran a nivel módulo, los que
representan pocas variaciones, a nivel de subsistema; y los restantes son
considerados a nivel sistema.
2.10.6 Mantenimiento de software
Es una de las actividades más comunes en la ingeniería de software y es el proceso
de mejora y optimización del software después de su entrega al usuario final (es
47
decir; revisión del programa), así como también corrección y prevención de los
defectos.
El mantenimiento de software es también una de las fases en el ciclo de vida de
desarrollo de sistemas (SDLC21), que se aplica al desarrollo de software. La fase de
mantenimiento es la fase que viene después de la implementación del software.
2.10.6.1 Técnicas de mantenimiento de software
Dentro de la ingeniería del software se proporcionan soluciones técnicas que
permiten abordar el mantenimiento de manera que su impacto en coste dentro del
ciclo de vida sea menor. Las soluciones técnicas pueden ser de tres tipos:
Ingeniería inversa
Análisis de un sistema para identificar sus componentes y las relaciones entre
ellos, así como para crear representaciones del sistema en otra forma o en un
nivel de abstracción más elevado.
Reingeniería
Modificación de un producto software, o de ciertos componentes, usando para
el análisis del sistema existente técnicas de ingeniería inversa y, para la etapa
de reconstrucción, herramientas de ingeniería directa, de tal manera que se
oriente este cambio hacia mayores niveles de facilidad en cuanto a
mantenimiento, reutilización, comprensión o evolución.
Reestructuración del software
Cambio de representación de un producto software, pero dentro del mismo
nivel de abstracción.
Estas tres soluciones técnicas se enmarcan en el ciclo de vida de la siguiente
manera:
21 Acrónimo de las palabras en inglés:“System Development Life Cycle”, Ciclo de Vida de Desarrollo de Sistemas
48
Figura 8. Relaciones entre los términos asociados con la ReingenieríaFuente: Recuperado de: http://cnx.org/content/m17431/latest/
El objetivo de estas técnicas es proporcionar métodos para reconstruir el software, ya
sea reprogramándolo, re documentándolo, rediseñándolo, o rehaciendo algunas
características del producto.
49
CAPÍTULO 3
3. FACTIBILIDAD DEL PROYECTO
3.1 Introducción
Todos los proyectos bien elaborados serían factibles si se contase con recursos
ilimitados y tiempo infinito. Desafortunadamente, la mayoría de los proyectos deben
desarrollarse dentro del presupuesto y límites de tiempo ajustados para cada uno de
ellos. Esto significa que la evaluación de la factibilidad22 del proyecto es una actividad
requerida para todos los proyectos de sistemas de información y es potencialmente
una tarea grande.
Esto requiere que se debe evaluar un amplio marco de factores. Típicamente,
algunos de estos factores serán más importantes que otros para algunos proyectos y
relativamente insignificantes para otros proyectos. Los factores de factibilidad se
representan por las siguientes categorías:
Económico
Técnico
Programática
Operacional
Legal y contractual
Político
3.2 Factibilidad económica
El propósito de la evaluación de factibilidad económica es identificar los beneficios
financieros y costos asociados con el desarrollo del Proyecto propuesto: “Sistema de
información administrativo caso SAR-FAB ILLIMANI”; la factibilidad económica es a
menudo referido al análisis de costo – beneficio.
3.2.1 Determinando beneficios del proyecto
El Proyecto propuesto proporcionará muchos beneficios para el grupo SAR y las tres
sub secciones que contemplará como ser: automatización de trabajos monótonos,
22 Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados.
50
reducción de errores, reducción de pérdidas de materiales y mejorar la eficiencia del
plan de llamadas.
En general, el beneficio estará enfocado en dos principios: beneficios tangibles e
intangibles. Los beneficios tangibles se refieren a los ítems que pueden ser medidos
en dólares o en moneda nacional con certeza.
Siendo de esta forma el sistema tendrá los siguientes beneficios tangibles:
Reducción de costos de operatividad
Reducción en gastos de reposición de libretas militares
Ahorro en costos de llamadas en la ejecución del plan de llamadas
Mejoramiento en planificación y ejecución de un operativo
CÁLCULO DE BENEFICIOS TANGIBLES
Costo x año
a. Reducción de costos
b. Reducción en gastos de
reposición
c. Ahorro en costos de llamadas
d. Mejoramiento en planificación y
ejecución de un operativo
Se reduce el costo basándose
en la adquisición de materiales
de escritorio (Hojas, fólders,
tinta, medios magnéticos y
otros).
Se reducirá a cero los gastos
en reposición de libretas de
servicio militar erróneas.
Al no tener los datos exactos de
los rescatistas, se llega a gastar
un monto en ocasiones alto en
llamadas a todo el personal.
Para mayor productividad de un
operativo y mejor
administración en gastos varios
Bs. 1500
Bs. 2500
Bs. 1440
Bs. 960
51
e. Menos pérdidas de materiales
logísticos
(implementos, alimento,
gasolina, etc.)
Al no tener una administración
adecuada se sufre de pérdidas
y robos provocados por el
mismo personal o externos.
TOTAL Bs. 6400
Tabla 3. Tabla de cálculo de beneficios tangibles Fuente: Elaboración propia
Los beneficios intangibles son aquellos ítems que no pueden ser medidos fácilmente
en dólares o en moneda nacional por falta de veracidad.
Reducción de pérdidas de material logístico
Aumento de control en la parte financiera
BENEFICIOS INTANGIBLES
a. Reducción de pérdidas de
materiales logísticos
b. Aumento de control en la parte
financiera
Habrá un mejor control de los
materiales que entran y salen
de sección logística evitando
pérdidas.
Se reducirá la mala
administración de recursos
evitando engaño y robos.
Tabla 4. Tabla de cálculo de beneficios intangiblesFuente: Elaboración propia
52
3.2.2 Determinando costos estimados del proyecto
Según el enfoque en el que se está centrado y similar a los beneficios, un sistema de
información puede tener distintos costos, siendo éstos denominados costos de
desarrollo.
COSTOS DE DESARROLLO
a. Software
b. Hardware
c. Instalación
- Análisis de sistemas y determinación de
requisitos
- Diseño de sistemas
- Desarrollo e implementación
- Licencia de software Windows 7
- Licencia de software Visual Studio
Community 201323
- Licencia de software SQL Server 2013
Advance Express Edition24
- Se cuenta con el equipo requerido
- Capacitación del personal x 4
A DETERMINAR
A DETERMINAR
A DETERMINAR
Bs. 500-1000
Bs. 0
Bs. 0
Bs. 0
Bs. 0
TOTAL A DETERMINAR
Tabla 5. Tabla de cálculo de costos de desarrolloFuente: Elaboración propia basándose en datos de proyectos mencionados.
Nota: Los datos de costos son aproximados y en proceso de verificación.
23 Microsoft desde noviembre de 2014 te brinda una Licencia gratuita de Visual Studio Community 2013 completo y con todas las herramientas necesarias para desarrollo de software.
24 La licencia de SQL Server 2014 Advance es libre en la versión Express Edition con algunas limitaciones.
53
3.2.3 Modelo para el cálculo de costos COCOMO
3.3 Factibilidad técnica
El propósito de evaluar la factibilidad técnica es conseguir la habilidad de entender la
organización para construir el sistema propuesto. Este análisis debe incluir una
evaluación del grupo de desarrollo que entiende el posible hardware y software
designado, los ambientes que operan para ser usados, así como el tamaño del
sistema y su complejidad.
3.3.1 Hardware y software designados
3.3.1.1 Hardware
Debido a los requerimientos informáticos del Grupo SAR-FAB “ILLIMANI”, la
institución cuenta con una PC en la cual se implementará el sistema propuesto; la PC
consta de las siguientes características:
DISPOSITIVOS CARACTERÍSTICAS
Tarjeta madre ASROCK (sonido, video, red)
Microprocesador INTEL CORE 2 DUO de 2.93 GHz
Memoria RAM DDRII de 2 Gb. PC 800
Disco duro SEAGATE tecnología SATA de 320 Gb.
Lector de DVD ASUS semi profesional
Monitor DELL 15”
Case DELUX
Teclado, Mouse, Parlantes Puerto PS2 marca GENIUS
Impresora HP 1600 series
Tabla 6. Tabla detalla de características de una PC del grupo SAR-FAB “ILLIMANI”Fuente: Empresa importadora de accesorios para computadoras “COMPUPARTES”
También cuenta con otras tres computadoras tipo torre de menores características
que se utilizan para el manejo de programas Excel. Por tanto no se encuentra
muchos inconvenientes en cuanto a requerimientos de hardware se refiere.
3.3.1.2 Software
En cuanto al aspecto de software, los programas y paquetes a utilizar son detallados
a continuación:
54
Nº Nombre Versión Fuente Utilidad
1 Windows 7 Service Pack 1 Microsoft Sistema Operativo
2 SQL Server Advance
Express Editon
2014 Microsoft Manejador de bases de
datos
3 Visual Studio Community 2013 Microsoft Lenguaje de programación
Tabla 7. Tabla de requerimientos de software a utilizarFuente: Elaboración propia
3.4 Factibilidad operacional
La factibilidad operacional es el proceso de evaluar el grado por el cual un sistema
propuesto resuelve problemas de la empresa.
Las preguntas formuladas para este apartado serán:
1. ¿Trabajará el sistema propuesto cuando esté terminado?
2. ¿Existen barreras importantes para la implantación del sistema?
3. ¿Existe apoyo por parte de los futuros usuarios?
4. ¿Existe apoyo por parte del Comandante del Grupo SAR?
1. ¿Trabajará el sistema propuesto cuando esté terminado?
Claro que sí, ese es el objetivo pues una vez desarrollado e implementado, el
sistema será implantado para de esta manera tener un manejo ordenado y rápido de
la información en cuanto a los procesos administrativos personales, logísticos y
financieros.
2. ¿Existen barreras importantes para la implantación del sistema?
No, ya que existe disposición de parte del personal del Grupo SAR, así de esta
manera coadyuvará al mejor manejo del sistema propuesto.
3. ¿Existe apoyo por parte de los futuros usuarios?
55
Sí, ya que todo el personal encargado de las distintas secciones necesita de manera
urgente un sistema como el propuesto para la correcta ejecución de sus actividades.
4. ¿Existe apoyo por parte del Comandante del Grupo SAR?
Sí, el Comandante del Grupo SAR es el más interesado en que se implemente este
sistema propuesto.
Por tanto, el Grupo SAR-FAB “ILLIMANI” y las distintas secciones que implica el
proyecto, cuenta con el personal adecuado para operar el sistema. El comandante y
los rescatistas tienen conocimiento del proyecto y están dispuestos a ser capacitados
para mejorar el manejo adecuado de la información sobre los datos personales,
datos logísticos y financieros del Grupo SAR-FAB “ILLIMANI”.
56
CAPÍTULO 4
4. INGENIERÍA DEL PROYECTO
4.1 Introducción
El capítulo de Ingeniería del Proyecto está orientado al análisis y diseño del proyecto
y al estudio de los diagramas de casos de uso, secuencia, colaboración, estado,
componentes y clases; vamos a utilizar el modelo espiral en el desarrollo del mismo.
4.2 Análisis y diseño del sistema
4.2.1 Recopilación de información
Observación
Se tomaron en cuenta distintos aspectos en el marco de la observación para la
posterior descripción del mismo.
Determinación de lo que se va a observar
o El proceso de registro del personal del grupo SAR, además de
consultas y modificaciones en el file de cada postulante, voluntario y
rescatista.
o El proceso de registro de materiales salientes y entrantes en caso de
operatividad o actividad.
o El recojo del aporte voluntario semanal y el proceso de registro y
guardado de datos de los mismos.
Tiempo necesario de observación
o Por ser una institución que tiene actividad solamente los días sábados,
se ha venido observando a lo largo de dos meses.
Obtención de autorización
o La autorización fue solicitada al inicio del desarrollo del proyecto con
resultados positivos.
Descripción
De acuerdo a lo observado, podemos plantear las siguientes formas de
procedimiento de acuerdo al área o sección:
Sección personal
57
o Una vez que todo el personal del grupo SAR llega, se procede al
control de asistencia semanal empezando por el personal más antiguo.
o El registro se hace en papel de forma manuscrita para luego proceder a
registrar a los voluntarios de segundo año bajo listado y aporte de un
boliviano. Finalmente se procede a registrar a los postulantes de primer
año bajo la misma modalidad.
o Semana a semana se realiza un control de faltas de todo el personal
del grupo, este proceso se lo realiza de forma manual. Si algún
personal del grupo tiene acumuladas más de 7 faltas se recurre al
llamado de atención; si algún personal tiene acumulado más de 8 faltas
se procede a realizar la baja del mismo, de manera que cambia la
información general del personal total, personal efectivo y personal
asistente.
o En caso de un llamado de emergencia y confirmación del mismo, se
procede a ejecutar el plan de llamadas recurriendo a los datos de los
rescatistas más capacitados dependiendo del caso (evento adverso);
este proceso se realiza de forma tardía debido a la falta de
actualización de los datos o por la existencia de errores en los mismos.
o Finalmente, la sección personal es la encargada de elevar informes
(partes25) semanales para enviarlos al Comando General de la Fuerza
Aérea.
Sección logística
o Esta sección maneja todos los datos referentes a materiales y equipos
con los que cuenta el grupo SAR. Si se presenta una emergencia u
operativo de rescate es cuando se requieren distintos tipos de equipos
de acuerdo a los requerimientos del caso (cuerdas, mosquetones,
cascos, cinturones, etc.). Es así que se nombra un comandante de
escena quien está encargado de cuidar y evitar el extravío de los
equipos.
25 Informes semanales del personal de la unidad en el ámbito militar
58
o Una vez que el oficial de servicio, el Mayor Cárdenas, da la orden de
salir de operativo, el encargado hace una lista de solicitud de materiales
para que el encargado de sección logística prepare el equipo necesario.
Todos los datos se apuntan en hojas y de forma manuscrita.
o Al finalizar el operativo, todo el personal rescatista vuelve a
instalaciones del grupo con todo el material utilizado que debe estas en
perfectas condiciones de operatividad para su posterior registro en
inventarios de sección.
Sección finanzas
o Esta sección coordina cada fin de semana con sección personal para
registrar y guardar datos de aportes voluntarios de todo el personal del
grupo SAR.
o También está encargada de la venta de uniformes y accesorios que los
rescatistas adquieren a lo largo del año; así mismo realiza contratos
con entidades externas de financiamiento, banca, confección y otros.
Por otra parte, esta sección se encarga de financiar gastos en materiales y gastos de
utilidad y mantenimiento de equipos y vehículos.
4.2.1.1 Entrevistas
Una entrevista para recabar información es una conversación dirigida con un
propósito específico que utiliza un formato de preguntas y respuestas. En la
entrevista se necesita obtener las opiniones de los entrevistados y su parecer acerca
del estado actual del sistema, metas organizacionales y personales y procedimientos
informales26.
Todas las entrevistas para el proceso de recopilación de información se elaboraron
luego de la observación, realizados de forma verbal y personal con el comandante
del Grupo SAR-FAB “ILLIMANI” y los rescatistas encargados de las secciones.
4.2.1.2 Preguntas y cuestionarios
Para una recopilación de información efectiva se ha realizado un cuestionario de
nueve preguntas, el cual fue impartido al comandante del Grupo SAR y a los jefes de
26 Kendall K., Kendall J. (2005), Análisis y diseño de sistemas: Análisis de los requerimientos de información (Cap. 2, p. 90). México: McGraw-Hill Latinoamericana
59
sección personal, sección logística y sección finanzas obteniendo un resultado
satisfactorio [ver ANEXO C].
4.3.1.3. Solicitud del cliente
Luego de hacer una evaluación profunda y basándonos en todo el análisis y
recopilación de información, conjuntamente el comandante del grupo SAR y los
rescatistas encargados de las secciones se tienen las solicitudes detalladas a
continuación:
El manejo del sistema y la interfaz de usuario debe ser sumamente aplicable y
de fácil utilización debido a que no todos los usuarios (rescatistas) tienen
grandes conocimientos de informática y computación.
El sistema debe resolver el principal problema de pérdida y manejo
inadecuado de información de las distintas secciones que contempla el
sistema (secciones: personal, logística, finanzas).
El sistema debe contar con una base de datos actualizada de manera
constante y todos los datos deben ser guardados en la computadora central.
El sistema debe hacer más efectivo el plan de llamadas y colaborar en el
ámbito de toma de decisiones en cuanto a la elección de los rescatistas más
capacitados para un operativo de emergencia.
4.2.1.3 Determinación de requerimientos
Vamos a enfocarnos en dos principios muy importantes:
Requisitos básicos
o ¿Cuáles son los procesos básicos?
Los procesos básicos están basados de acuerdo al flujo de información
en las 3 secciones; esto conlleva al registro, guardado y recopilación
correcta de los datos en cada sección.
o ¿Qué datos se utilizan y producen durante este proceso?
Los datos utilizados están ligados a:
Sección personal: Datos de todo el personal del Grupo SAR.
60
Sección logística: Datos de inventarios, materiales y equipos.
Sección finanzas: Datos económicos, datos de gastos y
beneficios.
o ¿Cuáles son los límites impuestos por tiempo y cantidad de trabajo?
Límites de tiempo: Debido a que la actividad se realiza solo los
días sábados y en ocasiones algún día de la semana, el limitante
de tiempo se ve cada fin de semana por la tardanza en
recopilación de la información.
Límites de cantidad de trabajo: El trabajo es arduo y tardío con el
tipo de manejo de información actual, esto se ve afectado por la
misma limitante de tiempo.
o ¿Qué controles de rendimiento se utilizan?
Aún no se realiza un control de rendimiento debido al manejo ambiguo
de la información, esta posibilidad queda nula.
Actividades
o ¿Cuál es el propósito de estas actividades?
El principal propósito es el correcto registro de datos de las tres secciones,
lo cual ayudará a agilizar todas las actividades que conllevan el proceso de
recopilación de información (plan de llamadas, registro de faltas, planillas,
etc.)
o ¿Qué es lo que se realiza?
En todos los casos, ya sea sección personal, logística o finanzas, los
procesos a realizarse son: la recolección, verificado, evaluación y
guardado de los datos.
o ¿Dónde se realizan?
Todos los procesos se lo realizan dentro del grupo SAR por tratarse de
información netamente interna. A excepción del “parte” semanal que se
debe reportar al comando y los datos de los rescatistas que recibirán la
libreta de servicio militar, todos los datos se quedan en el grupo.
o ¿Quiénes lo ejecutan?
61
Todos los procesos lo ejecutan cada encargado de sección (jefe de
sección) con la ayuda de sus colaboradores siempre bajo el mando del
comandante del grupo SAR.
o ¿Cuánto tiempo estimado consumen?
En cuanto a recolección y registro de datos junto con el aporte
voluntario y debido a que es realizado de forma manual se tarda
aproximadamente 3 a 5 a minutos por cada rescatista, voluntario o
postulante.
En cuanto a inventarios, el proceso de verificación cuando existe un
operativo es moroso debido al tipo de manejo de información. Esto
resulta perjudicial en operativos de emergencia por la rapidez en que se
debe acudir a un evento adverso.
o ¿Con que frecuencia se lo realizan?
Todas las actividades se lo realizan en general los días sábados a
excepción de algún operativo que pueda surgir en el transcurso de la
semana. Por tanto todo el proceso de manejo de información se lo
realiza sábado a sábado.
o ¿Quién utiliza la información resultante?
Toda la información resultante la utilizan el comandante del grupo SAR
y los encargados de las 3 secciones que implica el proyecto; toda la
información está relacionada también con las sub secciones que no
implica al proyecto (sección instrucción, operaciones, médicas y
transportes).
4.2.2 Diseño del sistema
4.2.2.1 Diagramas de contexto
Diagrama de contexto Sección personal
62
Figura 9. Diagrama de contexto de sección personal Grupo SAR-FAB “ILLIMANI”Fuente: Elaboración propia
Diagrama de contexto Sección logística
63
Figura 10. Diagrama de contexto de sección logística Grupo SAR-FAB “ILLIMANI”Fuente: Elaboración propia
Diagrama de contexto Sección finanzas
Figura 11. Diagrama de contexto de sección logística Grupo SAR-FAB “ILLIMANI”Fuente: Elaboración propia
64
4.2.2.2 Casos de uso
SECCIÓN PERSONAL
CASO DE USO 1: ESCENARIO GENERAL
Figura 12. Caso de uso: Escenario generalFuente: Elaboración propia
CASO DE USO 2: GESTIÓN DE DATOS DEL PERSONAL
65
Figura 13. Caso de uso: Gestión de datos del personalFuente: Elaboración propia
CASO DE USO 3: AGREGACIÓN DATOS
Figura 14. Caso de uso: Agregación de datosFuente: Elaboración propia
CASO DE USO 4: LISTADO DE DATOS
66
Figura 15. Caso de uso: Listado de datosFuente: Elaboración propia
CASO DE USO 5: MODIFICACIÓN DE DATOS
Figura 16. Caso de uso: Modificación de datosFuente: Elaboración propia
67
CASO DE USO 6: ELIMINACIÓN DE DATOS
Figura 17. Caso de uso: Eliminación de datosFuente: Elaboración propia
CASO DE USO 7: REGISTRO DE ASISTENCIA A INSTRUCCIÓN
Figura 18. Caso de uso: Registro de asistencia a instrucciónFuente: Elaboración propia
68
CASO DE USO 8: GESTIÓN DE PERMISOS
Figura 19. Caso de uso: Gestión de permisosFuente: Elaboración propia
CASO DE USO 9: GENERACIÓN DE REPORTES
Figura 19. Caso de uso: Generación de reportesFuente: Elaboración propia
69
ANEXOS
ANEXO – A
ÁRBOL DE PROBLEMAS
FALTA DE SISTEMATIZACIÓN Y CARENCIA DE INFORMACIÓN OPORTUNA Y FIABLE
CAUSAS
EFECTOS
Manejo inadecuado de la información de los postulantes,
voluntarios y rescatistas
Pérdida de datos e información personal de los postulantes,
voluntarios y rescatistas
Desorganización en el proceso de recopilación,
almacenaje y recuperación de datos de los rescatistas
Registro manual de inventarios y
materiales logísticos
Deficiente manejo y registro del control de asistencia semanal
No se encuentran datos e información personal de
manera oportuna
Lentitud en la ejecución del plan de llamadas
Registros erróneos en reportes de asistencia semanal y
asistencia al servicio de guardia.
Demora en entrega de libretas de servicio militar
Robos y pérdida de los
materiales utilizados
ANEXO – B
ÁRBOL DE OBJETIVOS
DESARROLLAR E IMPLEMENTAR UN SISTEMA DE INFORMACIÓN QUE PERMITA AL USUARIO CONTAR
CON INFORMACIÓN OPORTUNA Y FIABLE
CAUSAS
EFECTOS
Organizar adecuadamente la información personal de cada
postulante, voluntario y rescatista
Obtención instantánea, fácil y
precisa de datos
Desarrollar un sistema que permita el registro, control y seguimiento exacto de
la asistencia semanal de los rescatistas
Sistematizar el proceso de recopilación, almacenaje y recuperación de los datos logísticos e información de
materiales logísticos
Evita robos y extravíos de materiales logísticos
Planillas y reportes de asistencias
precisos y concisos
Confiabilidad en la información obtenida
Eficiencia en el proceso del plan
de llamadas
Agilización de entregas de las
libretas de servicio militar
Organizar adecuadamente la información financiera
Existen reportes económicos precisos y planillas financieras
exactas
Mejor control de gastos
ANEXO – C
CUESTIONARIO
1. ¿Existe algún medio automatizado de recolección de información en la sección a su cargo?
SI ( ) NO ( )
¿Por qué? …………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
2. ¿Respecto al manejo de información de los datos que maneja dentro su sección, se tuvo alguna vez algún tipo de problema con la recopilación de información de los mismos?
SI ( ) NO ( )
¿Por qué?
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
3. ¿Cree usted necesario que se deba implantar un sistema para el buen manejo de la información dentro del grupo SAR y sus sub secciones?
SI ( ) NO ( )
¿Por qué?
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
4. Ya sea en sección personal, logística o finanzas, ¿Existe algún aspecto donde se vea algún problema por la falta de organización de información?
SI ( ) NO ( )
¿Cuál(es) es(son)?
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
5. Los registros y el control de los datos de la sección a la que pertenece son::Inútiles a veces útiles útiles muy útiles
6. De acuerdo a su opinión, crear un sistema automatizado para el grupo SAR sería:De cierta ayuda útil muy útil indispensable
7. A su criterio, la recopilación de información para efectivizar el plan de llamadas es:Fácil y accesible difícil y complicada no me quejo necesitamos ayuda
8. ¿Usted cree que debe renovar su sistema de manejo de información dentro de la sección a la cual pertenece?Nunca de aquí a un tiempo lo más pronto posible
9. ¿De acuerdo a su criterio, estaría de acuerdo con que se le proporcione ayuda en su sección en el ámbito de actualización tecnológica para con en el manejo de información?
SI ( ) NO ( )
¿Por qué?
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
ANEXO – D
La librería MahApps.Metro se instala dentro de la aplicación Visual.NET, nos
dirigimos a Tools, NuGet Package Manager y Package Manager Console
Dentro ya de la consola escribimos: PM> Install-Package MahApps.Metro y ya
tendremos instalada la librería para comenzar a trabajar
ANEXO – E
CAPTURA DE PANTALLA: LOGIN DE USUARIO