Ejemplo Proyecto

UNIVERSIDAD SALESIANA DE BOLIVIA
INGENIERA DE SISTEMAS
PROYECTO DE GRADO
SISTEMA DE INFORMACIN ADMINISTRATIVO

CASO: SAR-FAB ILLIMANI
POSTULANTE
: GONZALO JHAMIL MUJICA PACOSILLO
DOCENTE GUA
: LIC. GLADYS FRANCISCA CHUQUIMIA MAMANI
DOCENTE REVISOR
: LIC. CARMEN ROSA MOLLINEDO
LA PAZ BOLIVIA
2015
NDICE DE CONTENIDOS
1. MARCO REFERENCIAL
1.1 INTRODUCCIN
1.2 ANTECEDENTES
1.2.1 ANTECEDENTES INSTITUCIONALES
1.2.2 ESTRUCTURA ORGNICA DE LA INSTITUCIN
1.2.3 ANTECEDENTES DE TRABAJOS AFINES AL PROYECTO
1.3 PLANTEAMIENTO DEL PROBLEMA
1.3.1 ANLISIS DEL PROBLEMA
1.3.2 PROBLEMA CENTRAL
1.3.3 PROBLEMAS ESPECFICOS
1.4 OBJETIVOS
1.4.1 OBJETIVO GENERAL
1.4.2 OBJETIVOS ESPECFICOS
1.5 JUSTIFICACIN
1.5.1 JUSTIFICACIN ACADMICA
1.5.2 JUSTIFICACIN SOCIAL
1.5.3 JUSTIFICACIN ECONMICA
1.6 ALCANCES Y APORTES
1.6.1 ALCANCES
1.6.2 APORTES
1.6.2.1 Aportes acadmicos
1.6.2.2 Aportes institucionales
1.6.3 METODOLOGAS Y TCNICAS
1.6.3.1 Mtodos
1.6.3.2 Tcnicas
1
2
2
3
3
4
4
5
5
6
6
6
7
7
7
7
8
8
8
8
8
9
9
9
2. MARCO TERICO
10
2.1 INTRODUCCIN
2.2 SISTEMA
2.2.1 CONCEPTO DE SISTEMA
2.2.2 DEFINICIN DE SISTEMA
2.3 INFORMACIN
2.3.1 DEFINICIN DE LA INFORMACIN
2.3.2 CARACTERSTICAS DE LA INFORMACIN
2.4 SISTEMA DE INFORMACIN
2.4.1 DEFINICIN DE SISTEMA DE INFORMACIN
2.4.2 ELEMENTOS DE LOS SISTEMAS DE INFORMACIN
2.4.3 CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN
2.4.3.1 Sistemas de informacin administrativos
2.4.3.2 Sistemas de informacin organizacionales
2.5 SOFTWARE
10
10
10
11
11
11
11
12
12
13
13
13
14
14
2.5.1 DEFINICIONES DE SOFTWARE

14
2.6 INGENIERA DE SOFTWARE
15
2.6.1 DEFINICIN DE INGENIERA DE SOFTWARE
15
2.6.2 ETAPAS DEL PROCESO DE INGENIERA DE SOFTWARE
15
2.6.3 METODOLOGAS DE DESARROLLO DE SOFTWARE
17
2.6.4 MODELO RUP (RATIONAL UNIFIED PROCESS)
18
2.7 ANLISIS Y DISEO DE SISTEMAS
20
2.7.1 ANLISIS DE SISTEMAS
20
2.7.1.1 Conceptos y anlisis
20
2.7.1.2 Objetivos del anlisis
21
2.7.2 DISEO DE SISTEMAS
24
2.7.2.1 Conceptos y principios
24
2.7.2.2 Etapas del diseo de sistemas
24
2.7.2.3 Herramientas para el diseo de sistemas
25
2.8 MODELO ORIENTADO A OBJETOS
26
2.8.1 CONCEPTOS ORIENTADOS A OBJETOS
26
2.8.2 LENGUAJE UNIFICADO DE MODELADO (UML)
27
2.8.3 Diagramas UML
28
2.8.3.1 Diagramas de clase
29
2.8.3.2 Diagramas de casos de uso
30
2.8.3.3 Diagramas de secuencia
31
2.9 BASE DE DATOS
32
2.9.1 DEFINICIN DE BASE DE DATOS
32
2.9.2 TIPOS DE BASE DE DATOS
33
2.9.3 MODELOS DE BASES DE DATOS
34
2.9.4 HERRAMIENTAS DE RECOLECCIN DE DATOS
35
2.9.4.1 Diccionario de datos
35
2.10 FASES DE IMPLEMENTACIN, PRUEBAS Y MANTENIMIENTO DEL SOFTWARE
35
2.10.1 IMPLEMENTACIN DEL SOFTWARE
35
2.10.2 WINDOWS PRESENTATION FOUNDATION (WPF)
35
2.10.3 LIBRERA MAHAPP.METRO CON WPF
36
2.10.4 PROGRAMACIN POR CAPAS
36
2.10.5 PRUEBAS DEL SOFTWARE
38
2.10.5.1 Mtodos de prueba
38
2.10.5.2 Calidad de software
40
2.10.5.3 Mtricas de calidad de software
40
2.10.5.4 El modelo McCall
42
2.10.5.5 Modelo de estimacin de costos COCOMO
45
2.10.5.5.1
Modelos de estimacin
45
2.10.5.5.2
Modelo bsico
47
2.10.5.5.3
Modelo intermedio
47
2.10.5.5.4
Modelo detallado
48
2.10.6 MANTENIMIENTO DE SOFTWARE
48
2.10.6.1 Tcnicas de mantenimiento de software
49
3. FACTIBILIDAD DEL PROYECTO
51
3.1 INTRODUCCIN
3.2 FACTIBILIDAD ECONMICA
3.2.1 DETERMINANDO BENEFICIOS DEL PROYECTO
3.2.2 DETERMINANDO COSTOS ESTIMADOS DEL PROYECTO
3.2.3 MODELO PARA EL CLCULO DE COSTOS COCOMO
3.3 FACTIBILIDAD TCNICA
3.3.1 HARDWARE Y SOFTWARE DESIGNADOS
3.3.1.1 Hardware
3.3.1.2 Software
3.4 FACTIBILIDAD OPERACIONAL
51
51
51
54
55
55
55
55
55
56
4. INGENIERA DEL PROYECTO
58
4.1 INTRODUCCIN
4.2 ANLISIS Y DISEO DEL SISTEMA
4.2.1 RECOPILACIN DE INFORMACIN
4.2.1.1 Entrevistas
4.2.1.2 Preguntas y cuestionarios
4.3.1.3. Solicitud del cliente
4.2.1.3 Determinacin de requerimientos
4.2.2 DISEO DEL SISTEMA
4.2.2.1 Diagramas de contexto
4.2.2.2 Casos de uso
58
58
58
60
61
61
61
64
64
66
CAPTULO 1
1. MARCO REFERENCIAL
1.1 Introduccin
Al pasar los aos todos hemos sido testigos de distintos eventos adversos y no
gratos para la poblacin como ser desastres naturales, catstrofes y accidentes
ocurridos en nuestro pas y en todo el mundo; eventos en los cuales siempre ha
sobresalido la labor de algn personal de ayuda capacitado para este tipo de
emergencias.
Nuestro pas no puede estar excluido de sufrir alguno de este tipo de incidentes, ms
an y concretamente en la ciudad de La Paz ya que: Estudios geolgicos,
geotcnicos y topogrficos demuestran de sobra que La Paz es una ciudad de y en
riesgo. Se caracteriza por una topografa 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 ros, riachuelos y afluentes que hacen que
la ciudad sea sumamente vulnerable, segn la ex directora de Cultura Ciudadana
del municipio paceo Patricia Grossman.1
Es por eso que existe la Institucin militar llamada Grupo de Bsqueda y Rescate
SAR2-FAB ILLIMANI perteneciente a la Fuerza Area Boliviana; este grupo de
voluntarios se desempea 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 poblacin, conociendo tambin el tipo
de manejo de datos en el grupo SAR-FAB ILLIMANI y existiendo la necesidad de
sistematizar la informacin de la institucin con el fin de brindar un mejor servicio a la
colectividad en casos de emergencias, surge este proyecto de grado.
1 Peridico 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 Acrnimo de las palabras en ingls Search and Rescue que significan Bsqueda
y Rescate.
1
El sistema de informacin administrativa SAR-FAB ILLIMANI, manejar datos

militares e institucionales de manera que facilite el manejo de informacin en
distintas reas como son: informacin personal, seccin logstica y finanzas.
1.2 Antecedentes
1.2.1 Antecedentes institucionales
El Grupo SAR-FAB ILLIMANI nace un 12 de mayo del ao 1994 conformado por un
grupo de personas aficionados al rescate y ayuda humanitaria que tiene la idea de
formar una institucin militar que ofrezca ayuda a la poblacin en bsqueda y rescate
de personas.
Es as que un 20 de mayo del mismo ao se inicia el Grupo de Bsqueda y Rescate
SAR-FAB ILLIMANI a cargo de varios voluntarios y bajo el mando del ahora
Rescatista Comando3 Vladimir Chino, quien an sigue en su labor de rescatista
especialista e Instructor.
Por rdenes del entonces Presidente de la Repblica, Gral. Hugo Bnzer Surez, se
le haba otorgado un espacio territorial propio al grupo SAR dentro del cuartel de la
Fuerza Area ubicada en la ciudad de El Alto, por tanto este grupo pertenece a las
Fuerzas Armadas de la Nacin.
Al paso de los aos existe un notable crecimiento de infraestructura, as tambin del
personal voluntario y el equipo logstico de bsqueda y rescate financiado antes por
aportes voluntarios y convenios con otras instituciones y actualmente dependiente de
la Fuerza Area de la Nacin.
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: montaismo, andinismo, supervivencia, rescate
en agua, rescate con canes, primeros auxilios, etc.; operativos realizados a nivel
local, nacional e internacional.
3 Rescatista Comando es el puesto jerrquico militar ms alto dentro de los

rangos internos en el grupo SAR-FAB ILLIMANI
2
Es por eso que para cualquier tipo de emergencia se recurre al plan de llamadas
que consiste en la recopilacin 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 ms preparado de acuerdo a la necesidad de la
emergencia.
1.2.2 Estructura orgnica de la institucin
Figura 1. Estructura organizacional del grupo SAR-FAB ILLIMANI

Fuente: Seccin instruccin 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 informacin de la institucin, los datos se manejan en papel y
mediante un sistema semi manual apoyado por un software de aplicacin horizontal
(Microsoft Excel).
1.3 Planteamiento del problema

