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