1.3.1 Anlisis del problema
El manejo de informacin interno del Grupo SAR-FAB ILLIMANI se realiza de forma
semi manual, en ocasiones recurriendo al mtodo manuscrito y almacenado en hojas
sueltas; por tanto se presentan sinfines de problemas en el procesamiento 4 de la
informacin personal de los rescatistas y en ocasiones se llega a sufrir la prdida de
los mismos.
Existen dos tipos de control de asistencia semanal: el primero se realiza todos los
sbados; la asistencia semanal est controlada bajo una lista. El segundo incurre en
el servicio de guardia que cada voluntario est obligado a realizar un da a la
semana. En ambos casos no existe un buen control debido al tipo de manejo de
informacin, 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 ms capacitado
de acuerdo al tipo de emergencia, lo cual resulta dificultoso y se presentan
problemas en el plan de llamadas retardando as la accin inmediata de los
rescatistas.
En distintos operativos y de acuerdo al suceso, siempre se necesitan materiales y
recursos de salvamento los cuales estn almacenados en seccin logstica 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 prdida 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 logstico,
se puede poner en peligro la vida de los mismos rescatistas al usar equipo en malas
condiciones.
Tambin se ha experimentado sinsabores en cuanto a la entrega de libretas de
servicio militar, provocados por la inexistencia de datos personales de los rescatistas
4 Aplicacin sistemtica de una serie de operaciones sobre un conjunto de datos,
generalmente por medio de mquinas, para explotar la informacin que estos
datos representan
4
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 comunicacin directa e instantnea entre las
distintas secciones dentro del Grupo SAR-FAB ILLIMANI como son: seccin
personal, seccin instruccin, seccin operaciones, seccin logstica y seccin
finanzas ya que para cualquier actividad debe existir una completa coordinacin
entre las distintas secciones, para un buen desempeo de la misin asignada en
cualquier operativo u actividad.
Finalmente, no est por dems recalcar que el Grupo SAR-FAB ILLIMANI no
cuenta con muchos recursos econmicos, subsiste bajo un presupuesto bajo
dependiente de la Fuerza Area y convenios con otras instituciones lo cual causa la
falta de equipos o la desactualizacin de los mismos.
1.3.2 Problema central
Luego de un estudio previo y un anlisis de problemas se ha diseado el rbol de
problemas [ver ANEXO A] donde se ha podido identificar el problema principal que es
el siguiente:
La informacin del personal de voluntarios y rescatistas, datos de materiales
logsticos y recursos econmicos y financieros son llevados de forma semi manual, lo
cual provoca que la informacin no sea fiable, ineficiente e inoportuna.
1.3.3 Problemas especficos
a.) Desorganizacin en el proceso de recopilacin, almacenaje y
recuperacin de datos de los rescatistas
No se encuentran datos e informacin 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
informacin semi manual provoca registros
errneos en reportes de asistencia semanal y asistencia al

servicio de guardia.
c.) Registro manual de inventarios y material logstico
La informacin de material logstico utilizado en una determinada
actividad es
registrada de forma manual, lo que provoca robos, prdida de
materiales y uso de equipo indebido.
d.) Datos financieros errneos
Los aportes semanales y distintos pagos realizados por los
postulantes,
voluntarios y rescatistas son llevados de forma
manuscrita lo que provoca reportes econmicos falsos. Los

gastos realizados en operativos y actividades son realizados de
forma ambigua provocando incertidumbre y confusin.
1.4 Objetivos
1.4.1 Objetivo general
Luego de un anlisis de problemas se ha elaborado un rbol de objetivos [ver
ANEXO B], lo que ha permitido determinar el objetivo general.
Desarrollar un sistema de informacin administrativo que permita al usuario contar
con informacin oportuna y fiable de los datos personales de los rescatistas y
materiales logsticos,
adems de informacin pertinente de recursos financieros,
para as mejorar de manera eficaz la administracin de informacin en la institucin

militar SAR-FAB ILLIMANI.
1.4.2 Objetivos especficos
Organizar adecuadamente la informacin personal de cada postulante,
voluntario y rescatista de manera que se pueda obtener fcilmente datos
precisos de los mismos, evitando la ineficiencia del plan de llamadas y
agilizando la entrega de libretas de servicio militar.
6
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 recopilacin, almacenaje y recuperacin de los
datos logsticos e informacin de materiales evitando extravos, robos y poner
en peligro la vida de los rescatistas.
Organizar adecuadamente la informacin 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 Justificacin
1.5.1 Justificacin acadmica
El sistema propuesto tiene como finalidad mejorar el manejo de informacin dentro
de la institucin, es adecuado porque va a servir de herramienta para el personal
administrativo de manera que puedan recurrir instantneamente a datos de los
Rescatistas y sus reas de especialidad en casos de emergencia.
Se emplearn todos los conocimientos obtenidos en reas de anlisis y diseo de
sistemas, base de datos, programacin e ingeniera de software para implementar el
sistema informtico que va a contribuir en diferentes mbitos administrativos.
1.5.2 Justificacin 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 Justificacin econmica

En este aspecto podemos mencionar que ao tras ao se ha evidenciado que
existen gastos insulsos en reposicin de libretas de servicio militar, ya que por la falta
de sistematizacin de la informacin y por la existencia de datos errneos, se ha
procedido al llenado de libretas con datos errneos y se tuvo que reponer los mismos
con recursos propios de la institucin.
En el marco del proyecto, tampoco se cuenta con un equipo de ltima generacin,
esto debido a los bajos recursos econmicos del GRUPO SAR y por tanto se
implementar un sistema con un software que requiera bajos recursos de hardware.
1.6 Alcances y aportes
1.6.1 Alcances
El proyecto contempla el anlisis, diseo e implementacin de un sistema informtico
que administrar: registro de datos de todo el personal rescatista, control y reportes
semanales de asistencia, registro de datos de materiales logsticos y planillas de
recursos financieros de aportes y gastos de la institucin.
1.6.2 Aportes
1.6.2.1
Aportes acadmicos
Los aportes acadmicos van delimitados:

Como prototipo de un nuevo software de sistemas informticos para
instituciones militares.
El uso del Anlisis y Diseo de sistemas aplicado en la Ingeniera de Software.
La aplicacin de herramientas tecnolgicas e informticas en una institucin
militar.
1.6.2.2
Aportes institucionales
Los aportes institucionales se vern reflejados de la siguiente manera:

Reduccin de la desorganizacin en datos personales.
Organizacin en el manejo y registro de la informacin de todo el personal de
rescate.
Confiabilidad en la informacin 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.
Recopilacin, almacenaje y recuperacin de datos adecuado para una buena
ejecucin e incremento en la efectividad del plan de llamadas.
8
Disminucin de prdidas y extravos de materiales de la institucin y gastos
vanos.
Productividad de uso con los bajos recursos computacionales de la institucin.
1.6.3 Metodologas y tcnicas
1.6.3.1
Mtodos
Para el desarrollo del proyecto se utilizan las siguientes metodologas de

investigacin:
Mtodo cientfico
Mtodo inductivo
Mtodo deductivo
Para el desarrollo del proyecto se utilizan los siguientes modelos:
Modelo RUP (Rational Unified Process)5
Modelo Orientado a Objetos (UML)
Modelo de estimacin de costos COCOMO
1.6.3.2
Tcnicas
Para el desarrollo del proyecto se utilizan las siguientes tcnicas:

Entrevistas, cuestionarios, observaciones y encuestas
Diccionario de datos
Diagramas de casos de uso
CAPTULO 2
2. MARCO TERICO
2.1 Introduccin
5 Rational Unifed Process, en espaol Proceso Racional Unificado
9
En el siguiente captulo se dar a conocer los conceptos bsicos, herramientas y

metodologas que se utilizarn en todo el desarrollo del trabajo de investigacin y en
la aplicacin del mismo. Estos conceptos tienen diferentes fuentes de investigacin.
2.2 Sistema
Implcitamente el trmino sistema fue conocido por Aristteles en su famoso
enunciado El todo es ms 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
teora de sistemas. Hoy en da el trmino sistema es utilizado con mucha frecuencia
en diferentes mbitos tanto tcnicos, econmicos, polticos y sociales.
2.2.1 Concepto de sistema
Una primera aproximacin a la comprensin de lo que significa, un sistema es una
caja negra, donde se identifica las entradas, el proceso y las salidas.
Figura 2. Representacin esquemtica de un sistema

Fuente: Elaboracin propia
La entrada es el flujo de materia, informacin o energa 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 transformacin 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 Definicin de sistema
Por la generalidad de este trmino, han sido varios autores que intentan explicar su
significado en consideracin a sus caractersticas:
10
Conjunto de cosas que relacionadas entre s ordenadamente contribuyen a

determinado objeto6.
Conjunto de partes coordinadas y en interaccin 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 informacin
son parte de este ltimo.
2.3 Informacin
2.3.1 Definicin de la informacin
Informacin es un conjunto ordenado de datos que tienen un determinado
valor o significado; es la unidad bsica del conocimiento
Informacin son datos procesados en forma significativa, para el receptor, con
valor real y perceptible para decisiones presentes o futuras. (Davis, 1974)
2.3.2 Caractersticas de la informacin
La informacin puede caracterizarse de varias formas; ciertas clases de informacin
son ms adecuadas que otras para un problema de decisin. Se debe verificar que
las caractersticas de la informacin se ajuste a la situacin y al modelo de
interpretacin del tomador de decisiones.
La informacin puede ser:
Histrica o predicativa
Anticipada o inesperada
Resumida o detallada
Actualizada o relativamente antigua
Estructurada poco o mucho
6 Diccionario de la Real Academia de la lengua Espaola (DRAE)
7 Johansen, B. O. (2001). Introduccin a la Teora General de Sistemas: Qu es un
sistema (Cap. 3, p. 54). Mxico: Grupo Noriega-Editorial Limusa S.A. de C.V.
11
Para que un sistema pueda proporcionar informacin correcta, en el momento

oportuno y en la medida suficiente, se necesita, en todo momento, que la informacin
sea programada y controlada.
La programacin y el control de la informacin por consiguiente, deben proporcionar
a stas ciertas caractersticas de orden prctico, que se resumen a continuacin.
Ser sinttica
Ser formal
Ser fidedigna
Ser de fcil comprensin
Ser de fcil utilizacin
Tener una finalidad definida e identificada
Ser emitida con claridad
Ser recibida sin dificultades
2.4 Sistema de informacin
2.4.1 Definicin de sistema de informacin
Todo sistema de informacin (SI) se disea a fin de satisfacer las necesidades de
informacin de una organizacin (empresa o cualquier tipo de institucin pblica o
privada) y est inmerso en ella. El SI ha de tomar los datos del entorno (la propia
organizacin as como fuentes externas) y sus resultados han de ser la informacin
que dicha organizacin necesita para su gestin y toma de decisiones 8.
2.4.2 Elementos de los sistemas de informacin
Los componentes ms importantes de un sistema de informacin son los siguientes:
Financieros: Es el aspecto econmico que permite la adquisicin, contratacin
y mantenimiento de los dems recursos que integran un sistema de
informacin.
8 Piattini, M. G., Marcos, E., Calero, C., y Vela, B. (2007). Tecnologa y diseo de
bases de datos: Sistemas de informacin y bases de datos (Cap. 1, p. 9). Mxico:
Alfaomega Grupo Editor S. A. de C. V.
12
Administrativos: Es la estructura orgnica de objetivos, lineamientos,

funciones, procedimientos, departamentalizacin, direccin y control de las
actividades; que sustenta la creacin y uso de los sistemas.
Humanos: Est compuesto por dos grupos:
o El tcnico: es quien posee los conocimientos especializados en el
desarrollo de sistemas, siendo estos los: Administradores, Lderes de
Proyecto, Analistas, Programadores, Operadores y Capturistas.
o El usuario: representado por las personas interesadas en el manejo de
informacin va cmputo, como apoyo al mejor desempeo de sus
actividades, siendo stos los: Encargados de seccin, Comandante del
Grupo SAR, etc.
Materiales: Son aquellos elementos fsicos que soportan el funcionamiento de
una sistema de informacin, por ejemplo; local de trabajo, instalaciones
elctricas y aire acondicionado, medios de comunicacin, mobiliario,
maquinaria, papelera, etc.
Tecnolgicos: Es el conjunto de conocimientos, experiencias, metodologas y
tcnicas; que orientan la creacin, operacin y mantenimiento de un sistema.
2.4.3 Clasificacin de los sistemas de informacin
2.4.3.1
Sistemas de informacin administrativos
Estos sistemas de informacin manejan los datos orientados a la toma de decisiones

para resolver problemas por parte de los administradores. La informacin que surge,
sirve para ayudar a la toma de decisiones administrativas.
Los datos que se manejan son transacciones, del procesamiento de stas surgirn
informes que darn idea de la situacin. Se analizarn las posibles decisiones a
tomar, se estudiarn las posibles consecuencias de las diferentes acciones y se
optar por la ms adecuada.
2.4.3.2
Sistemas de informacin organizacionales
Es la clasificacin de los sistemas de informacin en relacin a las funciones

organizacionales que utilizan su informacin. Entendindose por funcin a una serie
de actividades relacionadas en forma cercana.
13
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 ingeniera de software.
2.5.1 Definiciones de software
Conjunto de programas, instrucciones y reglas informticas que permiten
ejecutar ciertas tareas en un computadora9.
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 operacin y uso del
programa.10
Figura 3. Representacin esquemtica de un sistema

2.6 Ingeniera de software
Es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para
desarrollar y mantener software de calidad.
Esta ingeniera trata con reas muy diversas de la informtica y de las ciencias de la
computacin, tales como construccin de compiladores, sistemas operativos, o
desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del
desarrollo de cualquier tipo de sistemas de informacin y aplicables a infinidad de
9 RAE Real Academia Espaola. (2014). Diccionario de la lengua espaola
(23.aed.). Madrid, Espaa
10 Laboratorio Nacional de Calidad del Software, (2009), Ingeniera de Software
Metodologas y Ciclos de Vida, Espaa, Instituto Nacional de Tecnologas de la
Comunicacin.
14
reas (negocios, investigacin cientfica, medicina, produccin, logstica, banca,

control de trfico, meteorologa, derecho, Internet, Intranet, etc.)
2.6.1 Definicin de ingeniera de software
La ingeniera de software es una disciplina de la ingeniera que comprende todos los
aspectos de la produccin de software desde las etapas iniciales de la especificacin
del sistema, hasta el mantenimiento de ste despus que se utiliza 11.
2.6.2 Etapas del proceso de ingeniera de software
La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas
como las siguientes:
Anlisis de requerimientos
Se extraen los requisitos del producto de software. En esta etapa la habilidad y
experiencia en la ingeniera del software es crtica para reconocer requisitos
incompletos, ambiguos o contradictorios. Usualmente el cliente/usuario tiene una
visin incompleta/inexacta de lo que necesita y es necesario ayudarle para
obtener la visin completa de los requerimientos. El contenido de comunicacin
en esta etapa es muy intenso ya que el objetivo es eliminar la ambigedad en la
medida de lo posible.
Especificacin
La Especificacin 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 interaccin con los usuarios y/o otros sistemas.
Diseo y Arquitectura
Determinar cmo funcionar de forma general sin entrar en detalles
incorporando consideraciones de la implementacin tecnolgica, como el
hardware, la red, etc. Consiste en el diseo de los componentes del sistema
que dan respuesta a las funcionalidades descritas en la segunda etapa
tambin conocidas como las entidades de negocio. Generalmente se realiza
en base a diagramas que permitan describir las interacciones entre las
entidades y su secuenciado.
11 Sommerville, I., (2005). Ingeniera del Software: Introduccin a las
computadoras (Cap. 1, p. 6). Espaa: Pearson Educacin, S. A.
15
Nosotros utilizaremos diagramas de casos de uso y diagramas de secuencia.

Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera
de software, pero no necesariamente es la que demanda mayor trabajo y ni la
ms complicada. La complejidad y la duracin de esta etapa est ntimamente
relacionada al o a los lenguajes de programacin utilizados, as como al diseo
previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas
indicadas en la especificacin del problema. Una tcnica de prueba es probar
por separado cada mdulo del software, y luego probarlo de forma integral,
para as llegar al objetivo. Se considera una buena prctica 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 evala que la documentacin entregada sea de
calidad, que los procesos descritos son tan claros que cualquiera puede
entenderlos y el software hace las cosas tal y como estn 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 aplicacin y que pueden

poner atencin en detalles que personal inexperto no considerara.
Documentacin
Es la realizacin del manual de usuario, y posiblemente un manual tcnico con el
propsito de mantenimiento futuro y ampliaciones al sistema. Las tareas de esta
etapa se inician ya en la primera fase pero slo 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 ms
tiempo incluso que el desarrollo inicial del software. Alrededor de dos tercios
de toda la ingeniera de software tiene que ver con dar mantenimiento. Una
16
pequea 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 Metodologas de desarrollo de software
La ingeniera de software, con el fin de ordenar el caos que era anteriormente el
desarrollo de software, dispone de varias metodologas, paradigmas y filosofas 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 concepcin de una idea hasta la entrega y el
retiro del sistema
Los modelos de desarrollo de software son una representacin abstracta de una
manera en particular. Realmente no representa cmo se debe desarrollar el software,
sino de un enfoque comn. 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 debera escoger el ms apropiado para sus necesidades. En ocasiones
puede que una combinacin de varios modelos sea apropiado.
Entre los distintos modelos podemos citar dos grupos:
Metodologas 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
Metodologas giles
Extreme programing13 (XP)
SCRUM
Dynamic Systems Development Method (DSDM)
12 Error o defecto en el software o hardware que hace que un programa funcione
incorrectamente.
13 Extreme Programing, en espaol Programacin Extrema
17
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 metodologa estndar
ms utilizada para el anlisis, implementacin y documentacin de sistemas
orientados a objetos.
Las caractersticas esenciales de la metodologa RUP son tres: dirigida por casos de
uso, iterativos e incrementales y centrados en la arquitectura.
Caso de uso
Los casos de uso describen cmo los usuarios interactan 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 evolucin 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 versin 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 ms 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 ms efectivo del producto final.
Centrado en la arquitectura
En RUP e proceso se basa en disear tempranamente una arquitectura base
ejecutable. La arquitectura de un sistema, es la organizacin o estructura de
sus partes (componentes) ms relevantes dejando de lado los detalles, incluye
los aspectos estticos y dinmicos del sistema.
18
Figura 4. Tabla de esfuerzos en actividades modelo RUP

Fuente: http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
2.7 Anlisis y diseo de sistemas
Dentro de las organizaciones, el anlisis y diseo de sistemas se refiere al proceso
de examinar la situacin de una empresa con el propsito de mejorarla con mtodos
y procedimientos ms adecuados14
2.7.1 Anlisis de sistemas
2.7.1.1
Conceptos y anlisis
Es un conjunto o disposicin 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 lgico en la
unin de las partes. Un mtodo, plan o procedimiento de clasificacin para hacer
algo. Tambin es un conjunto o arreglo de elementos para realizar un objetivo
predefinido en el procesamiento de la informacin. Esto se lleva a cabo teniendo en
cuenta ciertos principios:
14 Senn, J. (1992). Anlisis y Diseo de Sistemas: Introduccin al desarrollo de
sistemas de informacin (Cap. 1, p. 11). Mxico: Mc-Graw Hill.
19
Debe presentarse y entenderse el dominio de la informacin de un problema.

Defina las funciones que debe realizar el software
Represente el comportamiento del software a consecuencia de
acontecimientos externos
Divida en forma jerrquica los modelos que representan la informacin,
funciones y comportamiento.
El proceso debe partir desde la informacin esencial hasta el detalle de la
implementacin.
La funcin del anlisis 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
documentacin hacen efectiva la logstica, metodologa o controles de
requerimientos del programa.
Hardware, dispositivos electrnicos y electromecnicos, que proporcionan
capacidad de clculos y funciones rpidas, exactas y efectivas (computadoras,
sensores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin
externa dentro de los sistemas.
Personal, son los operadores o usuarios directos de las herramientas del
Sistema (en algunos casos los RRHH de la institucin).
Base de datos, una gran coleccin de informaciones organizadas y enlazadas
al sistema a las que se accede por medio del software.
Documentacin, son los manuales, formularios, y otra informacin descriptiva
que detalla o da instrucciones sobre el empleo y operacin del programa.
Procedimientos, o pasos que definen el uso especfico de cada uno de los
elementos o componentes del sistema y las reglas de su manejo y
mantenimiento.
2.7.1.2
Objetivos del anlisis
Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en

mente:
20
Identificacin de necesidades
Es el primer paso del anlisis del sistema, en este proceso el analista se rene
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 planificacin temporal y presupuestal, lneas de mercadeo y otros puntos
que puedan ayudar a la identificacin y desarrollo del proyecto.
Algunos autores suelen llamar a esta parte Anlisis de Requisitos y lo
dividen en cinco partes:
Reconocimiento del problema
Evaluacin y sntesis
Modelado
Especificacin
Revisin
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 materializacin sin tener
prdidas econmicas y frustracin profesional. La viabilidad y el anlisis de
riesgos estn 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 inters:
o Viabilidad econmica
Una evaluacin de los costos de desarrollo, comparados con los
ingresos netos o beneficios obtenidos del producto o sistema
desarrollado.
o Viabilidad tcnica
Un estudio de funciones, rendimiento y restricciones que puedan
afectar la realizacin de un sistema aceptable.
o Viabilidad legal
Es determinar cualquier posibilidad de infraccin,
violacin
responsabilidad legal en que se podra incurrir al desarrollar el sistema.

Anlisis econmico y tcnico
El anlisis econmico incluye lo que llamamos, el anlisis de costosbeneficios, significa una valoracin de la inversin econmica comparado con
los beneficios que se obtendrn en la comercializacin y utilidad del producto
o sistema.
Muchas veces en el desarrollo de sistemas de computacin, stos son
intangibles y resulta un poco dificultoso evaluarlos; esto vara de acuerdo a las
21
caractersticas del sistema. El anlisis de costos-beneficios es una fase muy

importante y de ella depende la posibilidad de desarrollo del proyecto.
En el anlisis tcnico, el analista evala los principios tcnicos del sistema y al
mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad,
caractersticas de mantenimiento y productividad.
Los resultados obtenidos del anlisis tcnico 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, mquinas, se crea un modelo idntico,
pero en menor escala (ms pequeo).
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 cmo lo
hace, stos modelos pueden incluir notacin grfica, informacin y
comportamiento del sistema.
Todos los Sistemas basados en computadoras pueden modelarse como
transformacin de la informacin empleando una arquitectura del tipo entrada
y salida.
Especificaciones del sistema
Es un documento que sirve como fundamento para la ingeniera hardware,
software, bases de datos,
e ingeniera humana. Describe la funcin y
rendimiento de un sistema basado en computadoras y las dificultades que

estarn presentes durante su desarrollo. Las especificaciones de los requisitos
del software se producen en la terminacin de la tarea del anlisis.
En Conclusin un proyecto de desarrollo de un sistema de informacin comprende
varios componentes o pasos llevados a cabo durante la etapa del anlisis, el cual
ayuda a traducir las necesidades del cliente en un modelo de sistema que utiliza uno
ms de los componentes: software, hardware, personas, base de datos,
documentacin y procedimientos.
22
2.7.2 Diseo de sistemas

2.7.2.1
Conceptos y principios
El diseo de sistemas define el proceso de aplicar ciertas tcnicas y principios con el

propsito de especificar un dispositivo, un proceso o un sistema, con suficientes
detalles como para permitir su interpretacin y realizacin fsica.
2.7.2.2
Etapas del diseo de sistemas
La etapa del diseo de sistemas encierra cuatro fases:

Diseo de los datos
Trasforma el modelo de dominio de la informacin, creado durante el anlisis,
en las estructuras de datos necesarios para implementar el Software.
Diseo arquitectnico
Define la relacin entre cada uno de los elementos estructurales del programa.
Diseo de la interfaz
Describe cmo se comunica el software consigo mismo, con los sistemas que
operan junto con l y con los operadores y usuarios que lo emplean.
Diseo de los procedimientos
Transforma elementos estructurales de la arquitectura del programa. La
importancia del diseo del software se puede definir en una sola palabra
Calidad; dentro del diseo es donde se fomenta la calidad del proyecto. El
diseo es la nica manera de materializar con precisin los requerimientos del
cliente.
Diseo de la salida
En este caso salida se refiere a los resultados e informaciones generadas por
el sistema. Para la mayora de los usuarios la salida es la nica razn para el
desarrollo de un sistema y la base de evaluacin de su utilidad. Sin embargo
cuando se realiza un sistema, como analista se debe realizar lo siguiente:
Determine qu informacin presentar. Decidir si la informacin ser
presentada en forma visual, verbal o impresa y seleccionar el medio de
salida.
Disponga la presentacin de la informacin en un formato aceptable.
Decida cmo distribuir la salida entre los posibles destinatarios.
23
2.7.2.3
Herramientas para el diseo de sistemas
Las herramientas para el diseo de sistemas nos apoyan en el proceso de

formulacin de las caractersticas que el sistema debe tener para satisfacer los
requerimientos detectados durante las actividades del anlisis.
Herramientas de especificacin
Apoyan el proceso de formulacin de las caractersticas que debe tener una
aplicacin, tales como entradas, salidas, procesamiento y especificaciones de
control. Muchas incluyen herramientas para crear especificaciones de datos.
Herramientas para presentacin
Se utilizan para describir la posicin 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 diseos en
aplicaciones funcionales.
Herramientas para ingeniera de software
Apoyan en el proceso de formular diseos de software, incluyendo
procedimientos y controles, as como la documentacin correspondiente.
Generadores de cdigos
Producen el cdigo fuente y las aplicaciones a partir de especificaciones
funcionales bien articuladas.
Herramientas para pruebas
Apoyan la fase de la evaluacin de un sistema o de partes del mismo contra

las especificaciones. Incluyen facilidades para examinar la correcta operacin
del sistema as como el grado de perfeccin alcanzado en comparacin con
las expectativas.
2.8 Modelo Orientado a Objetos
2.8.1 Conceptos orientados a objetos
Debido a que el anlisis y diseo orientado a objetos est fuertemente relacionado
con la programacin orientada a objetos debemos explorar brevemente el contexto
de P.O.O15.
bases de datos: Anlisis y Diseo de Sistemas Orientado a Objetos (Cap. 22, p.
860). Mxico: Alfaomega Grupo Editor S. A. de C. V.
24
Son seis las ideas bsicas que caracterizan a la programacin orientada a objetos:
Objetos
Un objeto es una representacin en computadora de alguna cosa o evento
del mundo real.
Clases
Una clase es una categora de objetos similares. Los objetos se agrupan en
clases.
Mensajes
Se refiere al proceso de enviado de informacin, de un objeto a otro
Encapsulacin
Esta caracterstica es la que denota la capacidad del objeto de responder a
peticiones a travs de sus mtodos sin la necesidad de exponer los medios
utilizados para llegar a brindar estos resultados.
Herencia
Es la caracterstica por la cual los objetos para su creacin se basan en una
clase de base, heredando todas sus propiedades, mtodos y eventos; los
cuales a su vez pueden o no ser implementados y/o modificados.
Polimorfismo
El trmino de polimorfismo define la capacidad de que ms 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 ingls, Unified Modeling Language; es el lenguaje de
modelado de sistemas de software ms conocido y utilizado en la actualidad; est
respaldado por el OMG 16. Es un lenguaje grfico para visualizar, especificar, construir
y documentar un sistema. UML ofrece un estndar 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 programacin, esquemas de bases de datos y componentes
reutilizables.
16 Del acrnimo Object Management Group, es un consorcio dedicado al cuidado y

el establecimiento de diversos estndares de tecnologas orientadas a objetos
25
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o

para describir mtodos 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 metodologa de desarrollo de software, tal como el Proceso
Unificado Racional o RUP17, pero no especifica en s mismo qu metodologa o
proceso usar.
UML no puede compararse con la programacin estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad
de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es
una forma de programar como lo es la orientacin a objetos, sin embargo, la
programacin orientada a objetos viene siendo un complemento perfecto de UML,
pero no por eso se toma UML slo 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 jerrquicamente, como se muestra en la
siguiente figura:
17 Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de

Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis,
implementacin y documentacin de sistemas orientados a objetos.
26
Figura 5. Jerarqua de los diagramas UML 2.0

Fuente: Recuperado de: http://es.wikipedia.org/wiki/UML
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 interaccin
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
27
Diagrama de comunicacin, que es una versin simplificada del

Diagrama de colaboracin (UML 1.x)
Diagrama de tiempos (UML 2.0)
Diagrama global de interacciones o Diagrama de vista de interaccin
(UML 2.0)
2.8.3.1
Diagramas de clase
Es un tipo de diagrama esttico que describe la estructura de un sistema mostrando

sus clases, orientados a objetos y sus interrelaciones (incluyendo herencia,
agregacin, asociacin, etc.). Los diagramas de clase son el pilar bsico de
modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede
hacer (anlisis), como para mostrar cmo puede ser construido (diseo).
NOTACION.
Cada clase se representa en un rectngulo con tres compartimientos:
Nombre de la Clase
Atributo 1
Atributo 2
.................
Operacion1( )
Operacion2( )
.................
Figura 6. Notacin de una clase
Nombre de la clase
Atributos de la clase
Mtodos u operaciones de la clase
28
Atributos:
Los atributos de una clase no deberan ser manipulables directamente por el resto de
objetos. Por esta razn se crearon niveles de visibilidad para los elementos que son:
Privado (-): es el ms fuerte. Esta parte es totalmente invisible (excepto para
clases friends en terminologa C++).
Protegido (#): Los atributos/operaciones protegidos estn visibles para las
clases friends y para las clases derivadas de la original.
Pblico (+): Los atributos/operaciones pblicos son visibles a otras clases
(cuando se trata de atributos se est transgrediendo el principio de
encapsulacin).
Mtodos:
Los mtodos u operaciones de una clase son la forma en como sta interacta con
su entorno, stos pueden tener las caractersticas:
Privado (-): Indica que el mtodo slo ser accesible desde dentro de la clase
(slo otros mtodos de la clase lo pueden acceder).
Protegido (#): Indica que el mtodo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de mtodos de
las subclases que se deriven (ver herencia).
Pblico (+): Indica que el mtodo 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 estndar
UML, el cual describe notacin grfica para esas relaciones:
Inclusin
Es una forma de interaccin o creacin, 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 mltiples casos de uso a una descripcin
29
individual (si el actor realiza el caso de uso base tendr que realizar tambin el
caso de uso incluido), desde el caso de uso.
Extensin
Es otra forma de interaccin, un caso de uso dado (la extensin)
puede extender a otro. Esta relacin indica que el comportamiento del caso de
la extensin se utiliza en casos de uso, un caso de uso a otro caso siempre
debe tener extensin o inclusin. El caso de uso extensin puede ser
insertado en el caso de uso extendido bajo ciertas condiciones. La notacin,
es una flecha de punta abierta con lnea discontinua, desde el caso de uso
extensin 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 extensin.
Generalizacin
La Generalizacin es la actividad de identificar elementos en comn entre
conceptos y definir las relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de construir clasificaciones
entre conceptos que entonces se representan en jerarquas de clases. Las
subclases conceptuales son conformes con las superclases conceptuales en
cuanto a la intencin y extensin."
2.8.3.3
Diagramas de secuencia
Un diagrama de secuencia es una representacin de las interacciones que muestran

los objetos entre s a lo largo de su vida en el tiempo, estas interacciones son
llamados mensajes y grficamente estn representadas como flechas desde la lnea
de vida origen hasta la lnea de vida destino.
Su funcin 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 diseo de la aplicacin.
30
Los diagramas de secuencia estn compuestos por:
Lnea de vida
Es una representacin de un participante individual, esta lnea por lo general
se representan con una lnea punteada que contiene a su inicio un rectngulo
con el nombre del objeto.
Los que interactan pueden ser de diferentes y cada uno de ellos tendr una
lnea de vida mientras dure su interaccin dentro de la funcionalidad del caso
de uso representado.
Mensajes
Los mensajes es aquello que se intercambian los objetos en la Lnea de Vida,
su representacin grfica es una flecha; los mensajes pueden ser de
diferentes formas, donde:
o Mensajes sncronos: se representan con una flecha de punta oscura.
o Mensajes asncronos: se representan con una flecha en lnea, los
mensajes de retornos asncronos son denotados por una lnea punteada.
Fragmentos
Los fragmentos son aquellas secciones que cumplen determinada
funcionalidad en un diagrama de secuencia y es necesario tener controlado a
travs de mecanismos que permiten agregar un grado de lgicas de
procedimientos a los diagramas.
2.9 Base de datos
2.9.1 Definicin de base de datos
Coleccin o depsito de datos integrados, almacenados en soporte secundario (no
voltil) y con redundancia controlada. Los datos, que han de ser compartidos por
diferentes usuarios y aplicaciones, deben mantenerse independientes de ellos, y su
definicin (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
31
actualizacin y recuperacin, comunes y bien determinados facilitarn 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 clasificacin:
Segn la variabilidad de los datos almacenados
Bases de datos estticas
stas son bases de datos de slo lectura, utilizadas primordialmente
para almacenar datos histricos que posteriormente se pueden utilizar
para estudiar el comportamiento de un conjunto de datos a travs del
tiempo, realizar proyecciones y tomar decisiones.
Base de datos dinmicas
stas son bases de datos donde la informacin almacenada se
modifica con el tiempo, permitiendo operaciones como actualizacin,
borrado y adicin de datos, adems de las operaciones fundamentales
de consulta. Un ejemplo de esto puede ser la base de datos utilizada en
un sistema de informacin de una tienda de abarrotes, una farmacia, un
videoclub.
Segn el contenido
Bases de datos bibliogrficas
Solo contienen un representante de la fuente primaria, que permite
localizarla. Un registro tpico de una base de datos bibliogrfica
contiene informacin sobre el autor, fecha de publicacin, editorial,
ttulo, edicin, de una determinada publicacin, etc.
Bases de datos de texto complejo
Almacenan las fuentes primarias, como por ejemplo, todo el contenido
de todas las ediciones de una coleccin de revistas cientficas.
Directorios
Un ejemplo son las guas telefnicas en formato electrnico.
Bases de datos de informacin qumica o biolgica
bases de datos: Sistemas de informacin y bases de datos (Cap. 1, p. 26). Mxico:
Alfaomega Grupo Editor S. A. de C. V.
32
Son bases de datos que almacenan diferentes tipos de informacin

proveniente de la qumica, las ciencias de la vida o mdicas. Se pueden
considerar en varios subtipos:
Las que almacenan secuencias de nucletidos o protenas.
Las bases de datos de rutas metablicas.
Bases de datos de estructura, comprende los registros de datos
experimentales.
Bases de datos clnicas.
Bases de datos bibliogrficas (biolgicas, qumicas, mdicas y
de otros campos.
2.9.3 Modelos de bases de datos

Adems de la clasificacin por la funcin de las bases de datos, stas tambin se
pueden clasificar de acuerdo a su modelo de administracin de datos.
Un modelo de datos es bsicamente una "descripcin" de algo conocido como
contenedor de datos (algo en donde se guarda la informacin), as como de los
mtodos para almacenar y recuperar informacin de esos contenedores.
Algunos modelos con frecuencia utilizados en las bases de datos:
Bases de datos jerrquicas
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 recoleccin de datos
2.9.4.1
Diccionario de datos
El diccionario de datos es una aplicacin 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 travs del anlisis y diseo.
33
Como documento, el diccionario de datos recolecta, coordina y confirma lo que

significa un trmino de datos especfico para diferentes personas de la organizacin.
Los diagramas de flujo de datos son un punto de arranque para la recoleccin de
entradas del diccionario de datos19.
2.10 Fases de implementacin, pruebas y mantenimiento del software
2.10.1 Implementacin del software
Es la fase de programacin o escritura del cdigo, en el lenguaje de programacin
elegido, una vez que se tenga completo el diagrama de diseo.
2.10.2 Windows Presentation Foundation (WPF)
Es una tecnologa de Microsoft que permite el desarrollo de interfaces ricas de
usuario ofrecindonos una potencia grfica con la que es posible desarrollar
aplicaciones visualmente muy atractivas. Dicha interfaz se desarrolla por medio del
lenguaje
declarativo
XAML
(eXtensible
Application
Markup
Language)
separadamente de la lgica de negocio de la aplicacin 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 pginas de navegacin 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 creacin de
aplicaciones empresariales de tipo escritorio o aplicaciones web enriquecidas.
bases de datos: Anlisis y diseo utilizando diccionario de datos (Cap. 10, p. 293).
Mxico: Alfaomega Grupo Editor S. A. de C. V.
34
WPF nos permite a los desarrolladores reutilizar el cdigo y crear rpidamente

versiones web y de cliente de las aplicaciones.
Se recomienda usar WPF sobre Windows Forms porque Microsoft est enfocando
est tecnologa como la plataforma para el desarrollo de interfaces de ltima
generacin a los que aporta una mayor riqueza visual y nuevos componentes.
2.10.3 Librera MahApp.Metro con WPF
Desde que sali Windows 8 se empez a dar tambin importancia no solamente a la
funcionalidad de una aplicacin, sino al diseo de interfaces de usuario. Por lo tanto
la tecnologa ms adecuada para poder realizar una interfaz de usuario lo ms rica
visualmente es WPF con su librera 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 Programacin por capas
La programacin por capas es una arquitectura de programacin en el que el objetivo
primordial es la separacin de la lgica de negocios de la lgica de diseo; un
ejemplo bsico de esto consiste en separar la capa de datos de la capa de
presentacin 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 algn cambio, solo se ataca al nivel
requerido sin tener que revisar entre cdigo mezclado. Adems, permite distribuir el
trabajo de creacin de una aplicacin por niveles; de este modo, cada grupo de
trabajo est totalmente abstrado del resto de niveles, de forma que basta con
conocer la API que existe entre niveles.
En el diseo de sistemas informticos actual se suelen usar las arquitecturas
multinivel o Programacin por capas. En dichas arquitecturas a cada nivel se le
35
confa una misin simple, lo que permite el diseo 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
parmetros que sern aadidos al atributo correspondiente para el negocio,
Capa de presentacin: la que ve el usuario (tambin se la denomina "capa
de usuario"), presenta el sistema al usuario, le comunica la informacin y
captura la informacin del usuario en un mnimo de proceso (realiza un filtrado
previo para comprobar que no hay errores de formato). Tambin es conocida
como interfaz grfica y debe tener la caracterstica de ser "amigable"
(entendible y fcil 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 envan las respuestas tras el proceso.
Se denomina capa de negocio (e incluso de lgica del negocio) porque es
aqu donde se establecen todas las reglas que deben cumplirse. Esta capa se
comunica con la capa de presentacin, para recibir las solicitudes y presentar
los resultados, y con la capa de datos, para solicitar al gestor de base de
datos almacenar o recuperar datos de l. Tambin se consideran aqu los
programas de aplicacin.
Capa de modelo: es donde residen los datos y es la encargada de acceder a
los mismos. Est formada por uno o ms gestores de bases de datos que
realizan
todo
el
almacenamiento
de
datos,
reciben
solicitudes
almacenamiento o recuperacin de informacin desde la capa de negocio.
36
de
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
produccin si se ha planificado una instalacin gradual.
Una vez se tiene una versin 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
Mtodos 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 depuracin al proceso en el que se
localiza el defecto (que es la causa del fallo), se determina la forma de corregirlo, de
evala el efecto de la correccin y se lleva a cabo la correccin.
Existen enfoques sistemticos que ayudan a encontrar buenos conjuntos de casos
de prueba y a determinar su grado de cobertura, son los siguientes:
Tcnica de prueba de caja negra
En esta tcnica 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 lgica
interna del software.
No se utilizan frente a las pruebas de Caja Blanca, sino que constituyen
un conjunto de tcnicas que tratan de detectar errores de diferentes
tipos. Se centran sobre el dominio de informacin 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 inicializacin o terminacin.
Las ventajas que presentan este tipo de mtodos de prueba son dos:
Reducen el nmero de casos de prueba que se deben disear.
37
Detectan clases de errores en vez de errores simples.

Algunos mtodos de caja negra son:
Clases de equivalencia
Valores lmite
Grafo causa-efecto
Representacin de un grafo
Tcnica de prueba de caja blanca

Con esta metodologa se comprueban los componentes internos (mdulos,
subprogramas, bucles, condiciones, etc.).
El programa que se desea probar se ve como una caja transparente y la
eleccin 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 ms exhaustivos):
Cobertura de sentencias
Cobertura de decisiones
Cobertura de condiciones
Cobertura de decisiones/condiciones
Cobertura de condiciones mltiples
Cobertura de caminos
La tcnica de prueba de caja blanca es una metodologa de prueba que
se basa en las estructuras de control del diseo 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 mdulo.
Se ejecuten todas las decisiones lgicas 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
tienen
posibilidades de recorrerse, son recorridos regularmente.

38
pocas
Los errores tipogrficos son aleatorios. Puede que no sean detectados

por los procesadores de la sintaxis del lenguaje particular y
estar presentes en cualquier camino lgico.
2.10.5.2
Calidad de software
Es la concordancia con los requisitos funcionales y de rendimiento explcitamente

establecidos con los estndares de desarrollo explcitamente documentados y con
las caractersticas implcitas 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 computacin es
la calidad del software. Desde la dcada del 70, este tema ha sido
motivo de preocupacin para especialistas, ingenieros, investigadores y
comercializadores de software, los cuales han realizado gran cantidad de
investigaciones al respecto con dos objetivos fundamentales:
Cmo obtener un software con calidad?
Cmo evaluar la calidad del software?
Ambas interrogantes conllevan amplias respuestas, pero estn 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 inters por la calidad crece de forma continua a medida
que los clientes se vuelven ms selectivos y comienzan a rechazar los
productos poco confiables o que realmente no dan respuesta a sus necesidades.
2.10.5.3
Mtricas de calidad de software
Muchos investigadores han intentado desarrollar una sola mtrica que

proporcione una medida completa de la complejidad del software. Aunque se
han propuesto docenas de mtricas 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 difcil de obtener
un solo valor de estas mtricas de calidad. Aun as debera ser posible
desarrollar medidas de diferentes atributos internos del programa.
39
Aunque todos estos obstculos son motivo de preocupacin, no son

motivo de desprecio hacia las mtricas. Es por eso que se dice que la
medicin es esencial, si es que se desea realmente conseguir la calidad en
software.
Existen distintos tipos de mtricas para poder evaluar, mejorar y clasificar
al software final en donde sern manejadas dependiendo del entorno de
desarrollo del software al cual pretendan orientarse:
Clasificacin de mtricas de software
La clasificacin de una mtrica de software refleja o describe la conducta
del software. Todas las clasificaciones de mtricas fortalecen la idea,
de que ms de una mtrica puede ser deseable para valorar la complejidad
y la calidad del software. A continuacin se muestra una breve
clasificacin de mtricas de software:
Mtricas de complejidad
Son todas las mtricas de software que definen de una u otra
forma la medicin de la complejidad; Tales como volumen, tamao,
anidaciones, costo (estimacin), agregacin, configuracin, y flujo.
Estas son los puntos crticos de la concepcin, viabilidad, anlisis, y
diseo de software.
Mtricas de calidad
Son todas las mtricas de software que definen de una u otra
forma
la
calidad
estructuracin
del
software;
modularidad,
Tales
como
pruebas,
exactitud,
mantenimiento,
reusabilidad, cohesin del mdulo, acoplamiento del mdulo,

etc. Estas son los puntos crticos en el diseo, codificacin,
pruebas y mantenimiento.
Mtricas de competencia
Son todas las mtricas que intentan valorar o medir
actividades
de
productividad
de
los
programadores
las
o
practicantes con respecto a su certeza, rapidez, eficiencia y

competencia.
Mtricas de desempeo
Corresponden a las mtricas que miden la conducta de mdulos y
sistemas de un software, bajo la supervisin del sistema operativo o
40
hardware. Generalmente tienen que ver con la eficiencia de

ejecucin,
tiempo, almacenamiento, complejidad de algoritmos
computacionales, etc.
Mtricas estilizadas
Son las mtricas de experimentacin y de preferencia; Por ejemplo:
estilo de cdigo, las convenciones denominando de datos, las
limitaciones, etc. No se deben confundir con las mtricas 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, basndose en once
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 McCall

Fuente: Ingeniera de Software de Roger. S. Pressman
Operacin del producto
Correccin
Completitud
41
Consistencia
Trazabilidad
Fiabilidad
Precisin
Consistencia
Tolerancia
Modularidad
Simplicidad
Exactitud
Eficiencia
Eficiencia en ejecucin
Eficiencia en mantenimiento
Integridad
Control de accesos
Facilidad de auditora
Seguridad
Facilidad de uso
Facilidad de operacin
Facilidad de comunicacin
Facilidad de aprendizaje
Formacin
Revisin del producto
Facilidad de mantenimiento
Modularidad
Simplicidad
Consistencia
Concisin
Auto descripcin
Facilidad de prueba
Modularidad
Simplicidad
Auto descripcin
Instrumentacin
Flexibilidad
Auto descripcin
Capacidad de expansin
Generalidad
Modularidad
Transicin del producto
Interoperabilidad
Modularidad
Compatibilidad de comunicacin
Compatibilidad de datos
42
Estandarizacin de los datos

Portabilidad
Auto descripcin
Modularidad
Independencia entre sistema y software
Independencia de hardware
Reusabilidad
Auto descripcin
Generalidad
Modularidad
Independencia entre sistema y software
Independencia de hardware
2.10.5.5
Modelo de estimacin de costos COCOMO
El Modelo Constructivo de Costes o COCOMO20 es un modelo matemtico de base

emprica utilizado para estimacin de costos de software. Incluye tres sub modelos,
cada uno ofrece un nivel de detalle y aproximacin, cada vez mayor, a medida que
avanza el proceso de desarrollo del software: bsico, intermedio y detallado. Este
mtodo Pertenece a la categora de modelos de subestimaciones basados en
estimaciones matemticas. Est orientado a la magnitud del producto final, midiendo
el "tamao" del proyecto, en lneas de cdigo principalmente.
2.10.5.5.1Modelos de estimacin
Las ecuaciones que se utilizan en los tres modelos son:
, en persona-mes
, en meses
, en personas
Donde:
E es el esfuerzo requerido por el proyecto, en persona-mes
20 Del acrnimo en ingls COnstructive COst MOdel

43
Tdev es el tiempo requerido por el proyecto, en meses
P es el nmero de personas requerido por el proyecto
a, b, c y d son constantes con valores definidos en una tabla, segn cada

submodelo.
Kl es la cantidad de lneas de cdigo, en miles.
m(X) Es un multiplicador que depende de 15 atributos.
A la vez, cada submodelo tambin se divide en modos que representan el tipo de

proyecto, y puede ser:
modo orgnico: un pequeo grupo de programadores experimentados

desarrollan software en un entorno familiar. El tamao del software vara
desde unos pocos miles de lneas (tamao pequeo) a unas decenas de miles
(medio).
modo semilibre o semiencajado: corresponde a un esquema intermedio

entre el orgnico y el rgido; el grupo de desarrollo puede incluir una mezcla
de personas experimentadas y no experimentadas.
modo rgido o empotrado: el proyecto tiene fuertes restricciones, que

pueden estar relacionadas con la funcionalidad y/o pueden ser tcnicas. El
problema a resolver es nico y es difcil basarse en la experiencia, puesto que
puede no haberla.
44
2.10.5.5.2Modelo bsico
Se utiliza para obtener una primera aproximacin rpida del esfuerzo, 2 y hace uso de
la siguiente tabla de constantes para calcular distintos aspectos de costes:
MODO
Orgnico
2.40
1.05
2.50
0.38
Semi - Orgnnico
3.00
1.12
2.50
0.35
Empotrado
3.60
1.20
2.50
0.32
Tabla 1. Tabla de constantes para el clculo de distintos aspectos de

costes
(MODELO BSICO)
Fuente: Recuperado de: http://es.wikipedia.org/wiki/COCOMO
Estos valores son para las frmulas:
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 bsico puesto que se
obvian muchas caractersticas del entorno.
2.10.5.5.3Modelo intermedio
Este aade al modelo bsico quince modificadores opcionales para tener en cuenta
en el entorno de trabajo, incrementando as la precisin de la estimacin.
45
Para este ajuste, al resultado de la frmula general se lo multiplica por el coeficiente

surgido de aplicar los atributos que se decidan utilizar.
Los valores de las constantes a reemplazar en la frmula son:
MODO
Orgnico
3.20
1.05
Semi - Orgnico
3.00
1.12
Empotrado
2.80
1.20
Tabla 2. Tabla de constantes para el clculo 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 bsico,
confirmando el papel que representa el tamao; mientras que los coeficientes de los
modos orgnico y rgido han cambiado, para mantener el equilibrio alrededor del
semi libre con respecto al efecto multiplicador de los atributos de coste.
2.10.5.5.4Modelo 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 aplicacin, utilizacin de herramientas de software, etc., tienen
mayor influencia en unas fases que en otras, y adems van variando de una
etapa a otra.
Establece una jerarqua de tres niveles de productos, de forma que los aspectos que
representan gran variacin a bajo nivel, se consideran a nivel mdulo, los que
representan pocas variaciones, a nivel de subsistema; y los restantes son
considerados a nivel sistema.
46
2.10.6 Mantenimiento de software

Es una de las actividades ms comunes en la ingeniera de software y es el proceso
de mejora y optimizacin del software despus de su entrega al usuario final (es
decir; revisin del programa), as como tambin correccin y prevencin de los
defectos.
El mantenimiento de software es tambin 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 despus de la implementacin del software.
2.10.6.1
Tcnicas de mantenimiento de software
Dentro de la ingeniera del software se proporcionan soluciones tcnicas que

permiten abordar el mantenimiento de manera que su impacto en coste dentro del
ciclo de vida sea menor. Las soluciones tcnicas pueden ser de tres tipos:
Ingeniera inversa
Anlisis 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 abstraccin ms elevado.
Reingeniera
Modificacin de un producto software, o de ciertos componentes, usando para
el anlisis del sistema existente tcnicas de ingeniera inversa y, para la etapa
de reconstruccin, herramientas de ingeniera directa, de tal manera que se
oriente este cambio hacia mayores niveles de facilidad en cuanto a
mantenimiento, reutilizacin, comprensin o evolucin.
Reestructuracin del software
Cambio de representacin de un producto software, pero dentro del mismo
nivel de abstraccin.
Estas tres soluciones tcnicas se enmarcan en el ciclo de vida de la siguiente
manera:
21 Acrnimo de las palabras en ingls:System Development Life Cycle, Ciclo de

Vida de Desarrollo de Sistemas
47
Figura 8. Relaciones entre los trminos asociados con la Reingeniera

Fuente: Recuperado de: http://cnx.org/content/m17431/latest/
El objetivo de estas tcnicas es proporcionar mtodos para reconstruir el software, ya
sea reprogramndolo, re documentndolo, redisendolo, o rehaciendo algunas
caractersticas del producto.
48
CAPTULO 3
3. FACTIBILIDAD DEL PROYECTO
3.1 Introduccin
Todos los proyectos bien elaborados seran factibles si se contase con recursos
ilimitados y tiempo infinito. Desafortunadamente, la mayora de los proyectos deben
desarrollarse dentro del presupuesto y lmites de tiempo ajustados para cada uno de
ellos. Esto significa que la evaluacin de la factibilidad 22 del proyecto es una actividad
requerida para todos los proyectos de sistemas de informacin y es potencialmente
una tarea grande.
Esto requiere que se debe evaluar un amplio marco de factores. Tpicamente,
algunos de estos factores sern ms importantes que otros para algunos proyectos y
relativamente insignificantes para otros proyectos. Los factores de factibilidad se
representan por las siguientes categoras:
Econmico
Tcnico
Programtica
Operacional
Legal y contractual
Poltico
3.2 Factibilidad econmica
El propsito de la evaluacin de factibilidad econmica es identificar los beneficios
financieros y costos asociados con el desarrollo del Proyecto propuesto: Sistema de
informacin administrativo caso SAR-FAB ILLIMANI; la factibilidad econmica es a
menudo referido al anlisis 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: automatizacin de trabajos montonos,
22 Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar
a cabo los objetivos o metas sealados.
49
reduccin de errores, reduccin de prdidas 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 dlares o en moneda nacional con certeza.
Siendo de esta forma el sistema tendr los siguientes beneficios tangibles:
Reduccin de costos de operatividad

Reduccin en gastos de reposicin de libretas militares
Ahorro en costos de llamadas en la ejecucin del plan de llamadas
Mejoramiento en planificacin y ejecucin de un operativo
CLCULO DE BENEFICIOS TANGIBLES

Costo x ao
a. Reduccin de costos
Se reduce el costo basndose en Bs. 1500

la adquisicin de materiales de
escritorio (Hojas, flders, tinta,
medios magnticos y otros).
Se reducir a cero los gastos en
b. Reduccin en gastos de reposicin
reposicin de libretas de servicio Bs. 2500

militar errneas.
c. Ahorro en costos de llamadas
Al no tener los datos exactos de

los rescatistas, se llega a gastar Bs. 1440
un monto en ocasiones alto en
llamadas a todo el personal.
d. Mejoramiento en planificacin y Para mayor productividad de un

ejecucin de un operativo
operativo y mejor administracin Bs. 960

en gastos varios (implementos,
alimento, gasolina, etc.)
50
Al no tener una administracin

e. Menos
prdidas
de
materiales adecuada se sufre de prdidas y
logsticos
robos provocados por el mismo

personal o externos.
TOTAL
Bs. 6400
Tabla 3. Tabla de clculo de beneficios tangibles
Los beneficios intangibles son aquellos tems que no pueden ser medidos fcilmente
en dlares o en moneda nacional por falta de veracidad.
Reduccin de prdidas de material logstico
Aumento de control en la parte financiera
BENEFICIOS INTANGIBLES
a. Reduccin
de
prdidas
materiales logsticos
de Habr un mejor control de los

materiales que entran y salen de
seccin
logstica
evitando
prdidas.
b. Aumento de control en la parte Se
financiera
reducir
administracin
la
de
mala
recursos
evitando engao y robos.

Tabla 4. Tabla de clculo de beneficios intangibles
3.2.2 Determinando costos estimados del proyecto

Segn el enfoque en el que se est centrado y similar a los beneficios, un sistema de
informacin puede tener distintos costos, siendo stos denominados costos de
desarrollo.
COSTOS DE DESARROLLO
a. Software
- Anlisis de sistemas y determinacin de A
51
DETERMINAR
requisitos
-
Diseo de sistemas
Desarrollo e implementacin
A
DETERMINAR
Licencia de software Windows 7
DETERMINAR
Licencia
de
software
Visual
Studio
Community 201323
-
Licencia de software SQL Server 2013

Advance Express Edition24
b. Hardware
Se cuenta con el equipo requerido
c. Instalacin
Capacitacin del personal x 4
Bs. 500-1000
Bs. 0
Bs. 0
Bs. 0
Bs. 0
TOTAL
A
DETERMINAR
Tabla 5. Tabla de clculo de costos de desarrollo

Fuente: Elaboracin propia basndose en datos de proyectos
mencionados.
Nota: Los datos de costos son aproximados y en proceso de verificacin.
3.2.3 Modelo para el clculo de costos COCOMO
3.3 Factibilidad tcnica
El propsito de evaluar la factibilidad tcnica es conseguir la habilidad de entender la
organizacin para construir el sistema propuesto. Este anlisis debe incluir una
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 versin Express Edition
con algunas limitaciones.
52
evaluacin del grupo de desarrollo que entiende el posible hardware y software

designado, los ambientes que operan para ser usados, as como el tamao del
sistema y su complejidad.
3.3.1 Hardware y software designados
3.3.1.1
Hardware
Debido a los requerimientos informticos del Grupo SAR-FAB ILLIMANI, la

institucin cuenta con una PC en la cual se implementar el sistema propuesto; la PC
consta de las siguientes caractersticas:
DISPOSITIVOS
CARACTERSTICAS
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 tecnologa 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 caractersticas de una PC del grupo SAR-FAB
ILLIMANI
Fuente: Empresa importadora de accesorios para computadoras
COMPUPARTES
Tambin cuenta con otras tres computadoras tipo torre de menores caractersticas
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 continuacin:
N
1
2
Nombre
Windows 7
SQL Server
Versin
Service Pack 1
Advance 2014
53
Fuente
Microsoft
Microsoft
Utilidad
Sistema Operativo
Manejador de bases de
Express Editon
datos
Visual Studio Community 2013
Microsoft Lenguaje de programacin
Tabla 7. Tabla de requerimientos de software a utilizar
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 sern:
1. Trabajar el sistema propuesto cuando est terminado?
2. Existen barreras importantes para la implantacin 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 rpido de
la informacin en cuanto a los procesos administrativos personales, logsticos y
financieros.
2. Existen barreras importantes para la implantacin del sistema?
No, ya que existe disposicin 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?
S, ya que todo el personal encargado de las distintas secciones necesita de manera
urgente un sistema como el propuesto para la correcta ejecucin de sus actividades.
4. Existe apoyo por parte del Comandante del Grupo SAR?
S, el Comandante del Grupo SAR es el ms interesado en que se implemente este
sistema propuesto.
54
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 estn dispuestos a ser capacitados
para mejorar el manejo adecuado de la informacin sobre los datos personales,
datos logsticos y financieros del Grupo SAR-FAB ILLIMANI.
CAPTULO 4
4. INGENIERA DEL PROYECTO
4.1 Introduccin
El captulo de Ingeniera del Proyecto est orientado al anlisis y diseo del proyecto
y al estudio de los diagramas de casos de uso, secuencia, colaboracin, estado,
componentes y clases; vamos a utilizar el modelo espiral en el desarrollo del mismo.
55
4.2 Anlisis y diseo del sistema

4.2.1 Recopilacin de informacin
Observacin
Se tomaron en cuenta distintos aspectos en el marco de la observacin para la
posterior descripcin del mismo.
Determinacin de lo que se va a observar
o El proceso de registro del personal del grupo SAR, adems 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 observacin
o Por ser una institucin que tiene actividad solamente los das sbados,
se ha venido observando a lo largo de dos meses.
Obtencin de autorizacin
o La autorizacin fue solicitada al inicio del desarrollo del proyecto con
resultados positivos.
Descripcin
De acuerdo a lo observado, podemos plantear las siguientes formas de
procedimiento de acuerdo al rea o seccin:
Seccin personal
o Una vez que todo el personal del grupo SAR llega, se procede al
control de asistencia semanal empezando por el personal ms antiguo.
o El registro se hace en papel de forma manuscrita para luego proceder a
registrar a los voluntarios de segundo ao bajo listado y aporte de un
boliviano. Finalmente se procede a registrar a los postulantes de primer
ao bajo la misma modalidad.
56
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 algn
personal del grupo tiene acumuladas ms de 7 faltas se recurre al
llamado de atencin; si algn personal tiene acumulado ms de 8 faltas
se procede a realizar la baja del mismo, de manera que cambia la
informacin general del personal total, personal efectivo y personal
asistente.
o En caso de un llamado de emergencia y confirmacin del mismo, se
procede a ejecutar el plan de llamadas recurriendo a los datos de los
rescatistas ms capacitados dependiendo del caso (evento adverso);
este proceso se realiza de forma tarda debido a la falta de
actualizacin de los datos o por la existencia de errores en los mismos.
o Finalmente, la seccin personal es la encargada de elevar informes
(partes25) semanales para enviarlos al Comando General de la Fuerza
Area.
Seccin logstica
o Esta seccin 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 extravo de los
equipos.
o Una vez que el oficial de servicio, el Mayor Crdenas, da la orden de
salir de operativo, el encargado hace una lista de solicitud de materiales
para que el encargado de seccin logstica 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
25 Informes semanales del personal de la unidad en el mbito militar
57
perfectas condiciones de operatividad para su posterior registro en

inventarios de seccin.
Seccin finanzas
o Esta seccin coordina cada fin de semana con seccin personal para
registrar y guardar datos de aportes voluntarios de todo el personal del
grupo SAR.
o Tambin est encargada de la venta de uniformes y accesorios que los
rescatistas adquieren a lo largo del ao; as mismo realiza contratos
con entidades externas de financiamiento, banca, confeccin y otros.
Por otra parte, esta seccin se encarga de financiar gastos en materiales y gastos de
utilidad y mantenimiento de equipos y vehculos.
4.2.1.1
Entrevistas
Una entrevista para recabar informacin es una conversacin dirigida con un

propsito especfico 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 recopilacin de informacin se elaboraron
luego de la observacin, 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 recopilacin de informacin efectiva se ha realizado un cuestionario de

nueve preguntas, el cual fue impartido al comandante del Grupo SAR y a los jefes de
seccin personal, seccin logstica y seccin finanzas obteniendo un resultado
satisfactorio [ver ANEXO C].
26 Kendall K., Kendall J. (2005), Anlisis y diseo de sistemas: Anlisis de los

requerimientos de informacin (Cap. 2, p. 90). Mxico: McGraw-Hill
Latinoamericana
58
4.3.1.3.
Solicitud del cliente
Luego de hacer una evaluacin profunda y basndonos en todo el anlisis y

recopilacin de informacin, conjuntamente el comandante del grupo SAR y los
rescatistas encargados de las secciones se tienen las solicitudes detalladas a
continuacin:
El manejo del sistema y la interfaz de usuario debe ser sumamente aplicable y
de fcil utilizacin debido a que no todos los usuarios (rescatistas) tienen
grandes conocimientos de informtica y computacin.
El sistema debe resolver el principal problema de prdida y manejo
inadecuado de informacin de las distintas secciones que contempla el
sistema (secciones: personal, logstica, 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 ms efectivo el plan de llamadas y colaborar en el
mbito de toma de decisiones en cuanto a la eleccin de los rescatistas ms
capacitados para un operativo de emergencia.
4.2.1.3
Determinacin de requerimientos
Vamos a enfocarnos en dos principios muy importantes:

Requisitos bsicos
o Cules son los procesos bsicos?
Los procesos bsicos estn basados de acuerdo al flujo de informacin
en las 3 secciones; esto conlleva al registro, guardado y recopilacin
correcta de los datos en cada seccin.
o Qu datos se utilizan y producen durante este proceso?
Los datos utilizados estn ligados a:
Seccin personal: Datos de todo el personal del Grupo SAR.
Seccin logstica: Datos de inventarios, materiales y equipos.
Seccin finanzas: Datos econmicos, datos de gastos y

beneficios.
59
o Cules son los lmites impuestos por tiempo y cantidad de trabajo?
Lmites de tiempo: Debido a que la actividad se realiza solo los

das sbados y en ocasiones algn da de la semana, el limitante
de tiempo se ve cada fin de semana por la tardanza en
recopilacin de la informacin.
Lmites de cantidad de trabajo: El trabajo es arduo y tardo con el

tipo de manejo de informacin actual, esto se ve afectado por la
misma limitante de tiempo.
o Qu controles de rendimiento se utilizan?

An no se realiza un control de rendimiento debido al manejo ambiguo
de la informacin, esta posibilidad queda nula.
Actividades
o Cul es el propsito de estas actividades?
El principal propsito es el correcto registro de datos de las tres secciones,
lo cual ayudar a agilizar todas las actividades que conllevan el proceso de
recopilacin de informacin (plan de llamadas, registro de faltas, planillas,
etc.)
o Qu es lo que se realiza?
En todos los casos, ya sea seccin personal, logstica o finanzas, los
procesos a realizarse son: la recoleccin, verificado, evaluacin y
guardado de los datos.
o Dnde se realizan?
Todos los procesos se lo realizan dentro del grupo SAR por tratarse de
informacin netamente interna. A excepcin del parte semanal que se
debe reportar al comando y los datos de los rescatistas que recibirn la
libreta de servicio militar, todos los datos se quedan en el grupo.
o Quines lo ejecutan?
Todos los procesos lo ejecutan cada encargado de seccin (jefe de
seccin) con la ayuda de sus colaboradores siempre bajo el mando del
comandante del grupo SAR.
60
o Cunto tiempo estimado consumen?

En cuanto a recoleccin 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 verificacin cuando existe un
operativo es moroso debido al tipo de manejo de informacin. 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 das sbados a
excepcin de algn operativo que pueda surgir en el transcurso de la
semana. Por tanto todo el proceso de manejo de informacin se lo
realiza sbado a sbado.
o Quin utiliza la informacin resultante?
Toda la informacin resultante la utilizan el comandante del grupo SAR
y los encargados de las 3 secciones que implica el proyecto; toda la
informacin est relacionada tambin con las sub secciones que no
implica al proyecto (seccin instruccin, operaciones, mdicas y
transportes).
4.2.2 Diseo del sistema

4.2.2.1
Diagramas de contexto
Diagrama de contexto Seccin personal
61
Figura 9. Diagrama de contexto de seccin personal Grupo SAR-FAB

ILLIMANI
Diagrama de contexto Seccin logstica
62
Figura 10. Diagrama de contexto de seccin logstica Grupo SAR-FAB

ILLIMANI
Diagrama de contexto Seccin finanzas
Figura 11. Diagrama de contexto de seccin logstica Grupo SAR-FAB

ILLIMANI
63
4.2.2.2
Casos de uso
SECCIN PERSONAL
CASO DE USO 1: ESCENARIO GENERAL
Figura 12. Caso de uso: Escenario general

64
CASO DE USO 2: GESTIN DE DATOS DEL PERSONAL
Figura 13. Caso de uso: Gestin de datos del personal

CASO DE USO 3: AGREGACIN DATOS
65
Figura 14. Caso de uso: Agregacin de datos

CASO DE USO 4: LISTADO DE DATOS
Figura 15. Caso de uso: Listado de datos

CASO DE USO 5: MODIFICACIN DE DATOS
66
Figura 16. Caso de uso: Modificacin de datos

CASO DE USO 6: ELIMINACIN DE DATOS
Figura 17. Caso de uso: Eliminacin de datos

67
CASO DE USO 7: REGISTRO DE ASISTENCIA A INSTRUCCIN
Figura 18. Caso de uso: Registro de asistencia a instruccin

CASO DE USO 8: GESTIN DE PERMISOS
68
Figura 19. Caso de uso: Gestin de permisos

CASO DE USO 9: GENERACIN DE REPORTES
Figura 19. Caso de uso: Generacin de reportes

69
ANEXOS
ANEXO A
RBOL DE PROBLEMAS
EFECTO
S
Demora en entrega de
libretas de servicio
militar
Prdida de datos e
informacin personal de
los postulantes,
voluntarios y rescatistas
Lentitud en la
ejecucin del plan de
llamadas
No se encuentran datos
e informacin personal
de manera oportuna
Robos y prdida de
los materiales
Registros errneos en
reportes de asistencia
semanal y asistencia al
servicio de guardia.
utilizados
FALTA DE SISTEMATIZACIN Y
CARENCIA DE INFORMACIN
OPORTUNA Y FIABLE
Manejo inadecuado de la
informacin de los
postulantes, voluntarios y
rescatistas
CAUS
AS
Desorganizacin en el
proceso de recopilacin,
almacenaje y
recuperacin de datos
de los rescatistas
Deficiente manejo y
registro del control de
asistencia semanal
ANEXO B
RBOL DE OBJETIVOS
EFECTO
S
Registro manual de
inventarios y
materiales
logsticos
Eficiencia en el
proceso del
plan de
llamadas
Agilizacin de
entregas de las
libretas de
servicio militar
Obtencin
instantnea, fcil y
precisa de datos
Mejor
control de
gastos
Confiabilidad en la
informacin
obtenida
Planillas y
reportes de
asistencias
precisos y
concisos
Existen reportes
econmicos
precisos y planillas
financieras
exactas
Evita robos y
extravos de
materiales
DESARROLLAR E IMPLEMENTAR UN
SISTEMA DE INFORMACIN QUE
PERMITA AL USUARIO CONTAR CON
INFORMACIN OPORTUNA Y FIABLE
CAUS
AS
Organizar adecuadamente la
informacin personal de cada
postulante, voluntario y
rescatista
Desarrollar un sistema que

permita el registro, control y
seguimiento exacto de la
asistencia semanal de los
Sistematizar el
proceso de
recopilacin,
almacenaje y
recuperacin de los
datos logsticos e
Organizar
adecuadamente la
informacin financiera
ANEXO C
CUESTIONARIO
1. Existe algn medio automatizado de recoleccin de informacin en la seccin a su cargo?
SI (
NO (
Por qu?
2. Respecto al manejo de informacin de los datos que maneja dentro su seccin, se tuvo
alguna vez algn tipo de problema con la recopilacin de informacin de los mismos?
SI ( )
NO ( )
Por qu?
3. Cree usted necesario que se deba implantar un sistema para el buen manejo de la
informacin dentro del grupo SAR y sus sub secciones?
SI ( )
NO ( )
Por qu?
4. Ya sea en seccin personal, logstica o finanzas, Existe algn aspecto donde se vea algn
problema por la falta de organizacin de informacin?
SI ( )
NO ( )
Cul(es) es(son)?
5. Los registros y el control de los datos de la seccin a la que pertenece son::

Intiles
a veces tiles
tiles
muy tiles
6. De acuerdo a su opinin, crear un sistema automatizado para el grupo SAR sera:
De cierta ayuda
til
muy til
indispensable
7. A su criterio, la recopilacin de informacin para efectivizar el plan de llamadas es:
Fcil y accesible
difcil y complicada
no me quejo
necesitamos ayuda
8. Usted cree que debe renovar su sistema de manejo de informacin dentro de la seccin a
la cual pertenece?
Nunca
de aqu a un tiempo
lo ms pronto posible
9. De acuerdo a su criterio, estara de acuerdo con que se le proporcione ayuda en su
seccin en el mbito de actualizacin tecnolgica para con en el manejo de informacin?
SI ( )
NO ( )
Por qu?
ANEXO D
La librera MahApps.Metro se instala dentro de la aplicacin 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 librera para comenzar a trabajar
ANEXO E
CAPTURA DE PANTALLA: LOGIN DE USUARIO

Ejemplo Proyecto

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ejemplo Proyecto

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD SALESIANA DE BOLIVIA

SISTEMA DE INFORMACIN ADMINISTRATIVO

: GONZALO JHAMIL MUJICA PACOSILLO

: LIC. GLADYS FRANCISCA CHUQUIMIA MAMANI

: LIC. CARMEN ROSA MOLLINEDO

2.5.1 DEFINICIONES DE SOFTWARE

2.10.6.1 Tcnicas de mantenimiento de software

3. FACTIBILIDAD DEL PROYECTO

4. INGENIERA DEL PROYECTO

El sistema de informacin administrativa SAR-FAB ILLIMANI, manejar datos

3 Rescatista Comando es el puesto jerrquico militar ms alto dentro de los

Figura 1. Estructura organizacional del grupo SAR-FAB ILLIMANI

1.3 Planteamiento del problema

informacin semi manual provoca registros

errneos en reportes de asistencia semanal y asistencia al

voluntarios y rescatistas son llevados de forma

manuscrita lo que provoca reportes econmicos falsos. Los

adems de informacin pertinente de recursos financieros,

para as mejorar de manera eficaz la administracin de informacin en la institucin

Desarrollar un sistema que permita el registro, control y seguimiento exacto de

1.5.3 Justificacin econmica

Los aportes acadmicos van delimitados:

Los aportes institucionales se vern reflejados de la siguiente manera:

Disminucin de prdidas y extravos de materiales de la institucin y gastos

Para el desarrollo del proyecto se utilizan las siguientes metodologas de

Para el desarrollo del proyecto se utilizan las siguientes tcnicas:

En el siguiente captulo se dar a conocer los conceptos bsicos, herramientas y

Figura 2. Representacin esquemtica de un sistema

Conjunto de cosas que relacionadas entre s ordenadamente contribuyen a

Conjunto de cosas que ordenadamente relacionadas entre s, contribuyen a

Para que un sistema pueda proporcionar informacin correcta, en el momento

Administrativos: Es la estructura orgnica de objetivos, lineamientos,

Sistemas de informacin administrativos

Estos sistemas de informacin manejan los datos orientados a la toma de decisiones

Sistemas de informacin organizacionales

Es la clasificacin de los sistemas de informacin en relacin a las funciones

funcionalidad deseada y el rendimiento cuando se ejecute

Figura 3. Representacin esquemtica de un sistema

reas (negocios, investigacin cientfica, medicina, produccin, logstica, banca,

Nosotros utilizaremos diagramas de casos de uso y diagramas de secuencia.

indicaciones en qu condiciones puede fallar una aplicacin y que pueden

pequea parte de este trabajo consiste en arreglar errores, o bugs12. La mayor

2.6.4 Modelo RUP (Rational Unified Process)

Figura 4. Tabla de esfuerzos en actividades modelo RUP

Es un conjunto o disposicin de procedimientos o programas relacionados de

Debe presentarse y entenderse el dominio de la informacin de un problema.

conseguir este objetivo, un sistema basado en computadoras hace uso de seis

Objetivos del anlisis

Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en

responsabilidad legal en que se podra incurrir al desarrollar el sistema.

caractersticas del sistema. El anlisis de costos-beneficios es una fase muy

e ingeniera humana. Describe la funcin y

rendimiento de un sistema basado en computadoras y las dificultades que

2.7.2 Diseo de sistemas

El diseo de sistemas define el proceso de aplicar ciertas tcnicas y principios con el

Etapas del diseo de sistemas

La etapa del diseo de sistemas encierra cuatro fases:

Herramientas para el diseo de sistemas

Las herramientas para el diseo de sistemas nos apoyan en el proceso de

Apoyan la fase de la evaluacin de un sistema o de partes del mismo contra

16 Del acrnimo Object Management Group, es un consorcio dedicado al cuidado y

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o

17 Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de