Texto Análisis I - 2013

UATF
TEXTO GUÍA
ANÁLISIS DE SISTEMAS I
M.Sc. Lic. Anny Mercado

Algarañaz
INGENIERÍA DE SISTEMAS
ANÁLISIS DE SISTEMAS I TEXTO GUÍA
INTRODUCCIÓN
El software es uno de los productos de la ingeniería que más ha evolucionado en muy poco tiempo,
transitando por el software empírico o artesanal hasta llegar al software desarrollado bajo los
principios y herramientas de la ingeniería del software.
Sin embargo, dentro de estos cambios, las personas encargadas de la construcción de software se han
enfrentado a problemas muy comunes: unos debido a la exigencia cada vez mayor en la capacidad de
resultados del software por el permanente cambio de condiciones, lo que aumenta su complejidad y
obsolescencia; y otros, debido a la carencia de las herramientas adecuadas y estándares de tipo
organizacional encaminados al mejoramiento de los procesos en el desarrollo del software.
Una necesidad sentida en este medio es el hecho de que los productos de software deben ser
desarrollados con base en la implantación de estándares mundiales, modelos , sistemas métricos,
capacitación del recurso humano y otros principios y técnicas de la ingeniería software que
garanticen la producción de software de calidady competitividad a nivel local e internacional.
Con el acelerado avance tecnológico de la información, la cantidad y la complejidad de los productos

de software se están incrementando considerablemente, así como la exigencia en su funcionalidad y
confiabilidad; es por esto que la calidad y la productividad se están convirtiendo en las grandes
preocupaciones tanto de gestores como para desarrolladores de software, considerando como una
dificultad adicional la relacionada con la satisfacción total y la gran demanda y exigencias por parte de
los clientes, en este sentido resulta importante el poder entender en su totalidad el papel importante
que juega el análisis y diseño de sistemas información.
A través del presente documento se pretende brindar una orientación básica/didáctica en cuanto a los
criterios científicos-técnicos para la elaboración y desarrollo de sistemas de información, que como
tales, deben cumplir con los requerimientos y condiciones conceptuales y metodológicas que permitan
la validez científica de los trabajos en este área, desarrollando puntualmente los contenidos mínimos
necesarios en la elaboración de documento, describiendo brevemente y con la mayor claridad posible
lo que debe incluirse en el mismo, contribuyendo al desarrollo de los software de calidad que pueda
satisfacer en su totalidad las necesidades de los clientes, así como la cimentación académica durante el
curso de la carrera y la elaboración de la tesis o proyecto de grado orientados al desarrollo de software,
así como para la orientación de la investigación en la vida profesional.
UATF M.Sc. Lic. Anny Mercado Algarañaz -1-

CAPITULO I
INTRODUCCIÓN AL ANÁLSIS DE SISTEMAS
“Es necesario ser disciplinado y sistemático para desarrollar un buen sistema”

A. MERCADO
1.1. INTRODUCCIÓN
Desarrollar un sistema en la actualidad, implica un conjunto de procedimientos necesarios para poder

lograr la obtención de un software de calidad, sin embargo es importante considerar los siguientes
aspectos:
 Un proyecto software no consiste sólo en programar.
 Necesitamos saber cuáles son las necesidades del cliente.
o Identificar los requisitos, anotarlos, analizarlos, validarlos.
 Necesitamos diseñar una solución, y hacer “los planos” del software:
o Diseño de la arquitectura, detallado, de datos, …
 Hay que asegurarse de que el software funciona:
o Pruebas de unidad (a nivel de método y clase), de integración, del sistema, de
aceptación, etc.
 Hay que mantener el software.
o Documentación (de cada una de las fases), coherencia entre los productos de las
distintas fases (ej. código vs. diseños).

1.2. ANÁLISIS
El análisis es la distinción y separación completa de las partes de un todo hasta llegar a conocer sus
principios o elementos, sus características representativas, así como sus interrelaciones.
Es el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y empleo de la
información para recomendar mejoras al sistema o crear un sistema para una nueva necesidad.
3.1.1. PRINCIPIOS DEL ANÁLISIS
• En general durante la etapa de análisis se deben especificar procesos, datos y control.
• Etimológicamente análisis significa “descomponer”, debe de responder a la pregunta ¿Qué?

del desarrollo de software.
ANÁLISIS
Asimismo, el análisis presenta los siguientes principios:
1º
2º
3º
4º

3.1.2. El ANALISTA DE SISTEMAS
El analista de sistemas es aquel que tiene como tarea principal, la de dar soporte a las actividades de
un negocio, o desarrollar un producto que pueda venderse para generar beneficios.
1.1.1.1. FUNCIONES DEL ANALISTA DE SISTEMAS
El analista de sistemas juega un papel primordial e importante en el desarrollo de sistemas ya que

dependerá del él el éxito del proyecto. A continuación se presenta las principales funciones del analista
de sistemas:
Edward Yourdon en su libro Análisis Estructurado Moderno, menciona que el analista de sistemas
desempeña varios papeles, tales como Arqueólogo, Innovador, Mediador y jefe de proyecto.
Arqueólogo, ya que el analista descubre detalles y documenta la política de un negocio.
Innovador, ya que con sus conocimientos de la tecnología de las computadoras, ayuda al usuario a
explorar aplicaciones novedosas y útiles, así como mercados radicalmente innovadores.
Mediador, debido a que usualmente se encuentra en medio de usuarios, administradores,

programadores, auditores y otros participantes, los cuales por lo general están en desacuerdo entre si y
sobre los cuales debe imponer su propia opinión y obtener el consenso, en base al uso de la diplomacia
y la negociación.
Finalmente Yourdon, también nos habla del rol de Jefe de Proyecto, dado que el analista suele tener
más experiencia que los programadores dado que asigna a los mismos antes de que ellos empiecen a
trabajar. (Yourdon E. Pag. 68)
La siguiente figura muestra de manera más general las funciones del analista de sistemas:

3.1.3. ROLES DE L ANALISTA DE SISTEMAS

Kendall & Kendall en su libro Análisis y diseño de sistemas, muestra básicamente tres roles del analista
de sistemas, el de Consultor, Agente de Cambio y Experto en Soporte Técnico, los mismo que se
describen en las siguientes líneas.
1.1.1.2. CONSULTOR
Este rol principalmente lo tiene el analista cuando es contratado de manera específica para enfrentar
los problemas de sistemas de información de una institución u organización. Esta contratación se
puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de la cual
carecen los demás miembros de una organización. También se puede traducir en una desventaja
porque alguien externo nunca conocerá la verdadera cultura organizacional. (Kendall & Kendall 2005, pag. 7)
1.1.1.3. EXPERTO EN SOPORTE TÉCNICO
En este rol el analista recurre a su experiencia profesional con el hardware y software de cómputo y al
uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de
sistemas, sino más bien la realización de pequeñas modificaciones o la toma de decisiones que se
circunscriben a un solo departamento. (Kendall & Kendall 2005, pag. 7)
1.1.1.4. AGENTE DE CAMBIO
“El rol más completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de
cambio, ya sea interno o externo para la empresa. Como analista, usted es un agente de cambio si
desempeña cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo de sistemas y
está presente en la empresa durante un largo periodo (de dos semanas a más de un año). Un agente de
cambio se puede definir como alguien que sirve de catalizador para el cambio, desarrolla un plan para
el cambio y coopera con los demás para facilitar el cambio.” (Kendall & Kendall 2005, pag. 8)

1.3. DISEÑO
El diseño es la primera parte del desarrollo de cualquier proyecto, etimológicamente significa

componer, por lo que se obtiene la solución que habrá de implantarse. Todas las cosas siempre tienen
primero una creación mental.
El Diseño como verbo “diseñar” se refiere al proceso de creación y desarrollo para producir un nuevo
objeto o medio de comunicación (objeto, proceso, servicio, conocimiento o entorno) para uso humano.
Como sustantivo, el diseño se refiere al plan final o proposición determinada fruto del proceso de
diseñar (dibujo, proyecto, maqueta, plano o descripción técnica), o (más popularmente) al resultado
de poner ese plan final en práctica (la imagen o el objeto producido).
Otra definición menciona que el diseño es el proceso de planificar, reemplazar o

complementar un sistema organizacional existente. Antes de llevar a cabo esta planeación es
necesario comprender, en su totalidad, el viejo sistema y determinar la mejor forma en que se
pueden, si es posible, utilizar recursos tecnológicos para incorporar eficiencia.
Finalmente es importante mencionar que Diseñar requiere principalmente consideraciones

funcionales y estéticas.
3.1.4. PRINCIPIOS DEL DISEÑO
 El diseño establece ¿cómo? , como alcanzar el objetivo

 Etimológicamente significa componer, por lo que se obtiene la solución que habrá de
implantarse.
 Todas las cosas siempre tienen primero una creación mental.
DISEÑO
1.4. SISTEMA
Ferdinand de Saussure (1931): “Sistema es una totalidad organizada, hecha de elementos solidarios
que no pueden ser definidos más que los unos con relación a los otros en función de su lugar en esa
totalidad.”

IEEE Standard Dictionary of Electrical and Electronic Terms define: “Sistema es un todo integrado,
aunque compuesto de estructuras diversas, interactuantes y especializadas. Cualquier sistema tiene un
número de objetivos, y los pesos asignados a cada uno de ellos pueden variar ampliamente de un
sistema a otro. Un sistema ejecuta una función imposible de realizar por una cualquiera de las partes
individuales.”
La Real Academia Española lo define como: “Sistema es un conjunto de cosas que ordenadamente
relacionadas entre sí contribuyen a un determinado objetivo.”
Estándar X3.12-1970 (ANSI), Estándar 2382/V, VI (ISO) Vocabulary forInformation Processing: “Sistema
es una colección organizada de hombres, máquinas y métodos necesaria para cumplir un objetivo
específico.“
Resumiendo, de las definiciones se pueden extraer unos aspectos fundamentales del concepto
Sistema:
 La existencia de elementos diversos e interconectados.
 El carácter de unidad global del conjunto.
 La existencia de objetivos asociados al mismo en contribución al logro de un objetivo

común que persigue el sistema.
 La integración del conjunto en un entorno.
1.4.1. ELEMENTOS DE UN SISTEMA
Entre los elementos que componen un sistema se tienen:

 Los componentes del sistema.
 Las relaciones entre ellos, que determinan la estructura del sistema.
 El objetivo del sistema.
 El entorno del sistema: aquello que lo rodea, dentro del cual está ubicado.
 Los límites del sistema: la frontera entre lo que es el sistema y lo que constituye el entorno.
Como se muestra en la siguiente imagen todo sistema cuenta con un conjunto de elementos que lo
conforman.
Elementos de un sistema
Fuente: http://es.scribd.com/doc/2620890/Sistemas-de-Informacion

1.5. SISTEMA DE INFORMACIÓN
Un Sistema de Información es un conjunto de elementos interrelacionados entre sí que recolectan,

almacenan, procesan y distribuyen información para el apoyo en la toma de decisiones, la
administración y el control en una organización.
“Un conjunto formal de procesos que, operando sobre una colección de datos estructurada según las
necesidades de la empresa, recopilan, elaboran y distribuyen la información (o parte de ella)
necesaria para las operaciones de dicha empresa y para las actividades de dirección y control
correspondientes (decisiones) para desempeñar su actividad de acuerdo a su estrategia de negocio.”
(Andreu et al. 91)
Otras definiciones de SI enfatizan que el objetivo es proporcionar información de calidad:
“El objetivo del SI es ayudar al desempeño de las actividades en todos los niveles de la
organización, mediante el suministro de la información adecuada, con la calidad suficiente, a la
persona apropiada, en el momento y lugar oportunos, y con el formato más útil para el
receptor.”
1.6. COMPONENTES DE UN SISTEMA DE INFORMACION
Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos
fundamentales:
Elementos de un Sistema de Información
Fuente:http://es.wikipedia.org

1.7. LOS SISTEMA DE INFORMACION AUTOMATIZADOS

Un si no necesita, para existir, estar obligatoriamente basado en el uso de ordenadores. El si existe
siempre, esté mecanizado o no.
La aplicación del ordenador a los si produce los sistemas de información basados en computadora o
sistemas de información automatizados (sia).
1.
Sistema Informático de
Soporte
1.8. COMPONENTES DE UN SISTEMA DE INFORMACIÓN AUTOMATIZADO
Todo sistema cuenta con los siguientes elementos que lo componen:

Asimismo es importante mencionar que en sistemas informáticos se deben observar ciertos principios:
 Debe presentarse y entenderse el dominio de la información de un problema.

 Define las funciones que debe realizar el Software.
 Representa el comportamiento del software a consecuencias de acontecimientos externos.
 Divide en forma jerárquica los modelos que representan la información, funciones y
comportamiento.
1.8.1. TIPOS DE SISTEMAS DE INFORMACIÓN
Existen varios tipos de Sistemas de Información, desde el punto de vista administrativo éstos se pueden
clasificar en una forma de pirámide.
UATF M.Sc. Lic. Anny Mercado Algarañaz - 10 -

3.1.5. Nivel operativo
Se utilizan para realizar un seguimiento de las actividades y operaciones básicas de una organización.
Sistema de Procesamiento de Transacciones (TPS)
Recolectan, almacenan, modifican y recuperan la información generada por las transacciones

Producidas en una organización. Si durante una transacción se produce un error, el TPS debe ser capaz
de deshacer las operaciones realizadas hasta ese momento. Es muy útil para el procesamiento de
transacciones on-line.
En esencia presentan:
• Entrada: transacciones, eventos

• Proceso: actualización Aplicaciones típicas TPS
• Salida: informes detallados
• Usuarios: personal nivel operativo
Ejemplo: Facturación
ÁREA DE VENTAS Y MARKETING
• Gestión de Ventas
• Investigación de Mercado
o PRINCIPALES FUNCIONES • Promoción
• Precios
• Nuevos Productos
• SI de Órdenes de Ventas
• SI de Investigación
o PRINCIPALES APLICACIONES:
Comercial
• SI de Gestión de Precios.
ÁREA DE OPERACIONES
• Programación
• Compras
o PRINCIPALES FUNCIONES • Logística
• Ingeniería
• Operaciones
• SI de Planificación de Recursos Materiales

o PRINCIPALES APLICACIONES • SI de Control de Órdenes de Compras
• Sistemas de Control de Calidad

ÁREA DE FINANZAS Y CONTABILIDAD
• Presupuesto
o PRINCIPALES FUNCIONES • Contabilidad
• Facturación
• Contabilidad de Costes
• SI de Contabilidad General
o PRINCIPALES APLICACIONES • Cuentas a Cobrar / Pagar,
• Presupuesto
• Gestión de Tesorería
ÁREA DE RECURSOS HUMANOS
• Registros de personal
• Retribuciones
o PRINCIPALES FUNCIONES • Complementos
• Relaciones Laborales
• Formación
• •SI de
SI Nómina
de Contabilidad General
o PRINCIPALES APLICACIONES • •Registro Personal
Cuentas a Cobrar / Pagar,
• •Complementos
Presupuesto
• •Sistema de Gestión
Gestión de Carreras
de Tesorería
Finalmente, a continuación se muestra el funcionamiento de un, la siguiente figura muestra de manera

grafica este tipo de sistemas:
FUENTE:http://es.wikipedia.org/wiki/Sistema_de_procesamiento_de_transacciones

3.1.6. Nivel del conocimiento
Se utilizan para el mejoramiento de la calidad de los servicios de la organización y aporte de nuevos

conocimientos, además de incrementar la productividad de los usuarios del sistema.
Sistemas de Conocimiento (KWS)
Auxilian a los trabajadores en la creación e integración de nuevo conocimiento en la organización.

Están diseñados para aumentar la productividad de los trabajadores.
Ejemplo: aplicaciones como Photoshop con la que diseñadores pueden crear arte publicitario.
En esencia presentan:
Entrada: especificaciones de diseño
Proceso: modelización
Salida: diseños, gráficos

Usuarios: staff técnico
Ejemplo: Estación de trabajo de diseño asistido por el ordenador:
FUENTE:http://www.infovis.net/printMag.php?lang=1&num=176
Sistemas de Automatización de Oficina (OAS)
Aplicaciones destinadas a ayudar al trabajo diario del administrativo de una organización, forman parte
de este tipo de software los procesadores de textos, las hojas de cálculo, los editores de
presentaciones, los clientes de correo electrónico, etc.
Objetivo: oficina sin papeles
Rediseño de los flujos de trabajo
En esencia realizan: Software integrado
Diseño ergonómico
Espacio de trabajo limpio y agradable
Ejemplo: Microsoft Office, presentaciones gráficas:

FUENTE:http://blog.sage.es/innovacion-tecnologia/opciones-para-trabajar-con-la-ofimatica-en-la-nube/
3.1.7. Nivel Administrativo
Son utilizados por los administradores de nivel medio en la toma de decisiones. Tratan y comparan
resultados relevantes para la compañía, y estudian sus trayectorias.
Sistemas de Información Gerencial (MIS)
Son el resultado de interacción colaborativa entre personas, tecnologías y procedimientos. Apoyan a

nivel administrativo entregando información útil para el planteamiento, control y toma de decisiones.
En esencia utilizan a nivel táctico y presentan:
Entrada: elevado volumen de datos

Procesos: modelos simples
Salida: informes resumen
Usuarios: mandos intermedios
Ejemplo:
• Sistema para Presupuesto Anual.

• Sistema que reúna información de sistemas de información de nivel productivo sobre los
productos (pedidos, costos y gastos) y genere reportes para la toma de decisiones. La mayoría
de los informes para control administrativo están basados en resúmenes de las transacciones.
• Diseñados para decisiones
estructuradas y semiestructuradas
• Orientados a informes de control
• Datos pasados y presentes
• Orientación hacia información
interna
• Proceso de diseño lento y costoso

Sistemas de Apoyo a la Toma de Decisiones (DDS)
Herramienta para realizar el análisis de las diferentes variables de un negocio con la finalidad de apoyar
el proceso de toma de decisiones. Su principal característica es la capacidad de análisis
multidimensional (OLAP) que permite profundizar en la información hasta llegar a un alto nivel de
detalle, analizar datos desde diferentes perspectivas, realizar proyecciones de información para
pronosticar lo que puede ocurrir en el futuro, análisis de tendencias, análisis prospectivo, etc.
Entre sus características mas comunes se tienen:
 Son flexibles, adaptables, rápidos

 El usuario controla las entradas y salidas
 No requiere programación profesional
 Apoya procesos de decisión
 Utilizan herramientas sofisticadas de modelización
En esencia permiten:
 Nivel táctico
 Entrada: poco volumen de datos
 Procesos interactivos
 Salida: análisis de decisiones
 Usuarios: profesionales, staff
Ejemplo: Análisis Coste Contratos. El sistema implantado por la New York State Office of
General Services que permite que los ejecutivos verifiquen el estado por programa,
comparando presupuestos y gastos y mostrando el gasto estimado hasta el final del año fiscal.
El software IBM® Lotus Notes®, combina las capacidades de e-mail, calendario y programación
con una poderosa plataforma de desktop para aplicaciones colaborativas, Facilita la toma de
decisiones a través de la colaboración, incorporando conciencia, mensajería instantánea e
integración de conferencias Web (opcional), entre otros:
FUENTE:http://apoyotomadedecisiones.blogspot.com/2010_01_01_archive.html

Sistemas Expertos (SE)
Es una aplicación informática capaz de solucionar un conjunto de problemas que exigen un gran
conocimiento sobre un determinado tema. Emulan el comportamiento de un experto en un dominio
concreto y en ocasiones son usados por éstos. Con los sistemas expertos se busca una mejor calidad y
rapidez en las respuestas dando así lugar a una mejora de la productividad del experto. Estos sistemas,
realizan tareas que normalmente haría un humano.
Ejemplo: un sistema MRP (Manufacturing Resoure Planning) diseñado para reducir el desperdicio en el
proceso productivo. Sistema experto para la aprobación de préstamos o Sistema Experto de
Diagnostico medico, como es el caso del siguiente ejemplo:
FUENTE: http://jane15cl.wordpress.com/2011/04/04/sistema-experto-para-el-diagnostico-de-la-tuberculosis/
3.1.8. Nivel estratégico
Los sistemas de información estratégicos pueden modificar objetivos, operaciones, productos, servicios, entorno...
...Para el logro de ventajas competitivas
Están basados en los resultados estratégicos a largo plazo de la compañía, son útiles para poder hacer
frente a los impactos producidos por cambios en los negocios.
Sistemas de Soporte Gerencial (SSG)
Trabajan con información interna y externa a la organización y están diseñados para abordar la toma
de decisiones que requieren juicio, evaluación y comprensión.

Entre sus características más comunes se tienen:
 Están diseñados para la alta dirección

 Diseñados para el individuo
 Conecta a la dirección con los demás niveles
 Costosos de mantener actualizados
 Se necesita un amplio staff(Conjunto de recursos que asesoran y colaboran con un
componente específico dentro de una organización) de apoyo.
En esencia permiten:
Entrada: datos agregados

Proceso: interactivo
Salida: proyecciones
Usuarios: alta dirección
Ejemplo: Plan Estratégico a 5 años. Un ejecutivo puede utilizar el sistema para conocer las ventas
por país, rango etáreo y línea de producto y, además, obtener el crecimiento esperado del segmento
para los próximos 5 años en bases de datos externas. Asimismo, este tipo de sistemas Generalmente
se presenta en forma de informes periódicos, informes especiales, y salidas de simulaciones temáticas.
FUENTE:http://es.wikipedia.org/wiki/Sistemas_de_informaci%C3%B3n_ejecutiva
Sistemas de Planificación de Recursos Empresariales (ERP)
Los ERP son sistemas que integran y manejan todo lo asociado con las operaciones de producción y
aspectos de distribución y que son necesarios para el funcionamiento de los procesos de negocio de
una organización, es decir, permiten la disponibilidad de toda la información para todo el mundo todo
el tiempo. Son también llamados back office ya que no se involucra directamente a clientes y público
general. Las áreas que generalmente manejan los ERP son:
Producción - Logística - Distribución - Inventario - Envíos - Facturas - Contabilidad

Sin embargo el ERP también puede integrar otras áreas de un negocio como:

Ventas
Despachos
Pagos
Administración de inventarios
Calidad de la administración
Administración de recursos
humanos
Los sistemas ERP están diseñados para incrementar la eficiencia en las operaciones de la compañía que
lo utilice, además tiene la capacidad de adaptarse a las necesidades particulares de cada negocio y se
aproveche al máximo el trabajo de consultoría durante la implantación para mejorar los procesos
actuales de trabajo. Si el cliente desea organizarse mejor estos sistemas son un aliado excelente ya que
le permite aumentar la productividad de la compañía en forma considerable:
FUENTE:http://www.oocities.org/es/dersia_alvarez/TI/foro/foro_cuerpo.html

CAPÍTULO II
ESTRATÉGIAS PARA EL DESARROLLO DE
SISTEMAS DE INFORMACIÓN
2.1. INTRODUCCIÓN
Los sistemas de información automatizados en la actualidad están cambiando la forma en que operan
las organizaciones actuales, a través de su uso se logran importantes mejoras, pues automatizan los
procesos operativos de las empresas, proporcionando información de toma de decisiones y facilitando
en gran manera ventajas competitivas a través de su implantación en las empresas, en este sentido,
resulta importante conocer estrategias que permitan trabajar adecuadamente en el proceso de
desarrollo de los mismos, y el ciclo de vida que se debe adoptar para este efecto.
2.2. CICLO VE VIDA
“Es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los
usuarios finales elaboran sistemas de información y aplicaciones informáticas”. (Whitten J., Bentley L., Barlow
V. 1996)
“Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el

mantenimiento del software” (IEEE 1074)
“Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el
desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización de su uso.” (ISO 12207-1 )
“Método de siete fases para el análisis y diseño de sistemas cuya premisa es que los sistemas se
desarrollan de una mejor manera mediante un ciclo específico de actividades del analista y el usuario.”
(Kendall & Kendall 2005 )
En resumen se puede mencionar que el ciclo de vida consiste en determinar:

 Las fases productivas del desarrollo de un proyecto.
 Los objetivos de cada fase productiva.
 Los productos obtenidos en cada una de estas fases así como sus características.
Es importante de que se pueda mostrar la perspectiva que tienen respecto a las fases de los ciclos de
vida diferentes según diferentes autores:
Como se puede observar, existe bastante coincidencia respecto a cada una de las fases genéricas para
el desarrollo de sistemas de información, de las que se puede destacar claramente las siguientes:
análisis – diseño – implementación –pruebas - mantenimiento.
El anterior ejemplo permite mostrar de manera análoga una comparación respecto a la construcción de
una casa y el desarrollo de un software, sin embargo, es importante de que se pueda detallar de
manera mucho más clara que se realiza en cada etapa, para esto, se presenta la siguiente información:

ANÁLISIS
Actividad en la que se analizan y clarifican los diferentes aspectos del problema que debe ser resuelto
por la aplicación, con el fin de establecer claramente qué debe ser construido.
 El resultado es, normalmente, un documento de requisitos software que especifica claramente
las funcionalidades de la aplicación
 Funcionalidad = lo que tiene que hacerse (sin saber todavía cómo)
DISEÑO
 Actividad en la que se decide la organización y la estructura de una aplicación que satisfaga los
diferentes requisitos establecidos en la fase de análisis
 El resultado es uno (o varios) documentos de diseño que especifican claramente cómo
construir la aplicación
 Mientras que el análisis se ocupa de qué hay que hacer, el diseño se ocupa de cómo hacerlo
 Hay varias técnicas de diseño, nosotros estudiaremos una de las más básicas: el diseño
funcional
IMPLEMENTACIÓN
 Actividad en la que se construye (codifica) la aplicación utilizando un lenguaje de programación
concreto, y siguiendo, las directrices marcadas por los documentos de diseño.
 Si las actividades anteriores han sido realizadas correctamente, la fase de implementación
debería ser bastante trivial.
 La implementación se encarga de concretar el diseño teniendo en cuenta un lenguaje y
herramienta de desarrollo concreta.
PRUEBAS
 Actividad en la que se asegura que la aplicación construida satisface los requisitos del usuario.
 Se debe invertir mucho tiempo en hacer pruebas (¡mucho más que en su implementación!).
 Dos pasos diferenciados
 Verificación: ¿Se ajusta la aplicación construida a los requisitos establecidos?

 Validación: ¿Resuelve la aplicación el problema que realmente tenía el usuario?
MANTENIMIENTO
 Actividad en la que la aplicación se modifica para satisfacer cambios o ampliaciones en
los requisitos del usuario, corregir errores, etc.
 ¡Es la actividad más costosa en el desarrollo de software!
(Tomar en cuenta que hay programas que están muchos años en funcionamiento y lo
usan miles de personas).
 Estos costes pueden aliviarse si se hacen bien todo lo anterior.

*otras actividades
 Confección de los manuales de usuario.

 Planificación y control del proyecto.
 Gestión de versiones.
...
2.3. ESTRATEGIAS, PRINCIPIOS Y CRITERIOS PARA LA EVALUACIÓN DEL CICLO DE

VIDA DE DESARROLLO DE SISTEMAS
Se pueden enunciar algunos principios para desarrollar correctamente un sistema de información:

1. Involucrar al usuario
El usuario es una parte imprescindible para el adecuado desarrollo de un sistema. Implicando al

usuario se logrará mejor sus necesidades y reducir su potencial resistencia a los nuevos sistemas de
información.
2. Utilizar métodos de solución de problemas
Cualquier actividad compleja necesita aplicar lógicas contrastadas. El ciclo de vida es en sí un

método de resolución de un problema específico.
3. Abordar adecuadamente cada una de las fases
El ciclo de vida moderno incorpora una serie de fases: planificación, análisis, diseño, implantación y
soporte de sistemas. En términos generales se puede decir que se desarrollan secuencialmente, y
cada una de ellas incorpora mayor grado de detalle que la anterior. Las fases planificación y análisis
han de abordarse correctamente, puesto que por muy inteligentes que sean las soluciones
técnicas, sin un análisis correcto será muy difícil que el sistema sea todo lo útil que potencialmente
podría ser.
4. Normalizar y documentar
Es fundamental que se fijen normas sobre las actividades, sobre las responsabilidades, requisitos
documentales y controles de calidad para asegurar en el tiempo la supervivencia del sistema. Los
analistas y programadores responsables de un sistema pueden dejar su puesto y si no existe la
documentación apropiada, todo puede resultar caótico. La necesidad de documentar aumenta en
la medida que el sistema que se desarrolle sea más complejo.
5. Justificar adecuadamente el sistema
Desarrollar sistemas de información supone invertir en el futuro de la empresa. No se puede

considerar un gasto, sino una inversión y como tal ha de plantearse.

6. Cancelar o revisar el proyecto si es necesario
Si es necesario, durante el desarrollo se ha de ser lo suficientemente flexible como para cancelar un

proyecto. Durante el ciclo de vida existen distintos momentos en los que se efectúa un control
progresivo que es un control de la viabilidad del proyecto.
7. Descomponer y simplificar
Un sistema complejo se ha de abordar dividiéndolo en subsistemas más simples. De esta manera

disminuye la complejidad y es más abordable por el ser humano.
8. Diseñar sistemas flexibles
Si los sistemas no se diseñan previendo futuras modificaciones, sólo servirán para momentos
concretos en el tiempo. Si se hace necesario cambiar un sistema que no es flexible, consumirá
muchos recursos y talento de las unidades involucradas en el soporte o mantenimiento del
sistema.
2.4. EL CICLO DE VIDA TRADICIONAL
Este ciclo de vida se caracteriza por:

 Tener una implantación Ascendente.
 Las fases deben sucederse de manera Secuencial.
 El usuario no ve resultados, sino hasta el final.
 El usuario o el ambiente pueden cambiar las especificaciones originales del sistema.
 Presenta numerosos problemas Analista-Usuario.
 Es manejable como proyecto.
Asimismo, es importante destacar las actividades al interior de cada fase del ciclo de vida las mismas
que se muestran a continuación:
 ANALISIS
o Estudio Preliminar
o Levantamiento de Información
o Definición del Problema
o Elaboración del Modelo Funcional del Sistema actual

o Determinación de Requerimientos
o Descripción y Evaluación de Alternativas
o Aprobación de alternativa
 DISEÑO
o Elaborar Modelo Funcional del Sistema Propuesto
o Diseño Lógico
o Elaboración y Presentación del prototipo del Sistema
o Aprobación del Sistema Propuesto
 IMPLEMENTACION
o Codificación del Software
o Prueba del Sistema
o PUESTA EN MARCHA:Actividad de traslado de una aplicación probada a un ambiente
de producción; entre las actividades realizadas dentro de esta, se tienen:
- Acondicionamiento de - Carga de datos en vivo
locales - Entrega de documentación
- Organización del Cliente - Asignar Responsabilidades
- Entregar aplicación probada - Determinar FIN de la
- Elaborar datos en Vivo instalación
- Adiestramiento
 MANTENIMIENTO
La fase de mantenimiento de software aporta cambios al mismo para corregir defectos y
dependencias encontradas durante su uso así como la adición de nuevas funciones para
mejorar la usabilidad y aplicabilidad del software.
Tipos de mantenimiento:
 Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de
los sistemas en cualquiera de sus aspectos; reestructuración del código,
definición más clara del sistema y optimización del rendimiento y eficiencia.
 Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias
en un producto software para cubrir la expansión o cambio en las necesidades
del usuario.
 Adaptativo: son las modificaciones que afectan a los entornos en los que el
sistema opera.
 Correctivo: son aquellos cambios precisos para corregir errores del producto
software.
2.5. MODELOS DE CICLOS DE VIDA
Es importante que todo analista de sistemas pueda de inicio conocer los modelos de ciclos de vida que
permitirán llevar a cabo el desarrollo de manera sistemática y exitosa, entre los modelos más
importantes se pueden identificar:

3.1.9. Modelo en cascada
Este modelo toma en cuenta las siguientes fases:

 Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema
mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y
luego asignando algún subconjunto de estos requisitos al software.
 Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e
intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender
el ámbito de la información del software, así como la función, el rendimiento y las interfaces
requeridas.
 Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación
del software con la calidad requerida antes de que comience la codificación.
 Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de
codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación
puede realizarse mecánicamente.

 Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se
centra en la lógica interna del software, y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se requieren.
 Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios
ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios
del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente
requiera ampliaciones funcionales o del rendimiento.
3.1.10. Modelo en espiral
Es un modelo evolutivo que combina el modelo clásico con el diseño de prototipos, incluye la etapa de
análisis de riesgos y es ideal para crear productos con diferentes versiones mejoradas.
Este es el modelo más realista actualmente. El modelo en espiral se divide en un número de actividades
estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de
tareas:
 Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el
desarrollador y el cliente.
 Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.
 Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones
relacionadas con el proyecto.
 Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
 Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario.
 Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la
evaluación de las representaciones del software creadas durante la etapa deingeniería e
implementación durante la etapa de instalación.
3.1.11. Modelo basado en prototipos
Un prototipo es una representación o modelo del producto de programación que incorpora

componentes del producto real. Por lo regular, un prototipo tiene un funcionamiento limitado en
cuanto a capacidades, confiabilidad o eficiencia
Este modelo arranca con el establecimiento de los requerimientos del sistema, se definen los objetivos
del sistema y los requisitos conocidos con base en las áreas de mayor prioridad e importancia para el
sistema.
Luego se hace un diseño preliminar, sobre el cual se construye un prototipo o modelo del sistema,
compuesto a menudo de ventanas, tablas de la Base de Datos, formatos de entrada y de salida básicos.
3.1.12. Modelo incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de
reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles
posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando
subconjuntos de requerimientos del sistema.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
 Es un desarrollo inicial de la arquitectura completa del sistema seguido de incrementos o
versiones parciales.
 Cada incremento tiene su propio ciclo.
 Cada incremento agrega una funcionalidad.
 Construir un sistema pequeño tiene siempre menos riesgo que construir un sistema grande.
 Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos
planeados para los niveles subsiguientes son correctos.
 Si un error importante es realizado, sólo la última iteración necesita ser descartada.
 Reduciendo el tiempo de desarrollo de un sistema decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.
 Si un error importante es realizado, el incremento previo puede ser usado.
 Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del
comienzo del próximo incremento.
2.6. HERRAMIENTAS CASE
El nuevo analista debe tener conocimientos en herramientas CASE para ser productivos y realizar sus tareas
de una manera organizada, precisa y minuciosa.
[Kendall &Kendall]
CASE (ComputerAided Software Engineering : o Ingeniería de Software Asistida por Computadora) es

una filosofía que se orienta a la mejor comprensión de los modelos de empresa, sus actividades y el
desarrollo de sistemas de información. Esta filosofía involucra además el uso de programas que
permite:
2. Construir los modelos que describe la empresa.
3. Describir el medio en el que se realizan las actividades.
4. Llevar a cabo la planificación.
5. El desarrollo del sistema informativo desde la planificación, pasando por el análisis y diseño
de sistemas, hasta la generación del código de los programas y la documentación.

3.1.13. OBJETIVOS DE LAS HERRAMIENTAS CASE
 Aumentar la productividad de las áreas de desarrollo y mantenimiento de los sistemas

informáticos.
 Mejorar la calidad del software desarrollado.
 Reducir tiempos y costos de desarrollo y mantenimiento del software.
 Mejorar la gestión y dominio sobre el proyecto en cuanto a su planificación, ejecución y control.
 Mejorar el archivo de datos (enciclopedia) de conocimientos y sus facilidades de uso, reduciendo
la dependencia de analistas y programadores.
 Automatizar:
o El desarrollo del software.

o La documentación.
o La generación del código.
o El chequeo de errores.
o La gestión del proyecto.
 Permite:
o La reutilización (reusabilidad) del software.

o La portabilidad del software.
o La estandarización de la documentación.
 Integrar las fases de desarrollo (ingeniería de software) con las herramientas CASE.
 Facilitar la utilización de las distintas metodologías que desarrollan la propia ingeniería de
software.
3.1.14. Clasificación de las herramientas CASE

Las herramientas CASE, se pueden clasificar según las fases del ciclo de vida y según su funcionalidad:
1. Clasificación del CASE en función de las fases del ciclo de vida abarcadas.

 HERRAMIENTAS INTEGRADAS, I-CASE (integrated CASE, CASE INTEGRADO): abarcan todas las
fases del ciclo de vida del desarrollo de sistemas. Son llamadas también workbench.
o WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso
completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto
final aportado por ellas es un sistema en código ejecutable y su documentación.
 HERRAMIENTAS DE ALTO NIVEL, U-CASE (Upper CASE- CASE Superior) o front-end, orientadas
a la automatización y soporte de las actividades desarrolladas durante las primeras fases del
desarrollo: planificación estratégica, requerimientos de desarrollo.
 HERRAMIENTAS NIVEL MEDIO, (Middle CASE) abarca las fases de análisis y diseño.
 HERRAMIENTAS DE BAJO NIVEL, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a
las últimas fases del desarrollo: generación de código, construcción e implantación.
 JUEGO DE HERRAMIENTAS O TOOLKITS: Son el tipo más simple de herramientas CASE.
Permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del
sistema informático: planificación estratégica, análisis, diseño, generación de programas.
2. Clasificación del CASE utilizando la funcionalidad como criterio principal.
 HERRAMIENTAS DE PLANIFICACION DE SISTEMAS DE GESTION.
Sirven para modelizar los requisitos de información estratégica de una organización. Proporcionan
un “metamodelo” del cual se pueden obtener sistemas de información específicos.
Su objetivo principal es ayudar a comprender mejor cómo se mueve la información entre las
distintas unidades organizativas. Estas herramientas proporcionan una ayuda importante cuando
se diseñan nuevas estrategias para los sistemas de información y cuando los métodos y sistemas
actuales no satisfacen las necesidades de la organización.
 HERRAMIENTAS DE ANALISIS Y DISEÑO
Permiten al desarrollador crear un modelo del sistema que se va a construir y también la

evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la
representación del análisis y ayudan a eliminar errores con anticipación. Se tienen:
 Herramientas de análisis y diseño (modelamiento)

 Herramientas de creación de prototipos y de simulación
 Herramientas para el diseño y desarrollo de interfases
 Máquinas de análisis y diseño (modelamiento)
 HERRAMIENTAS DE PROGRAMACION
Aquí se engloban los compiladores, los editores y los depuradores de lenguajes de programación
convencionales. Ejemplo de estas herramientas son:

 Herramientas de codificación convencionales

 Herramientas de codificación de cuarta generación
 Herramientas de programación orientadas a objetos.
 HERRAMIENTAS DE INTEGRACION DE PRUEBA
Sirven de ayuda a la adquisición, medición, simulación y prueba de los equipos lógicos

desarrollados. Entre las más utilizadas están:
 Herramientas de análisis estático

 Herramientas de codificación de cuarta generación
 Herramientas de programación orientadas a los objetos.
 HERRAMIENTAS DE GESTION DE PROTOTIPOS
Los prototipos son utilizados ampliamente en el desarrollo de aplicaciones, para la evaluación de

especificaciones de un sistema de información o para un mejor entendimiento de cómo los
requisitos de un sistema de información se ajustan a los objetivos perseguidos.
 HERRAMIENTAS DE MANTENIMIENTO
Esta categoría se puede subdividir en:

 Herramientas de ingeniería inversa
 Herramientas de reestructuración y análisis de código
 Herramientas de reingeniería
 Herramientas de gestión de proyectos
3.1.15. Clases de herramientas CASE funcionales
TIPOS DE HERRAMIENTAS EJEMPLOS
Herramientas de administración Herramientas PERT de estimación.
Herramientas de edición Editores de texto, de diagramas, Procesadores de palabras.
Herramientas de prototipo Lenguajes de alto nivel, generadores de interface.
Herramientas de lenguajes Compiladores, intérpretes.
Herramientas de prueba Comparadoras de archivos, generadores de prueba de datos.
Herramientas de depuración Sistemas interactivos de depuración.

Sistemas reestructurados de programas, sistemas de referencia
Herramientas de reingienería
cruzada.

CAPITULO III
TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN
“La Ingeniería de Sistemas se ha popularizado como una disciplina que pone especial énfasis en la aplicación de
las nuevas técnicas de investigación de operaciones. “El verdadero trabajo del ingeniero es la investigación y
creación de soluciones nuevas, no de la aplicación de lo ya comprobado…”
X. BRUGES
3.2. INTRODUCCIÓN
Considerando que un método es el “camino para llegar a un fin”, los métodos de investigación
constituyen el camino para llegar al conocimiento científico; son un procedimiento o conjunto de
procedimientos que sirven de instrumento para alcanzar los fines de la investigación. La descripción, la
exploración, la explicación, la predicción y el control de los fenómenos naturales constituyen los
objetivos más comunes de una investigación.
En el proceso real de la investigación científica se presentan etapas que se encuentran separadas entre
sí aunque no hay barreras absolutas entre ellas y pueden realizarse de manera consecutiva, cada una
de ellas se desarrollan con la ayuda de los métodos de investigación, los que se aplican en cada etapa
del proceso para revelar las características del objeto. En cada una de las mencionadas etapas del
proceso prevalece un método sobre otro, sin que en ningún momento la aplicación preferencial de uno
implique la negación absoluta de otros.
Independientemente de su estudio mucho más profundo posteriormente y con el fin de mantener la
coherencia lógica del presente capítulo, hay que destacar en este epígrafe introductorio que los
métodos se pueden clasificar en teóricos(lógicos) o empíricos, en dependencia de los procedimientos
que utilicen durante su desarrollo.
3.3. METODOS EMPÍRICOS
Son aquellos que revelan y explican las características fenomenológicas del objeto. Estos se emplean
fundamentalmente en la primera etapa de acumulación de información empírica y en la tercera de
comprobación experimental de la hipótesis de trabajo.
Estos métodos se aproximan al conocimiento del objeto mediante su conocimiento directo y el uso de
la experiencia.
A lo largo de toda Investigación Científica, los métodos empíricos y teóricos del conocimiento
están dialécticamente relacionados; como regla uno ni se desarrolla ni existe sin el otro.
Estos métodos de investigación empírica implican toda una serie de procedimientos prácticos con el
objeto y los medios de investigación que permiten revelar las características fundamentales y
relaciones esenciales del objeto; que son accesibles a la contemplación sensorial. Los métodos de
investigación empírica, representan un nivel en el proceso de investigación cuyo contenido procede
fundamentalmente de la experiencia, el cual es sometido a cierta elaboración racional y expresado en
un lenguaje determinado.
3.3.1. OBSERVACIÓN CIENTÍFICA
La observación científica como método consiste en la percepción directa del objeto de investigación.
La observación investigativa es el instrumento universal del científico. La observación permite conocer
la realidad mediante la percepción directa de los objetos y fenómenos.
La observación, como procedimiento, puede utilizarse en distintos momentos de una investigación más
compleja: en su etapa inicial se usa en el diagnóstico del problema a investigar y es de gran utilidad en
el diseño de la investigación. En el transcurso de la investigación puede convertirse en procedimiento
propio del método utilizado en la comprobación de la hipótesis. Al finalizar la investigación la
observación puede llegar a predecir las tendencias y desarrollo de los fenómenos, de un orden mayor
de generalización.
La observación científica presenta las siguientes cualidades:
 La observación científica es consciente; y se orienta hacia un objetivo o fin determinado. El
observador debe tener un conocimiento cabal del proceso, fenómeno u objeto a observar, para
que sea capaz, dentro del conjunto de características de éste, seleccionar aquellos aspectos
que son susceptibles a ser observados y que contribuyen a la demostración de la hipótesis.
 La observación científica debe ser cuidadosamente planificada donde se tiene en cuenta
además de los objetivos, el objeto y sujeto de la observación, los medios con que se realiza y
las condiciones o contexto natural o artificial donde se produce el fenómeno, así como las
propiedades y cualidades del objeto a observar.

 La observación científica debe ser objetiva: ella debe estar despojada lo más posible de todo
elemento de subjetividad, evitando que sus juicios valorativos puedan verse reflejados en la
información registrada. Para esto hay que garantizar:
- Mediante la observación se recoge la información de cada uno de los conceptos o variables

definidas en la hipótesis de trabajo, en el modelo. Cuando esto se cumple decimos que
existe validez en la observación.
- El documento guía de la observación debe ser lo suficientemente preciso y claro para

garantizar que diferentes observadores al aplicar éste, en un momento dado, lo entiendan
y apliquen de la misma manera. Cuando este requisito se cumple decimos que la
observación es confiable.
3.3.1.1. Importancia de la observación

 Históricamente la observación fue el primer método científico empleado, durante mucho
tiempo constituyó el modo básico de obtención de la información científica.
 La observación, como método científico, nos permite obtener conocimientoacerca del
comportamiento del objeto de investigación tal y como éste se da en la realidad, es una
manera de acceder a la información directa e inmediata sobre el proceso, fenómeno u objeto
que está siendo investigado.
 La observación estimula la curiosidad, impulsa el desarrollo de nuevos hechos que pueden
tener interés científico, provoca el planteamiento de problemas y de la hipótesis
correspondiente.
 La observación puede utilizarse en compañía de otros procedimientos o técnicas (la
entrevista, el cuestionario, etc.), lo cual permite una comparación de los resultados obtenidos
por diferentes vías, que se cumplimentan y permiten alcanzar una mayor precisión en la
información recogida.
 La observación como método científico hace posible investigar el fenómeno directamente, en
su manifestación más externa, en su desarrollo, sin que llegue a la esencia del mismo, a sus
causas, de ahí que, en la práctica, junto con la observación, se trabaje sistemáticamente con
otros métodos o procedimientos como son: la medición y el experimento. Por supuesto, para
llegar a la esencia profunda del objeto se hace necesario el uso de los métodos teóricos.
 La observación, como método científico, puede aplicarse de diferentes formas:
o Observación simple: se realiza con cierta espontaneidad, por una persona de calificación
adecuada para la misma y ésta debe ejecutarse, de forma consciente y desprejuiciada.
o Observación sistemática: requiere de un control adecuado que garantice la mayor
objetividad, realizándose la observación de forma reiterada y por diferentes observadores,
inclusive para garantizar la uniformidad de los resultados de éste.

o Observación participativa: en ella el observador forma parte del grupo observado y

participa en él durante el tiempo que dure la observación.
o Observación no participante: el investigador realiza la observación desde fuera, no forma
parte del grupo investigado.
o Observación abierta: donde los sujetos y objetos de la investigación, conocen que van a
ser observados. Cuando se utiliza este tipo de observación se analiza previamente si el
hecho de que los observados conozcan previamente que su conducta es observada, esto
puede afectar los resultados de la observación. En caso positivo es necesario realizar la
observación encubierta, cerrada o secreta.
o Observación encubierta: las personas que son objeto de la investigación no lo saben. El
observador está oculto, se auxilia con medios técnicos los que en la mayoría de los casos
no son de fácil obtención. Esta investigación es más objetiva.
3.3.1.2. Organización de la observación
Está determinada por muchos factores como pueden ser: tipo de objeto sobre el cual se investiga,
características personales del observador, métodos, procedimientos y técnicas que se requiere para
la observación, de las propiedades y cualidades del objeto a observar, medios con que se cuenta para
la observación y otros.
Una vez tenido en cuenta todos estos factores, se elabora un plan de observación donde se precisa:
objeto, magnitudes y variables a observar, tiempo de duración de la observación y el resultado
esperado. A partir de esto se elabora un programa de observación, determinado por las interrogantes
que tienen que esclarecerse mediante la misma.
3.3.2. LA MEDICIÓN
La observación fija la presencia de una determinada propiedad del objeto observado o una relación
entre componentes, propiedades u otras cualidades de éste. Para la expresión de sus resultados no
son suficientes con los conceptos cualitativos y comparativos, sino que es necesaria la atribución de
valores numéricos a dichas propiedades y relaciones para evaluarlas y representarlas
adecuadamente.
Cuando se inicia el estudio de una región de procesos o fenómenos totalmente desconocidos se
comienza por la elaboración de conceptos cualitativos, lo que permite una clasificación de los objetos
de la región estudiada. Posteriormente se establecen determinadas relaciones entre los conjuntos de
objetos semejantes con el auxilio de conceptos comparativos, lo que permite clasificarlos en conjuntos
que tengan cualidades semejantes.
El uso de conceptos comparativos puede servir de base para la introducción de conceptos
cuantitativos, es decir, conceptos que designan la cualidad medida. El tránsito de los conceptos
cualitativos a los comparativos y de estos a los cuantitativos se realiza solo mediante proposiciones
teóricas.

La medición es el método empírico que se desarrolla con el objetivo de obtener información numérica
acerca de una propiedad o cualidad del objeto, proceso o fenómeno, donde se comparan magnitudes
medibles y conocidas.
El valor numérico de una propiedad va a estar dada por la diferencia de valores entre las magnitudes
comparadas.
Se denominará medición al proceso de comparación de una propiedad con una magnitud homogénea
tomada como unidad de comparación.
Se puede decir que la medición es la atribución de valores numéricos a las propiedades de los objetos.
Aunque la medición constituye una de las formas del conocimiento empírico, los procedimientos de
medición se determinan por consideraciones teóricas.
En la medición es necesario tener en cuenta el objeto y la propiedad que se va a medir, la unidad y el
instrumento de medición, el sujeto que realiza la misma y los resultados que se pretenden alcanzar.
3.3.2.1. Niveles básicos de la medición
En investigación hay cuatro niveles básicos de medición:

1. Escala nominal.- divide los datos en categorías, los números que se asignan a objetos o
fenómenos son nombres o clasificaciones; se emplean para calcular recuentos de frecuencias
porcentajes y modas.
Los valores son nominativos, sirven para designar. Sólo se puede realizar un conteo (frecuencias). No es
factible las operaciones aritméticas. Se analizan a través de la comparación: igualdad y no igualdad ( = y
).
EJEMPLO
Sexo del paciente 1: Masculino 2: Femenino
Grupo sanguíneo A B AB O
Servicio médico 1: Emergencia 2: Ginecología
3: Traumatología 4: Pediatría
2. Escala ordinal.- tiene como propósito dar orden (prioridades) a los datos de forma ascendente
o descendente. Se emplean para calcular la mediana, la media y la desviación típica.
Los valores representan un orden. No son cuantitativos, sólo simbolizan una posición. Se
analizan a través de la desigualdad: mayor que o menor que (> y <).
EJEMPLO
Calificación : A,B,C,D A>B
Lugar (orden) : 1º , 2º , 3º 1º > 2º
Dolor : leve, moderado, intenso

3. Escala de intervalos.- son escalas que agrupan las mediciones por intervalos o rangos, donde
los puntos de escala son iguales. Se emplean para calcular la media aritmética, las desviaciones
estándares y el coeficiente de correlación.
Se utilizan números cardinales. El cero es relativo o diferencial, es decir no indica ausencia de la

propiedad. Se pueden realizar operaciones aritméticas.(+ y -). Es una escala creada por el
hombre..
EJEMPLO
Hora 00:00
Temperatura ambiental 0 ºC
El año en que vivimos 2003
4. Escala de razón.- es una escala similar a las escalas de intervalos, sin embargo, tienen un cero
absoluto u origen. Se utilizan con variables como ingresos, volumen de producción,
rentabilidad, etc.
Se utilizan números cardinales. Tienen unidad de medida (cms, pulgadas). El cero es absoluto,
indica ausencia de la propiedad. Se pueden realizar operaciones aritméticas (+,-,x ,),
EJEMPLO
Pacientes no atendidos hoy : 0
Nº de hijos en edad de vacunación : 0
Procesos deficientes : 0
3.3.2.2. Confiabilidad y valides de la medición
CONFIABILIDAD
Se refiere a la consistencia de las puntuaciones obtenidas por las mismas personas, cuando se las
examina en distintas ocasiones con los mismos cuestionarios. La pregunta clave para determinar la
confiabilidad es si se miden fenómenos o eventos con el mismo instrumento de medición, ¿se
obtienen los mismos resultados o otros muy similares?
VALIDEZ
Un instrumento de medición es válido cuando mide aquello para lo cual esta destinado. Indica el
grado con que pueden inferirse conclusiones a partir de los resultados obtenidos.
Factores que afectan la confiabilidad y la validez de los instrumentos de medición
- La improvisación, consiste en creer que un instrumento de medición es un cuestionario

que resulta de elaborar varias preguntas sin mucha dedicación ni revisión.
- La utilización de instrumentos desarrollados en el extranjero que no han sido validados en
el respectivo contexto.
- El instrumento resulta inadecuado para las personas a las que se les aplica.
- Las condiciones en las que se aplica el instrumento de medición.
- Las instrucciones son deficientes.
- Quienes aplican el instrumento no generan empatía ni conocen el instrumento.
Otras fuentes de error en un instrumento de medición
- Error muestral
- Errores de respuesta
- Error por falta de respuesta
- Error de aplicación en el instrumento
3.4. TÉCNICAS DE INVESTIGACIÓN
Las técnicas son herramientas o instrumentos que coadyuvan al logro y cumplimiento de los
objetivos planteados, las mismas son esenciales para la investigación científica, ya que por medio de
ellas se integra, organiza la investigación.
Es importante el uso de las técnicas en la investigación, ya que las mismas persiguen los siguientes
objetivos:
 Ordenar las etapas de la investigación.
 Aportar con instrumentos para el manejo de la información.
 Llevar el control de los datos.
 Orientar la obtención de la información.
 Facilitar el uso de métodos.
 Especificación detalladamente aspectos de la investigación.
 Delimitar algunos componentes de la investigación.
3.4.1. El CUESTIONARIO
El cuestionario es un instrumento básico de la observación en la encuesta y en la entrevista. En el

cuestionario se formula una serie de preguntas que permiten medir una o más variables.
El cuestionario posibilita observar los hechos a través de la valoración que hace de los mismos el
encuestado o entrevistado, limitándose la investigación a las valoraciones subjetivas de éste.
No obstante a que el cuestionario se limita a la observación simple, del entrevistador o el encuestado,
éste puede ser masivamente aplicado a comunidades nacionales e incluso internacionales, pudiéndose
obtener información sobre una gama amplia de aspectos o problemas definidos.
La estructura y el carácter del cuestionario lo definen el contenido y la forma de las preguntas que se
les formula a los interrogados.

3.4.1.1. Tipos de preguntas
La pregunta en el cuestionario por su contenido pueden dividirse en dos grandes grupos: pregunta
directa o indirecta.
 La pregunta directa: coincide el contenido de la pregunta con el objeto de interés del
investigador.
 La formulación de la pregunta indirecta constituye uno de los problemas más difíciles de la
construcción de las encuestas.
o Ejemplo de pregunta directa: ¿Le agrada a usted la profesión de Ingeniero de Sistemas?

o Ejemplo de pregunta indirecta: ¿Quisiera usted que su hijo escogiera la profesión de
Ingeniero de Sistemas?
Al construir el cuestionario, conjuntamente con el contenido de las preguntas, hay que definir su
forma, utilizándose en sociología el cuestionario abierto y cerrado.
 La pregunta abierta en una encuesta es la que no limita el modo de responder a la misma, ni se
definen las variantes de respuestas esperadas. Este tipo de preguntas no permite medir con
exactitud la propiedad, solo se alcanza a obtener una opinión.
o Ejemplo: ¿Qué piensa usted respecto al comercio electrónico?
 La pregunta cerrada tiene delimitada, con antelación, su respuesta para determinada cantidad
de variantes previstas por el confeccionador del instrumento. Existen dos tipos de preguntas
cerradas, las dicotómicas (dos alternativas de respuestas) y las politómicas (varias alternativas
de respuesta).
o Dicotómica:
Ejemplo: ¿Considera usted que el comercio electrónico es clave para poder ampliar las
ventas en su empresa? Si No
o Politómica:
Ejemplo: ¿Cómo califica usted el método actual utilizado para captar ventas en su
empresa?
Excelente
Bueno
Regular
Malo
Muy malo
 La pregunta mixta que considera en su construcción una combinación de tanto preguntas

cerradas como abiertas, su utilidad es amplia, ya que identifica claramente la respuesta.
o Ejemplo: ¿Considera usted que el comercio electrónico es clave para poder ampliar las
ventas en su empresa? Si No

¿Porque?______________________________________________________________________
______________________________________________________________________________
Otra técnica muy aplicada en el cuestionario es la selección, donde la persona a la cual se aplica el
instrumento elige entre una lista de posibles respuestas aquellas que prefiere. Dentro de esta técnica
existen variantes: de selección limitada, donde puede elegir un número determinado de respuestas y
el de selección única donde puede escoger una sola respuesta posible.
La elaboración estadística en este caso resulta sencilla, donde se reduce al conteo de frecuencia de
selección de cada respuesta sobre la cual se realiza la gradación de la actitud que muestran los
encuestados hacia las respuestas.
En los cuestionarios se pueden aplicar preguntas que miden actitudes del individuo hacia un
determinado hecho. Cuando se mide actitud, es necesario tener en cuenta la dirección de la misma así
como su intensidad, para lo cual se aplican diversos tipos de escalas.
De manera más general la pregunta se formula de forma positiva y se dan 5 alternativas de posibles
respuestas, designándose una escala de valores de 1 a 5, dando la respuesta más favorable a la
afirmación que tenga el máximo de puntuación.
Ejemplo:
“El nuevo plan de estudio de la carrera de Ingeniería de Sistemas permite que los estudiantes alcancen
un mayor desarrollo en sus capacidades creativas”
Muy de acuerdo………………………………………….… (5)
De acuerdo ………………………………………………….. (4)
Ni de acuerdo, ni en desacuerdo……….…………. (3)
En desacuerdo..………………………………………….…. (2)
Muy en desacuerdo …………………………….………. (1)
Si por el contrario las afirmaciones son negativas en la formulación de la pregunta, la evaluación de la

pregunta debe resultar opuesta al anterior caso.
Ejemplo:
“La nueva estructura administrativa de las organizaciones en Potosí han permitido la introducción de
estudiantes practicantes de la carrera de Ingeniería de sistemas”.
Totalmente de acuerdo ………………………………… (1)
De acuerdo ………………………………………………….… (2)
Ni de acuerdo ni en desacuerdo…………………..… (3)
En desacuerdo ………………………………………………. (4)
Totalmente en desacuerdo ……………………………. (5)
3.4.1.2. Tipo de información a recoger por el cuestionario
 Un cuestionario sirve para recoger información de distintos tipos:

 Hechos o comportamientos
 Conocimientos

 Opiniones o juicios
 Actitudes
 Motivos / explicaciones de conductas concretas
 Posibles comportamientos futuros
 Distintos tipos de estudios suelen buscar informaciones de distintos tipos
3.4.1.3. Fases para la elaboración del cuestionario
Las fases que se deben seguir para elaborar adecuadamente un cuestionario se presentan en la
siguiente figura:
FASES PARA LA ELABORACIÓN DEL CUESTIONARIO
3.4.1.4. Algunas reglas básicas para la construcción del cuestionario
1. Al igual que cualquier otra teoría propia de los métodos empíricos, hay que partir de la
hipótesis formulada y específicamente de los indicadores de las variables definidas en
ésta, los que se traducirán en preguntas específicas para el cuestionario.
2. Establecer la necesidad de cooperación del encuestado; lo que dependerá de que los
individuos participen o no, o que contribuyan o no favorablemente en la investigación.
Dicha demanda puede realizarse de diversas formas; puede hacerla el entrevistador en el
momento de presentar el instrumento, puede acompañar el mismo por escrito, puede
solicitarse por teléfono, por carta previa, etc.
3. Lo valioso de la información que se solicita debe estar en lo que se solicita.
4. Que no existe motivo encubierto o no confesado en la finalidad perseguid.
5. Uso confidencial de la información que se brinda.
6. Lo fácil y rápido que puede contestarse el cuestionario.
7. Las preguntas deben ser claras.
8. Cada término debe ser comprendido.
9. No deben de plantearse dos preguntas en una.
10. La pregunta debe formularse de manera positiva.

11. La construcción de la respuesta no debe inducir expresiones ambiguas.

12. Las preguntas no deben ser tendenciosas, es decir, no deben estar confeccionadas de
manera tal que lleven al individuo a responder de una manera determinada o que lo
predispongan en contradicción con su sentir ante la pregunta a responder.
13. Las preguntas no deben exigir mucho esfuerzo de la memoria.
14. Al abordar aspectos controvertidos o embarazosos las preguntas deben ser construidas de
forma tal que no constituyan un conflicto para el sujeto.
15. El orden de las preguntas debe de disponerse con arreglo a las características psicológicas
de las mismas.
16. En primer lugar se deben preguntar datos socio-demográficos como sexo, edad,
ocupación; a continuación preguntas generales simples que lo van llevando hasta
preguntas más complejas, de lo impersonal a lo personal.
17. Se debe contrarrestar el efecto de monotonía en la variante de respuesta. Esto ocurre
fundamentalmente en los cuestionarios cerrados y cuando el interrogado no se siente
totalmente motivado a responder.
18. Debe de inducirse una pregunta final que recoja la impresión del interrogado respecto al
cuestionario.
3.4.1.5. Orden de las preguntas
Las preguntas en un cuestionario deben elaborarse tomando en cuenta el siguiente orden:
1) Empezar con una presentación

2) Filtros al principio de los bloques
3) Primeras preguntas sencillas
4) Agrupar temas afines
5) Ir de lo general a lo específico y de lo sencillo a lo complicado
6) Preguntas delicadas en medio
7) Acabar con preguntas “de relax”
8) Preguntas de clasificación al final
9) Dar las gracias al acabar
En conclusión podemos decir que en la ejecución de una investigación se hacen uso de

múltiples métodos y procedimientos tratando de ser cada vez más profundos y esenciales en la
caracterización del objeto.
Aunque el método describe la vía que sigue el investigador, su modo de actuación; sin
embargo, sólo con ayuda del método no es posible explicar el por qué se desarrolla la
Investigación Científica.

3.4.1.6. Ventajas y desventajas del cuestionario
Ventajas:
- Ahorro de tiempo.
- Posibilidad de aplicación colectiva.
- Facilidad para la codificación.
- Requiere menos habilidad para administrarlo que cualquier otro tipo de instrumento.
Limitaciones e Inconvenientes:
- Tiene el riesgo de un elevado porcentaje de cuestionarios sin respuesta, lo cual puede

disminuir notablemente la representatividad de los resultados.
- Exclusión casi sistemática de quienes no saben escribir o leer. Generalmente sólo puede
ser respondido por personas que cierto nivel educativo y/o que sepan leer como
mínimo, pudiéndose consignar falsedades u omitir datos en las respuestas (UNA, 1999;
Buendía y otros, 1998).
- Imposibilidad de ayudar al informante cuando no ha comprendido las preguntas o
instrucciones.
- Dificultad para realizar el control y la verificación de la información; recepción tardía de
muchos cuestionarios remitidos después de la fecha indicada, y consecuentemente no
utilizables.
- Si el investigador no se encuentra presente, no existe la certeza de que la persona que
responde es la que el investigador desea; y no existe la posibilidad de aclarar las preguntas
en caso de confusión, quedando a libre interpretación.
- Al no existir alguien a quien recurrir, el interrogado pudiera consultar con otras personas
antes de expresar sus opiniones con lo que se pierde la espontaneidad e individualidad de
los datos a recolectar.
- Igualmente, depende de la disposición del encuestado para proporcionar la información.
- Asimismo, a través del cuestionario es imposible conocer las reacciones del respondiente
ante cada pregunta, lo cual puede ser un dato significativo para la investigación.
- De igual manera, aunque el anonimato al término de responder un cuestionario puede
generar cierta confidencialidad, existen personas que adoptan una actitud poco seria y
responsable lo que dificultaría la representatividad de los resultados.
- Limitación de las respuestas de la muestra y, en ocasiones, ninguna de las categorías
describe con exactitud lo que las personas tienen en mente; no siempre se captura lo que
pasa por la cabeza de los sujetos

3.4.2. LA ENTREVISTA
La entrevista es una técnica de recopilación de información mediante una conversación profesional,
con la que además de adquirirse información acerca de lo que se investiga, los resultados a lograr en
la misión depende en gran medida del nivel de comunicación entre el investigador y los
participantes en la misma.
- Es la comunicación interpersonal establecida entre el investigador y el sujeto de estudio a fin

de obtener respuestas verbales a las interrogantes planteadas sobre el problema propuesto.
- «Técnica orientada a obtener información de forma oral y personalizada sobre
acontecimientos vividos y aspectos subjetivos de los informantes en relación a la situación que
se está estudiando».
(Folgueiras, 2009)
Según el fin que se persigue con la entrevista, ésta puede estar o no estructurada mediante un
cuestionario previamente elaborado. Cuando la entrevista es aplicada en las etapas previas de la
investigación donde se quiere conocer el objeto de investigación desde un punto de vista externo,
sin que se requiera aún la profundización en la esencia del fenómeno, las preguntas a formular por
el entrevistador, se deja a su criterio y experiencia.
Si la entrevista persigue el objetivo de adquirir información acerca de las variables de estudio o

preguntas de investigación, el entrevistador debe tener clara la hipótesis de trabajo, las variables y
relaciones que se quieren demostrar por una parte ó las preguntas de investigación; de forma tal
que se pueda elaborar un cuestionario adecuado con preguntas que tengan un determinado fin y
que son imprescindibles para esclarecer la tarea de investigación, así como las preguntas de apoyo
que ayudan a desenvolver la entrevista.
El éxito que se logre en la entrevista depende en gran medida del nivel de comunicación que
alcance el investigador con el entrevistado; la preparación que tenga el investigador en cuanto a las
preguntas que debe realizar; la estructuración de las mismas; las condiciones psicológicas del
investigado; la fidelidad a la hora de transcribir las respuestas y el nivel de confianza que tenga el
entrevistado sobre la no filtración en la información que él está brindando; así como la no influencia
del investigador en las respuestas que ofrece el entrevistado.
La entrevista es una técnica que puede ser aplicada a todo tipo de persona, aún cuando tenga
algún tipo de limitación como es el caso de analfabetos, limitación física y orgánica, niños que
posean alguna dificultad que le imposibilite dar respuesta escrita.
3.4.2.1. Tipos de entrevistas
 Estructurada, es aquella entrevista que está estructurada a partir de un cuestionario

elaborado previamente, la información que se obtiene resulta fácil de procesar, no se
necesita de un entrevistador muy diestro y hay uniformidad en el tipo de información que

se obtiene; sin embargo esta alternativa no posibilita profundizar en los aspectos que
surjan en la entrevista.
 No estructurada, la entrevista no estructurada es muy útil en estudios descriptivos, y en la
fase del diseño de la investigación; es adaptable y susceptible de aplicarse a toda clase de
sujetos y de situaciones; permite profundizar en el tema y requiere de tiempo y de
personal de experiencia para obtener información y conocimiento del mismo. En ésta se
dificulta el tratamiento de la información, ya que no cuenta con la elaboración previa del
cuestionario.
 Semi-estructurada, en este caso se utilizan preguntas estructuradas y no estructuradas,
por esta razón se denomina mixta. En este tipo de entrevista, el eje guía es una especie de
guión sobre temas a tratar, a raíz de esto, la entrevista se adapta a cada entrevistado. Este
tipo de entrevista es el más utilizado por los investigadores por su amplitud de respuestas.
3.4.2.2. Fases para la elaboración de la entrevista
Las fases a seguir para poder elaborar la entrevista se muestran a continuación:
I. Diseño de entrevista
• Definir objetivos de la entrevista
• Muestreo personas a entrevistar (Directorio)
• Diseño de cuestionario
II. Desarrollo de la entrevista

• Concertar citas y contactos
• Realizar entrevista
• Registro de información
III. Análisis e interpretación de datos

• Categorizar y codificar datos recolectados
• Crear una matriz y elaborar representaciones gráficas.
• Elaborar conclusiones
EJEMPLO de cómo iniciar una entrevista:
Somos estudiantes de cuarto semestre de la Carrera de Ingeniería de Sistemas. Estamos realizando un
Sistema….., con la finalidad de contribuir a mejorar el proceso…….. De manera que su empresa pueda
realizar o continuar esta labor de una manera más efectiva.
A continuación le formularemos algunas preguntas que pretenden recopilar información…... Los datos
aportados serán de gran relevancia para nuestros propósitos y mantenidos en estricta confidencialidad.
¿Debido a la importancia de la información que nos proporcionará para nuestra investigación, permitiría
usted que la entrevista fuese grabada?
Si_____ No_____
……………………..
…………………….

3.4.2.3. Funciones de las preguntas
Hay variedad de preguntas de acuerdo a su función:
• Biográficas: ¿Desde cuándo viene participando en......?

• De experiencia: ¿Cómo acostumbra a planificar tu trabajo como encargado del control
del personal en su empresa?
• De sentimiento: ¿Cómo le gustaría que le supervisaran en su trabajo?
• De opinión: ¿Cómo ve usted el actual control de….?
• De información ¿Qué sugiere para integrar ……?
• De comprobación Acaba de decir..... ¿Eso significa que....?
• Ampliaciones: ¿Podría hablar con mayor detalle sobre este punto?
• Relanzamiento: ¿Antes dijo usted que.... ¿Podría hablarme de nuevo sobre este tema?
3.4.2.4. Requisitos para diseñar una entrevista
Es importante tomar en cuenta los siguientes requisitos para poder diseñar adecuadamente una
entrevista:
 Tener claro el objetivo a lograr mediante la entrevista.

 Pensar en la muestra apropiada de sujetos a quien se le aplicará. Por ser un instrumento que
exige mayor tiempo de aplicación, debe estar dirigida a un menor N° de personas pero que
sean significativas.
 Las preguntas han de ser claras, directas, sin intenciones ocultas.
 Practicar validación por expertos y prueba piloto respecto al guión de entrevista
3.4.2.5. Ventajas y desventajas de la entrevista
Ventajas:
• Amplio espectro de aplicación.

• No limita los temas a un espacio-tiempo.
• Es posible centrar el tema.
• Puede aplicarse en cualquier lugar y momento (Flexibilidad).
• Estandarización y representatividad de los resultados.
• Observación propia y ajena.
• Lectura de gestos y actitudes.
Desventajas
• Artificialidad de la situación de medición.

• Significados dados a las respuestas.
• Limitaciones en el lenguaje.
• Índices de no respuesta.
• Posibilidad de respuestas falsas.

3.4.3. LA ENCUESTA
La encuesta es una técnica de adquisición de información de interés sociológico y consiste en
realizar preguntas a un número apreciable de personas (muestra), mediante un cuestionario
previamente elaborado, a través del cual se puede conocer la opinión o valoración del sujeto
seleccionado en una muestra sobre un asunto dado.
En la encuesta a diferencia de la entrevista, el encuestado lee previamente el cuestionario y lo
responde por escrito, sin la intervención directa de persona alguna de los que colaboran en la
investigación.
La encuesta, una vez confeccionado el cuestionario, no requiere de personal calificado a la hora de
hacerla llegar al encuestado.
A diferencia de la entrevista la encuesta cuenta con una estructura lógica, rígida, que permanece
inalterada a lo largo de todo el proceso investigativo. Las respuestas se escogen de modo especial y
se determinan del mismo modo las posibles variantes de respuestas estándares, lo que facilita la
evaluación de los resultados por métodos estadísticos.
3.4.3.1. Características de la encuesta
 Permite establecer información primaria, concreta de la muestra seleccionada.

 Proporciona información respecto a la opinión de los encuestados, lo que provoca que los
resultados no sean cien por ciento exactos.
 Es un instrumento que recolecta información en determinado tiempo, por esta razón, ofrece
información respecto al objeto investigado en ese momento.
 Utiliza como instrumento base, el cuestionario.
 Requiere de la determinación estadística del tamaño y composición de la muestra.
3.4.3.2. Selección de la muestra
Población, es la totalidad del fenómeno a estudiar, donde las unidades de población poseen
una característica común, la que se estudia y da origen a los datos de la investigación.
Muestra, es un subconjunto representativo de la población, sobre los que recolectara los
datos. La muestra descansa en el principio de que las partes representan al todo y, por tal,
refleja las características que definen a la población de la que fue extraída, lo cual nos indica
que sea representativa.
Muestreo, es la técnica de selección de la muestra y el mismo puede ser de dos tipos:
- Probabilístico, aquel en el que todas las personas de una población a estudiar, tienen la
misma probabilidad de formar parte de la muestra. Entre estos se tienen:
 Simple, Precisa tener identificadas a todas las personas y consiste en seleccionarlas

una a una, es decir por sorteo total de la población.
 Sistemático, Aquí no se conoce la identidad de las persona, en este caso se
establece entre las mismas un orden de selección.
 Estratificado, toma la muestra de acuerdo estratos o categorías, es decir, selecciona

la muestra en función de la existencia de cierto carácter, por ejemplo: sexo(de
acuerdo a la cantidad, la selección es proporcional) , y a partir de ello, aplica
métodos de selección ya sea simples o sistemáticos.
 Por conglomerados, Los sujetos forman agrupaciones naturales.
- Muestreo no probabilístico, en este tipo de muestreo se desconoce la probabilidad de

cada sujeto que pertenece a la muestra y la selección de la misma, depende del
investigador y pueden ser expertos o los propios interesados. Aquí no todas las personas
tienen la misma probabilidad de formar parte de la muestra; los tipos de muestreos no
probabilísticos son:
 Causal, mayor accesibilidad a los sujetos.

 Intencional, el investigador decide que personas forman parte de la muestra, en
función a lo que posean, o algún criterio que desea analizar.
Finalmente se presentan a continuación algunos sitios web que permiten realizar el cálculo de
muestra:
 http://www.netquest.com/panel_netquest/calculadora_muestras.php
http://www.feedbacknetworks.com/cas/experiencia/sol-preguntar-calcular.html 
3.4.3.3. Información que se puede obtener por una encuesta
 Demográfica: Edad, sexo, estado civil, residencia, etc.

 Socioeconómica: Ocupación, salario, ingresos, escolaridad, movilidad social, etc.
 Conductas: Participación social, actividades culturales, innovación, hábitos políticos, etc.
 Opiniones, actitudes e imágenes sociales: Orientaciones afectivas, preferencias,
predisposiciones a actuar en favor o en contra, representaciones, creencias, etc.
3.4.3.4. Fases para la elaboración de la encuesta
Para poder elaborar adecuadamente es importante tomar en cuenta las siguientes etapas:
I. Determinar poblaciones y muestras.

II. Diseño y prueba de cuestionario.
III. Aplicación de cuestionario y recolección de datos.
IV. Análisis de los datos.

3.4.3.5. Ejemplos muestra de datos procesados
Conoce CCP/BZ ZR
Si 89,2% 74,7%
No 8,4% 23,1%
No responde 2,4% 2,2%
Total general 100,0% 100,0%
La siguiente figura muestra la

representación del análisis de una
pregunta cerrada dicotómica
3.4.3.6. Sitios Webs para elaborar encuestas
Finalmente se presentan algunos sitios Webs para poder elaborar encuestas:
http://www.e-encuesta.com/index.do
Google Drive
http://www.encuestafacil.com/
http://es.surveymonkey.com/

CAPITULO IV
METODOLOGÍAS PARA EL DESARROLLO DE SISITEMAS DE INFORMACIÓN
4.1. INTRODUCCIÓN
El software es un producto intangible el cual se logra a través de un proceso creativo ya que programar
es un arte, el cual no puede ser sistematizado del todo.
Ahora bien, en el proceso de desarrollo de software es primordial considerar la siguiente interrogante:
¿Por qué es importante el Desarrollo de Proyectos de forma Metodológica? , la respuesta implica
principalmente al hecho de que el software es cada vez más complejo y costoso que se compara con
construir un edificio, además que el uso de una metodología en cualquier trabajo de investigación es
esencial y necesario, de manera que se trabaje de manera ordenada y sistemática para el logro de los
objetivos del trabajo.
El presente capitulo presenta la descripción de un conjunto de metodologías que permitirán lograr este
cometido, el de desarrollar un sistema de información automatizado.
4.2. LA METODOLOLOGÍA PARA EL DESARROLLO DE SOFTWARE
Una metodología de desarrollo de software no es más que una serie de pasos que se realizan de forma
rigurosa tal que su resultado a partir de unos requisitos nuevos o modificados sea un software nuevo o
modificado. La metodología brinda un conjunto de pasos y procedimientos que deben seguirse para
desarrollar software.
En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuándo y
Cómo debe hacerlo.
La metodología de desarrollo de software está compuesta por:
 Cómo dividir un proyecto en etapas.
 Qué tareas se llevan a cabo en cada etapa.
 Qué restricciones deben aplicarse.
 Qué técnicas y herramientas se emplean.
 Cómo se controla y gestiona un proyecto

No existe una metodología de software universal. Las características de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el proceso sea configurable.
La gracia de una metodología es que aporta una garantía de calidad. ¡IMPORTANTE!
Un producto de software es de calidad si cumple rigurosamente con todos y cada uno de sus requisitos.
Es decir: calidad = requisitos satisfechos, gracias a esto podemos medir la calidad de un producto
basándonos en los requisitos iniciales.
La metodología aporta una forma de estimar y controlar costes. Así podemos saber cuánto vamos a
tardar en realizarlo y si nos sale o no rentable llevarlo a cabo antes de realizar la inversión completa de
tiempo, dinero y esfuerzo.
También evita una gran parte de los esfuerzos perdidos en rectificar fallos que se pueden evitar
utilizando una metodología adecuada.
4.3. EL PROCESO DE DESARROLLO DE SOFTWARE
Todo sistema de información debe ser elaborado en base a un proceso de desarrollo (como se mostró
en el capítulo II), el mismo que implica un conjunto de pasos necesarios para poder lograr el éxito del
proyecto, la adopción del mismo dependerá de la metodología a utilizar, entre las actividades de un
proceso genérico se tiene:
4.4. LA METODOLOGÍA Y EL-- CICLO DE VIDA
Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica
qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cómo hacerlo. La
metodología indica cómo hay que obtener los distintos productos parciales y finales.
Ciclo de Vida Metodología

4.5. CLASIFICACIÓN DE LAS METODOLOGÍAS
Las metodologías se clasifican en:

 Estructuradas.
o Orientadas a procesos
o Orientadas a datos
 No estructuradas.
o Orientadas a objetos
o Sistemas de tiempo real
4.5.1. Metodologías Estructuradas
Este tipo de metodologías Se basan en la forma top-down. Representan los procesos, flujos y
estructuras de datos, de una manera jerárquica, descendente y ven el sistema como entradas-
proceso-salidas.
Entre este tipo de metodologías se encuentran las metodologías orientadas a procesos y las no
orientadas a procesos, las mismas que se describen a continuación.
4.5.1.1. Metodologías orientadas a procesos
La ingeniería del software se basa en el modelo básico de entrada/proceso/salida de un

sistema. Está compuesta por:
 Diagrama de flujo de datos (DFD).
 Diccionario de datos.
 Especificaciones de proceso.
Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon.
4.5.1.2. Metodologías orientadas a datos
Son metodologías basadas en la información. Primero se definen las estructuras de datos y, a

partir de éstos, se derivan los componentes procedimentales.

Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr.
4.5.2. Metodologías No Estructuradas
4.5.2.1. Metodologías de tiempo real
Procesan información orientada al control más que a los datos. Se caracterizan por
concurrencia, priorización de procesos, comunicación entre tareas y acceso simultáneo a datos
comunes.
Ejemplo: Ward & Mellor 85, Hatley & Pirbhay 87, COMET (Concurrent Object Modeling and
architectural design mEThod).
4.5.2.2. Metodologías Orientadas a Objetos
La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos.

Tiene dos enfoques distintos:
 Revolucionario, puro u ortodoxo. Rompen con las metodologías tradicionales.
Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock, XP, Scrum.
 Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman

elementos de uno y otro tipo.
Ejemplos: metodología OMT de Rumbourgh. Rational Unified Process (RUP).
4.6. QUE METODOLOGÍA ELEGIR
La elección de la metodología dependerá en gran parte del tipo de sistema que se desea construir, sin
embargo, en la actualidad existen dos tipos principales de metodologías dentro de las metodologías
orientadas a objetos, las Ligeras y las Pesadas. Las primeras son metodologías extremadamente
prácticas que generalmente obvian gran parte de la documentación y están más preparadas para
utilizarse en proyectos cuyos requisitos cambiarán constantemente durante todo el proceso.
Las Metodologías Ágiles (AMs) valoran:
 Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las
herramientas.
 Desarrollar software que funciona más que conseguir una buena documentación 
Minimalismo respecto del modelado y la documentación del sistema.
 La colaboración con el cliente más que la negociación de un contrato.
 Responder a los cambios más que seguir estrictamente una planificación.
Las segundas (pesadas), son metodologías donde todo está mucho más controlado y se genera mas
documentación antes de proceder a implementar el proyecto, con mucho mayor peso del análisis y el
diseño sobre el proyecto. Estas últimas son más indicadas para proyectos grandes o cuyo rendimiento
y nivel de calidad son críticos para el éxito de éste.
4.7. LA METODOLOGÍA XP (EXTREME PROGRAMMING)
La Programación Extrema es una metodología ligera de desarrollo

de software que se basa en la simplicidad, la comunicación y la
realimentación o reutilización del código desarrollado.
Desarrollada por Kent Beck, cuyo principio se concentra en el

hecho de que: Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio
cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian.
Kent Beck menciona que “El problema no es el cambio en sí mismo, puesto que sabemos que el cambio
va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.”
4.7.1. Objetivos de XP
Entre los objetivos que persigue esta metodología, se puede mencionar:

 Obtención del producto, software funcionando, y con la satisfacción del cliente.
 Minimización del riesgo actuando sobre las variables del proyecto :
o Coste
o Tiempo
o Calidad
o Alcance

4.7.2. Valores que inspiran XP
La simplicidad consiste en desarrollar sólo el sistema que realmente

se necesita. Implica resolver en cada momento sólo las necesidades
actuales.
Con este principio de simplicidad, junto con la comunicación y el

feedback resulta más fácil conocer las necesidades reales
Una metodología basada en el desarrollo incremental de pequeñas

partes, con entregas y pruebas frecuentes y continuas, proporciona
un flujo de retro-información valioso para detectar los problemas o
desviaciones.
 De esta forma fallos se localizan muy pronto.

 La planificación no puede evitar algunos errores, que sólo se
evidencian al desarrollar el sistema.
 La retro-información es la herramienta que permite reajustar
la agenda y los planes.
 Disciplina en la aplicación de XP
 Parar cuando se está cansado
 Permitir que el usuario tome las decisiones de negocio
 Permitir que el desarrollador tome las decisiones técnicas
 Descartar código si es necesario
 Introducir cambios cuando las cosas no funcionan
XP pone en comunicación directa y continua a clientes y

desarrolladores. El cliente se integra en el equipo para establecer
prioridades y resolver dudas. De esta forma ve el avance día a día, y
es posible ajustar la agenda y las funcionalidades de forma
consecuente.
4.7.3. Roles de las personas participantes en XP
 Programador
◦ Pieza básica en desarrollos XP

◦ Más responsabilidad que en otros modos de desarrollo

◦ Responsable sobre el código
◦ Responsable sobre el diseño (refactorización=mejora del código, simplicidad)
◦ Responsable sobre la integridad del sistema (pruebas)
◦ Capacidad de comunicación (pair-programming)
◦ Acepta críticas (código colectivo)
 Cliente
◦ Pieza básica en desarrollos XP
◦ Define especificaciones (user stories)
◦ Influye sin controlar
◦ Confía en el grupo de desarrollo
◦ Define pruebas funcionales
 Encargado de Pruebas
◦ Apoya al cliente en la preparación/realización de las pruebas funcionales
◦ Ejecuta las pruebas funcionales y publica los resultados
 Encargado de Seguimiento(Tracker)
◦ Recoge, analiza y publica información sobre la marcha del proyecto sin afectar
demasiado el proceso
◦ Supervisa el cumplimiento de la estimaciones en cada iteración
◦ Informa sobre la marcha de la iteración en curso
◦ Controla la marcha de las pruebas funcionales, de los errores reportados, de las
responsabilidades aceptadas y de las prueba añadidas por los errores encontrados
 Entrenador (Coach)
◦ Experto en XP
◦ Responsable del proceso en su conjunto
◦ Identifica las desviaciones y reclama atención sobre las mismas
◦ Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza)
◦ Interviene directamente si es necesario
◦ Atajar rápidamente el problema
 Consultor
◦ Apoya al equipo XP en cuestiones puntuales
 Jefe del Proyecto
◦ Favorece la relación entre usuarios y desarrolladores
◦ Confía en el equipo XP
◦ Cubre las necesidades del equipo XP
◦ Asegura que alcanza sus objetivos

4.7.4. Fases de XP
Las fases que se siguen en el desarrollo de software con uso de XP se tienen:
1. El cliente define el valor de negocio a implementar

2. El programador estima el esfuerzo necesario para su implementación
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones
de tiempo
4. El programador construye ese valor de negocio
5. Vuelve al paso 1
4.7.5. Captura de requisitos en XP
En XP la herramienta utilizada para poder realizar la captura de requisitos del sistema es la

Historias del Usuario (User-Stories), cuyas características son los siguientes:
 Establecen los requisitos del cliente.
 Trozos de funcionalidad que aportan valor.
 Se les asignan tareas de programación con un nº de horas de desarrollo.
 Las establece el cliente.
 Son la base para las pruebas funcionales.
EJEMPLO:
4.7.6. Planificación en XP
La planificación XP toma en cuenta los siguientes aspectos:
 Planificación por entregas (releases)

 Se priorizan aquellas User-Stories que el cliente selecciona porque son más
importantes para el negocio

 Entregas:
o Son lo más pequeñas posibles
o Se dividen en iteraciones (iteración = 2 o 3 semanas)
o Están compuestas por historias
 A cada programador se le asigna una tarea de la user-story
4.7.7. La programación en XP
 La programación de tareas se realiza por parejas.

 La pareja diseña, prueba, implementa e integra el código de la tarea.
 Código dirigido por las pruebas.
 Código modular, intentando refactorizar siempre que se pueda.
EJEMPLO:
4.7.8. Tarjeta CRC (Clase- Responsabilidad-Colaborador)
Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las
responsabilidades de una clase son las cosas que conoce y las que realiza, sus atributos y
métodos. Los colaboradores de una clase son las demás clases con las que trabaja en conjunto
para llevar a cabo sus responsabilidades.
EJEMPLO:

4.7.9. Prácticas de XP
 Simplicidad de código y de diseño para producir software fácil de modificar.

 Reingeniería continua para lograr que el código tenga un diseño óptimo.
 Desarrollar estándares de codificación, para comunicar ideas con claridad a través del
código.
 Desarrollar un vocabulario común, para comunicar las ideas sobre el código con
claridad.
 Adoptar un método de desarrollo basado en las pruebas para asegurar que el código se
comporta según lo esperado.
 Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas.
 Asumir la propiedad colectiva del código, para que todo el equipo sea responsable de él.
 Integración continua, para reducir el impacto de la incorporación de nuevas
funcionalidades.

 Integración de un representante del cliente en el equipo, para encauzar las cuestiones
de negocio del sistema de forma directa, sin retrasos o pérdidas por intermediación.
 Adoptar el juego de la planificación para centrar en la agenda el trabajo más
importante.
 Entregas regulares y frecuentes para satisfacer la inversión del cliente.
 Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.
4.7.10. Ciclo de vida de XP
XP se encuentra basado en el ciclo de vida iterativo e incremental como lo muestra la siguiente

imagen:

4.8. METODOLOGÍA SCRUM
Scrum define un proceso empírico, iterativo e incremental de

desarrollo que intenta obtener ventajas respecto a los procesos
definidos (cascada, espiral, prototipos, etc.) mediante la aceptación
de la naturaleza caótica del desarrollo de software, y la utilización de
prácticas tendientes a manejar la impredictibilidad y el riesgo a niveles
aceptables. El mismo surge de un artículo de 1986 de la Harvard
Business Review titulado “The New New Product Development Game”
de Takeuchi y Nonaka, que introducía las mejores prácticas más utilizadas en 10 compañías japonesas
altamente innovadoras. A partir de ahí y tomando referencias al juego de rugby, Ken Scwaber y Jeff
Sutherland formalizan el proceso conocido como Scrum en el año 1995.
Scrum es un método iterativo e incremental que enfatiza prácticas y valores de project management
por sobre las demás disciplinas del desarrollo.
La complejidad de una melé hace que: Si un miembro del equipo se viene abajo, se cae toda le melé.
En consecuencia, los jugadores deben estar bien coordinados, apoyarse en sus compañeros para
empujar al mismo tiempo y con ello, avanzar a la misma velocidad.
Scrum se basa en la iteración y entrega incrementales de desarrollo de un producto o servicio. El cislo

de trabajo seguido por esta metodología se muestra en la siguiente figura:

4.8.1. Roles de las personas participantes en SCRUM
Cada persona que interviene en el proceso de creación de un producto o servicio tiene un rol
específico en SCRUM. En el ejemplo práctico veremos el papel que desarrolla cada uno y sus
funciones.
 Cliente, es la persona que necesita el producto, de quien se captura los requisitos.
 Dueño del producto, es el propietario del producto: es la persona respo-nsable de lograr

el mayor valor de producto para los clientes, usuarios y resto de implicados.
 Scrum Master: Responsable del fun-cionamiento de la metodología SCRUM en la

organización.es decir, es un miembro del equipo que tiene el papel de comunicar y
gestionar las necesidades del Dueño de Producto y la pila de Sprint.
 Equipo, es el Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto.
4.8.2. Elementos de SCRUM
 Pila del producto (product backlog)
Lista de requisitos de usuario que a partir de la

visión inicial del producto crece y evoluciona
durante el desarrollo.
Ejemplo:
 Pila del sprint(sprint backlog)
Lista de los trabajos que debe realizar el equipo

durante el sprint para generar el incremento previsto.
La pila de sprint tiene como utilidad fraccionar el

trabajo de un periodo de 15 días en tareas más
pequeñas, que tarden como mucho dos días.
Ejemplo:
 Incremento
Resultado de cada sprint

Finalmente se muestra un cuadro que muestra el funcionamiento de la metodología SCRUM.
4.9. METODOLOGÍA RUP (RATIONAL UNIFIED PROCESS)
Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un
producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar
tareas y responsabilidades dentro de una organización del desarrollo. Su meta es asegurar la
producción del software de alta calidad que resuelve las necesidades de los usuarios dentro de un
presupuesto y tiempo establecidos.
4.9.1. HISTORIA
El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson Approach)
elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el
concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y
lanza el proceso de desarrollo Objectory (abreviación de Object Factory).

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se
desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational
Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software
desarrolló e incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de
trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process
(RUP).
4.9.2. PRINCIPIOS DEL RUP
Esta metodología presenta los siguientes principios:
GUIADO POR CASOS DE USO
Guiado por casos de uso, debido a que Según Kru00, los Casos de Uso son una técnica de captura de
requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de
funciones que seria bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad
del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos
funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema.
También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento
integrador y una guía del trabajo como se muestra en la siguiente figura:
Los Casos de Uso integran el trabajo

Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor,
permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes
actividades del proceso de desarrollo.
Como se muestra en la Figura 3, basándose en los Casos de Uso se crean los modelos de análisis y
diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto
implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el
modelo de Casos de Uso.
CENTRADO EN LA ARQUITECTURA
La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que

permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una
perspectiva clara del sistema completo, necesaria para controlar el desarrollo (Kru, 2000).
La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está
relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a
determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración
elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe
ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma
software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como
sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención
al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante
cambios posteriores durante la construcción y el mantenimiento.
Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad
reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre los
Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a
cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y
en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo
durante todo el proceso de desarrollo de software. La siguiente imagen ilustra la evolución de la
arquitectura durante las fases de RUP. Se tiene una arquitectura más robusta en las fases finales del
proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio de baselines
y se va modificando dependiendo de las necesidades del proyecto.
Evolución de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo
que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del
sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1
de la arquitectura (Kru, 1995), el cual recibe este nombre porque lo forman las vistas lógica, de
implementación, de proceso y de despliegue, más la de Casos de Uso que es la que da cohesión a
todas.
ITERATIVO E INCREMENTAL
La estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se
divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y
arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo.
Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de
todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un
crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada como se muestra en la Figura 6. Se pasa por
los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una
planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración.
Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.
Una iteración RUP
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una
parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la
arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos
requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la
planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los
riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite
reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya
finalizado por completo con la versión actual del producto.
DESARROLLO BASADO EN COMPONENTES
La creación de sistemas intensivos en software requiere dividir el sistema en componentes con

interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta
característica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se
obtienen o se desarrollan sus componentes.
UTILIZACIÓN DE UML
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema
software. Es un estándar de la OMG (http://www.omg.org). Utilizar herramientas de modelado visual
facilita la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El
modelado visual también ayuda a mantener la consistencia entre los artefactos del sistema: requisitos,
diseños e implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad del equipo
para gestionar la complejidad del software.
PROCESO INTEGRADO
RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo
concluye con una generación del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio,
Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número de
iteraciones en cada fase es variable.
4.9.3. Ciclo de vida del RUP
Esta metodología utiliza el modelo tradicional en cascada y en cada iteración o ciclo incluye el modelo
iterativo e incremental, como se puede observar en la siguiente imagen:
Ciclos de vida del RUP

4.9.4. Fases del RUP
El RUP utiliza cuatro fases (Concepción – Elaboración – Construcción- Transición) para el desarrollo de
un sistema, cada una de las cuales se muestran de manera grafica y se describen a continuación:
CONCEPCIÓN
Esta fase tiene como objetivo el de definir la razón de ser y el alcance del proyecto. Estudio de
oportunidad.
Visión = QUÉ + PARA QUÉ + CUÁNTO
Actividades
 Especificación de los criterios de éxito del proyecto
 Definición de los requerimientos
 Estimación de los recursos necesarios
 Cronograma inicial de fases
Artefactos
 Documento de definición del proyecto
ELABORACIÓN
Esta fase permite establecer un plan de proyecto y una arquitectura correcta del sistema.
Actividades
 Análisis del dominio del problema
 Definición de la arquitectura básica
 Análisis de riesgos
 Planificación del proyecto
Artefactos
 Modelo del dominio
 Modelo de procesos
 Modelo funcional de alto nivel
 Arquitectura básica
CONSTRUCCIÓN
Permite desarrollar el sistema a lo largo de una serie de iteraciones

Actividades
 Análisis
 Diseño
 Codificación
 Pruebas (individuales, de integración)
TRANSICIÓN
Consiste en la transición del producto a la comunidad del usuario, es decir, esta fase se encarga de
garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
4.9.5. El lenguaje de Modelado Unificado (UML)
UML modela un sistema mediante el uso de objetos que forman parte de él así como, las relaciones
estáticas o dinámicas que existen entre ellos, puede ser utilizado por cualquier metodología de análisis
y diseño orientada por objetos para expresar los diseños.
Este lenguaje es el resultado de la unificación de principalmente los métodos de modelado orientados
a objetos de Booch, Rumbaugh (OMT: Object Modeling Technique) y Jacobson (OOSE: Object-
Oriented Sotfware Engineering), entre otros, como se muestra en la siguiente imagen:
ENFOQUES QUE AGLUTINA UML

¿Qué es un LENGUAJE DE MODELADO?

“Es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un
sistema” (Booch, Jacobson y Rumbaugh).
El Lenguaje de Modelado Unificado se encuentra basado en una notación gráfica la cual permite:
especificar, construir, visualizar y documentar los objetos de un sistema programado.
- Especificar
 Especificar es equivalente a construir modelos que cumplan las condiciones de no
ambigüedad y completitud.
 UML cubre la especificación del análisis, diseño e implementación de un sistema software.
- Visualizar
 Símbolos con semántica bien definida.
 UML transciende al lenguaje de programación.
 Modelo explícito, que facilita la comunicación.
- Construir
 Es posible hacer corresponder con los lenguajes de programación (Java, C#, B.Datos, etc.).
- Documentar
 UML cubre la documentación de un sistema:
 Requisitos  Planificación
 Arquitectura  Pruebas
 Diseño  Prototipos
 Código fuente  Versiones
ACTORES O ROLES
Son los personajes encargados de la realización de las actividades definidas dentro de los flujos de
trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categorías: Analistas,
Desarrolladores, Probadores, Encargados, Otros actores. A continuación se presenta una lista de
actores de acorde a las categorías mencionadas con anterioridad:
Analistas Desarrolladores
 Analista del Proceso del Negocio  Arquitecto
 Diseñador del Negocio  Revisor de la Arquitectura
 Revisor del Modelo del Negocio  Diseñador de Cápsulas
 Revisor del Código y Revisor del
 Revisor de Requerimientos
Diseño
 Analista del Sistema  Diseñador de la Base de Datos
 Especificador de Casos de Uso  Diseñador
 Diseñador de Interfaz del Usuario  Implementador y un Integrador

Encargados Otros…
 Encargado de Control del Cambio  Cualquier trabajador
 Encargado de la Configuración  Artista Gráfico
 Encargado del Despliegue  Stakeholder
 Ingeniero de Procesos  Administrador del Sistema
 Encargado de Proyecto  Escritor técnico
 Revisor de Proyecto  Especialista de Herramientas
Probadores Profesionales
 Diseñador de Pruebas
 Probador
MODELOS Y DIAGRAMAS
Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el
producto desde cada una de las perspectivas de interés
El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin
embargo, se requieren otros modelos.
Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de
trazabilidad entre los diferentes modelos
 Modelo: Captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema,
considerando un cierto propósito.
Modelo
Un modelo es
una
simplificación
de la realidad.

Las vistas que presenta UML se presentan en la siguiente imagen:

Organización de modelos de UML
El RUP propone la utilización de los modelos para la implementación completa de todas sus
fases respectivamente con sus disciplinas:
 Modelo de Casos de Uso del Negocio: Describe la realización del Caso de Uso, es
realizado en la disciplina de Modelado del Negocio.
 Modelo de Objetos del Negocio: Se utiliza para identificar roles dentro de la
organización, es realizado en la disciplina de Modelado del Negocio.
 Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y su ambiente,
además sirve como un contrato entre el cliente y los diseñadores. Es considerado
esencial al iniciar las actividades de análisis, diseño y prueba; este modelo es realizado
en la disciplina de Requerimientos.
 Modelo de Análisis: Contiene los resultados del análisis del Caso de Uso, y contienen
instancias del artefacto de Análisis de Clases; es realizado en la disciplina de Análisis y
Diseño.
 Modelo de Diseño: Es un modelo de objetos que describe la realización del Caso de
Uso, y sirve como una abstracción del modelo de implementación y su código fuente,
es utilizado como entrada en las actividades de implementación y prueba; este modelo
se realizado en la disciplina de Análisis y Diseño.
 Modelo de Despliegue: Muestra la configuración de los nodos del proceso en tiempo
de ejecución, muestra los lazos de comunicación entre estos nodos, así como las de los
objetos y componentes que en él se encuentran; se realizado en la disciplina de Análisis
y Diseño.
 Modelo de Datos: Es un subconjunto del modelo de implementación que describe la
representación lógica y física de datos persistentes en el sistema. También incluye
cualquier conducta definida en la base de datos como disparadores, restricciones, etc.
Es elaborado en la disciplina de Análisis y Diseño.
 Modelo de Implementación: Es una colección de componentes, y de subsistemas de
aplicación que contienen estos componentes, entre estos están los entregables,
ejecutables, archivos de código fuente. Es realizado en la disciplina de Implementación.

 Modelo de Pruebas: Es utilizado para la elaboración de las pruebas, y se realiza en la

disciplina de Pruebas.
Estos modelos representan los diagramas que propone el UML para el desarrollo de modelado
de un proyecto de software, con los cuales se puede representar los propuesto por UML
mediante la metodología RUP utilizando las herramientas que esta provee para la
implementación fácil, clara y estructurada de los diagramas utilizados.
 Diagrama: Representación gráfica de una colección de elementos de modelado, a menudo

dibujada como un grafo con vértices conectados por arcos.
Diagramas de UML
DIAGRAMAS DE UML
1) Diagrama de Casos de Uso: modela la

funcionalidad del sistema agrupándola en
descripciones de acciones ejecutadas por un
sistema para obtener un resultado.
Ejemplo
2) Diagrama de Clases: muestra las clases

(descripciones de objetos que comparten
características comunes) que componen el sistema
y cómo se relacionan entre sí.
 Ejemplo

3) Diagrama de Objetos: muestra una serie de objetos

(instancias de las clases) y sus relaciones.
Ejemplo
4) Diagramas de Comportamiento: dentro de estos

diagramas se encuentran:
- Diagrama de Estados: modela el
comportamiento del sistema de acuerdo con
eventos.
Ejemplo
- Diagrama de Actividades: simplifica el

Diagrama de Estados modelando el comportamiento
mediante flujos de actividades. También se pueden
utilizar caminos verticales para mostrar los responsables
de cada actividad.
 Ejemplo
5) Diagramas de Interacción: Estos diagramas a su

vez se dividen en 2 tipos de diagramas, según la
interacción que enfatizan:
- Diagrama de Secuencia: enfatiza la

interacción entre los objetos y los mensajes
que intercambian entre sí junto con el orden
temporal de los mismos.
Ejemplo

- Diagrama de Colaboración:
:Socio
igualmente, muestra la interacción entre los
:Video objetos resaltando la organización
2: verificar situación socio
estructural de los objetos en lugar del orden
1: prestar(video, socio)
:WInPréstamos
3: verificar situación video
de los mensajes intercambiados.
5: entregar recibo
: Encargado 4: registrar préstamo  Ejemplo
:Préstamo
Tecnico de
Almacen.frm
6) Diagramas de implementación Atender Pedido Consultar Pedidos no

CU08.frm Atendidos CU05.frm
- Diagrama de Componentes: muestra la

organización y las dependencias entre un Asignar
Stock.frm
Incidencia Pedido
CU07.frm
conjunto de componentes.
Consultar
Incidencias.frm
Ejemplo
Consultar Detalles
Incidencia.frm
<<Nodo ATM>> <<Nodo ATM>> <<Nodo ATM>> <<Nodo ATM>>

Marketing Contabilidad / Logística Recursos
Facturación Humanos
<<Nodo ATM>>
Encargado de
- Diagrama de Despliegue:
Transportes
Component
Diagram:
Component
<<Servidor Central>>
Base de Datos
Central
muestra los dispositivos que se encuentran en
View / Diagrama
de Paquetes <<Nodo ATM>>
Almacén Regional
un sistema y su distribución en el mismo.
<<Nodo ATM>> <<Nodo ATM>>

 Ejemplo
Representante de Operadora
Ventas Component
Diagram:
Gestión de
Almacén /
Diagrama de
Almacen
Component Component
Diagram: Gestión Diagram: Gestión
de Ventas / de Ventas /
Diagrama de Diagrama de
Ventas Ventas
4.9.6. El modelado del negocio

El modelado del negocio permite capturar y presentar el contexto del negocio del sistema. Los
artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del
sistema, es decir, aporta elementos esenciales para poder determinar los requisitos del sistema, tal
como se puede observar en la siguiente imagen:
Modelado del negocio e ingeniería de requisitos
¿POR QUÉ ES NECESARIO MODELAR EL NEGOCIO?
Es importante modelar el negocio debido a que se necesita identificar con facilidad, donde están los
problemas u oportunidades de crecimiento y mejora del mismo.
Otro aspecto a considerar, es que resulta necesario modelar los procesos del negocio ya que desde la
perspectiva de los sistemas, no es conveniente automatizar procesos que no estén claramente
definidos.
OBJETIVOS DEL MODELADO DEL NEGOCIO
 Comprender la estructura dinámica de una organización en donde el sistema a desarrollar va a ser

instalado.
 Comprender los problemas actuales de la organización e identificar su potencial de crecimiento y
mejoras.
 Asegurar que los clientes, usuarios finales y desarrolladores tengan un entendimiento común del
objeto de estudio.
 Determinar los requerimientos necesarios para dar soporte a la organización.
EL MODELO DE CASOS DE USO DEL NEGOCIO
El modelo describe el negocio en términos de casos de uso del negocio “business use cases” que se
corresponden con lo que comúnmente se conoce como “procesos”.
Forman parte de este modelo:

 La vista externa
o Actores y casos de uso del negocio (CUN) (Business Actors y Business Use Cases)
o Diagramas de casos de uso del negocio.
 La vista interna
o Especificación de cada CUN.
o Objetos del negocio.
o Diagramas de actividades (workflow) para cada CUN.
OBJETIVOS DEL NEGOCIO
Es un requisito que debe ser satisfecho por el negocio. Describe el valor deseado de
una medida en particular a futuro, y se utiliza para planear y administrar las
actividades del negocio.
Business Goal
Ejemplo: “Incrementar en un 50% para finales de año, las ventas en Potosí”.
ACTORES DEL NEGOCIO
El actor del negocio “Business Actor” representa un rol que alguien o algo en el entorno del sistema
puede realizar puede realizar una relación con el negocio, es decir, son aquellos que participan de las
actividades del negocio.
Es importante mencionar, que existen dos tipos de actores en el modelo del negocio, los actores
internos ( busines worker) y los actores externos (Busines Actor).
Notación:
 Actor Interno (business Worker)
El Actor Interno o Bussines Worker, es aquel trabajador del negocio que

participa de las actividades del mismo ayudando o colaborando en el logro
de la misión y visión de este. Por lo general estos actores pueden ser: Contador
- Secretarias
- Contadores
- Administradores
- vendedores
- Gerentes
- Otros…
Los trabajadores del negocio tiene

roles dentro del negocio, puestos o
cargos dentro de la empresa,
personas que ejecutan procesos o
actividades del negocio, asimismo,
podrían ser hardware o sistemas informáticos dentro del negocio usados en ese momento.

Actor Externo (Business Actor) Notación:
El actor externo o Business Actor, es aquel que no trabaja en el negocio, sin

embargo interactúa con el mismo, ya sea dando o recibiendo algo (producto o
servicio) de este. Por lo general estos actores del negocio pueden ser: Cliente
- Clientes (los beneficiarios o afectados por el proceso)

- Proveedores
- Autoridades (entidades legales, reguladoras, etc.)
- Sistemas de información localizados fuera del negocio.
- Miembros de la organización externos al ámbito del negocio.
CASOS DE USO DEL NEGOCIO Notación:
Un caso de uso del negocio “Business Use Case”, es un proceso servicio del negocio que
produce un resultado de valor medible y esperado por un actor(o actores) en particular.
Representa la secuencia de actividades desarrolladas para lograr ese valor. Vender Producto
¿Cómo encontrar casos de uso del negocio?
- Para poder encontrar casos de uso del negocio se debe identificar las necesidades puntuales del
actor externo o business actor y qué conjunto de actividades se realizan para poder satisfacerlo.
- Identificar los resultados y entregas que tiene la empresa y, a partir de ellos, a los procesos que
los realizaron.
- Reconocer los procesos primarios y secundarios del negocio.
o Procesos primarios
 En primer lugar se encuentran las actividades comerciales importantes o
vitales del negocio que usualmente se llaman “business processes”.
 Son los procesos dirigidos al cliente. Ejemplo:
o Procesos secundarios Vender Producto
 Son actividades de soporte o apoyo, que no son importantes desde el

punto de vista comercial pero que se deben efectuar de todos modos para
hacer que el negocio camine. En esta categoría está: la
administración del sistema, la limpieza, la seguridad, etc.
Ejemplo:
Inventariar Producto
 Dentro de esta categoría también está el trabajo

administrativo. Estos casos de uso muestran el tipo de
trabajo que afecta el cómo los procesos son llevados
a cabo. Ejemplo: Pagar Remuneraciones a Empleados
¿Recomendaciones para encontrar casos de uso del negocio?
 Es recomendable comenzar con el más importante actor del negocio: El cliente.

 Preguntas frecuentes:
o ¿Cuáles son los principales servicios que el cliente obtiene del negocio?
o ¿Cuál es el ciclo de vida del cliente? un buen consejo es estudiar el ciclo de vida del
cliente ( y los objetivos parciales e intermedios que se va logrando en el tiempo).
o ¿Cuáles son las características principales de soporte a los negocios y cuando se
dan?en estos grupos de características se pueden hallar casos de uso del negocio.
o ¿Cuáles son los procesos que ayudan a tomar decisiones estratégicas?
 Para completar la definición se debe:
o Desarrollar y abastecerse de información acerca de nuevas tendencias del negocio a
los dueños o inversionistas.
o Identificar y establecer metas presupuestales a mediano y largo plazo.
o Coordinar y asignar prioridad entre los casos de uso del negocio.
o Guías de supervisión.
DIAGRAMAS DE CASOS DE USO DEL NEGOCIO
 Los diagramas de casos de uso del negocio muestran la agrupación de procesos en paquetes
(grandes procesos) y la descomposición de los mismos en casos de uso de negocio.
 Muestran la interacción de actores y casos de uso de negocio.
 Muestran el contexto del negocio.
Consideraciones a tomar en cuenta para elaborar los diagramas de casos de uso:
o Los negocios se hacen y construyen para satisfacer los requerimientos de sus usuarios.
o Si un modelo de casos de uso tiene procesos que no son requeridos por nadie, puede estar
reflejando que algo malo está ocurriendo….pero existen excepciones…
o Los casos de uso administrativos y de soporte no necesariamente están conectados con
Business Actor, no obstante, dependen de un evento interno que los dispare.
o Cada caso de uso del negocio primario debe tener una relación de comunicación o vínculo
con un actor del negocio. Ejemplo:
Caso de Uso
Actor
Es importante mencionar que a este tipo de relación (actor<-->Caso de uso) se denomina

asociación.
o Los casos de uso presentan relaciones tales como:
 Relación de inclusión <<include>>, permite representar el hecho de que una
instancia del Caso de Uso origen incluye también el comportamiento descrito por el
Caso de Uso destino, es decir, es la inserción de un caso de uso adicional a un caso de
uso origen. Ejemplo:

<<include>>
Caso de uso Origen Caso de uso destino
 Relación de extensión <<extend>>, representar el hecho de que el Caso de Uso

origen extiende el comportamiento del Caso de Uso destino, representan una
conducta opcional, varios flujos diferentes que pueden ejecutarse. Ejemplo:
<<extend>>
Caso de uso Origen Caso de uso destino
 Generalización, representa una relación entre un caso de uso general y un caso de uso
más específico que hereda y añade propiedades de aquel.
Caso de uso general Caso de uso específico
Ejemplo: En el libro El lenguaje de modelado Unificado, manual de referencia, se muestra el siguiente.

Ejemplo:
Relaciones entre casos de uso
Solicitar catálogo sabe

donde va dentro de
Hacer Pedido, pero
hacer pedido, no sabe. Solicitar Catalogo
<<extend>>
Hacer Perdido
Vendedor Cliente
<<include>> <<include>>
<<include>>
Estas inserciones o
inclusiones son
excplicitas en
hacer pedido.
Proporcionar Datos Cliente Organizar Pago

Pedir Producto
estos casos de uso

son variantes de
Organizar Pago.
Pago Contado Pago Crédito
Fuente: (Rumbaugh J, Jacobson I, Booch G., 2002, P. 161)

DESCRIPCIÓN DE LOS CASOS DE USO DEL NEGOCIO
Objetivos:
 Describir a detalle el flujo de actividades de cada uno de los CUN.

 Asegurarse que los actores del negocio obtengan el resultado esperado.
 Asegurarse que los miembros del proyecto y los clientes y usuarios finales tengan un
entendimiento común del proceso detallado.
 Se utilizan dos artefactos para la documentación:
o Documento de especificación de CUN.
o Diagrama de actividades (UML)
o Diagrama de objetos del negocio.
ESPECIFICACION DE LOS CASOS DE USO DEL NEGOCIO
Para realizar la especificación de los CUN, se deben tomar en cuenta los siguientes aspectos:
 Actores
o Se indican los actores que participan en el
CUN.
o Deben coincidir con los indicados en los
Diagramas de CUN.
 Propósito
o Indicar el objetivo principal del CU.
o Breve descripción
o Se redacta un resumen de los principales
actividades que se realizan en el CUN.
o Es suficiente un párrafo.
o Debe incluirse al comienzo un PUNTO DE
INICIO.
 Se establece al inicio del resumen.
 Coincide con la primera actividad del CUN.
 Se debe enunciar: “Este caso de uso se inicia cuando…”
 Está delimitado por la ocurrencia de algún evento externo al negocio o debido a una
necesidad del actor.
o Debe incluirse al final un PUNTO DE TERMINACIÓN.
 Se redacta al final del resumen.
 Coincide con la última actividad del CUN.
 Se enuncia: “este caso de uso termina cuando….”
 Flujo básico de eventos

o Se describe la secuencia de actividades o pasos básicos normales e invariables que realiza el
proceso del negocio.
o Describe QUE hace el actor y que responde el proceso de negocio y no CÓMO se implementa.
o Se establece un diálogo entre el actor y el proceso de negocio, ordenado por la secuencia de
ocurrencia.
o El primer evento coincide con el Punto de Inicio.

o El último evento coincide con el Punto de Terminación.

o Al final debe haberse alcanzado el propósito del CUN.
 Flujos alternos
o Se consideran las diferentes situaciones situaciones alternativas o variantes que provoquen
una desviación del flujo básico.
o Condiciones ocasionales, eventuales, anormales y extremas.
o Debe expresar claramente:
 Evento del flujo básico que lo provoca.
 Condición bajo la cual ocurre.
 Conjunto de actividades alternativas.
 Cómo continúa la ejecución de los casos de uso una vez culminado el flujo alternativo.
 Precondiciones
o Son condiciones en las que debe encontrarse el negocio para que el CU pueda ser activado.
o Se definen relativas al negocio, no a su entorno.
o Si no se cumplen, se rechaza la activación del caos de uso.
o Den ser redactadas en tiempo verbal presente.
 Poscondiciones
o Son condiciones en las que deberá encontrarse el negocio junto a su entorno una ves
terminado el CU.
o Definen los resultados esperados por los CU.
o Deben redactarse en tiempo verbal pasado.
De manera gráfica se muestra lo mencionado anteriormente:
Notación:
LAS ENTIDADES DEL NEGOCIO
Una entidad del negocio “Business Entity” representa un conjunto de información con
propiedades, comportamiento y semántica similares y que es usada, producida o
manejada por trabajadores del negocio cuando ejecutan un CUN. Las entidades
pueden ser tangibles o intangibles. Solicitud de pago
Ejemplo:
 Producto
 Factura
 Guía de remisión
 Pago de crédito
 …

¿Dónde encontrar entidades del negocio?
 En la información manejada por el trabajador del negocio.

 Información que necesita ser ingresada, validada, consultada o comunicada en cada proceso
del negocio.
 Objetos físicos.
 Transacciones.
 Informes
 Reportes
 Documentos
Sugerencias para identificar entidades del negocio:
- Participa en al menos un CUN.
- Pueden ser usadas por diferentes trabajadores.
- Representan documentos, contratos, información solicitada, producto, conocimiento, etc.
- Solo debe ser considerada información relevante y persistente en el negocio.
Recomendaciones:
-El nombre y la descripción deben ser claros y comprensibles.
-Cada entidad del negocio es usada por al menos un CUN
-Cada relación entre entidades es usada en algún caso de uso por lo menos.
-Todas las entidades tienen un propietario que puede ser un actor interno o un actor
externo.
DIAGRAMA DE CLASES DEL NEGOCIO
El Diagrama de Clases del Negocio es Una herramienta proporcionada por UML. Muestra los
trabajadores del negocio y las entidades del negocio así como las asociaciones entre los mismos. Solo
se tiene en cuenta “¿QUIÉN manipula QUÉ información?” ¿QUIÉN? (trabajador del negocio
identificado). ¿QUÉ? (entidad del negocio identificado). Relaciones entre ellos (asociaciones). Se le
llama también diagrama de objetos de negocio. Ejemplo:
Diagrama de clases del negocio

DIAGRAMA DE ACTIVIDADES
El diagrama de actividades es una herramienta proporcionada por UML. Un diagrama de actividades
(DA) detalla el flujo de trabajo (workflow) de un CUN o por sus siglas en ingles BUC. Un BUC consiste de
una secuencia de actividades que juntas producen algo de valor para un business actor. Un workflow
usualmente consiste de un flujo básico y uno o muchos flujos alternativos.
Diagrama de actividades es útil para indicar en un proceso: Las tareas a realizar. La secuencia de
ejecución de las tareas. La interacción entre los actores y trabajadores. La forma en que el proceso
maneja las entidades. Modela la dinámica de casos de uso del negocio. Abarca tareas automáticas y
manuales.
El Diagrama de Actividades está compuesto por los elementos siguientes:
 Estado inicial (start state). Representa el inicio de un workflow. Existe un único estado inicial.
Se coloca dentro del swimlane correspondiente al rol que comienza el caso de uso. Se
representa a través de un círculo de color negro.
 Actividad (activity)
Representa el desarrollo de una actividad o paso dentro de un workflow. El
Actividad nombre de la actividad debe: Ser simple y breve. Ser un verbo o frase verbal
en infinitivo. Incluir el objeto de la actividad. Colocarse dentro del símbolo de
la actividad Buscar los datos del cliente
 Transición de estado (state transition)
Señala la dirección en que fluyen las actividades. Representa la secuencia de
Actividad 1
cada elemento dentro del diagrama. Es navegable en un solo sentido. Ocurre
Actividad 2 cuando termina el elemento que la precede en el diagrama. Se representa a
través de una línea con saeta en el extremo indicando el sentido de la
transición entre los elementos.
 Estado transitorio
Representa tiempos de espera en un proceso. Es útil para representar los
tiempos muertos. Se representa con un rectángulo con las aristas
redondeadas.
 Decisión (decision)
Representa una pregunta o decisión dentro del proceso. Ramifica el curso
del diagrama en dos o más caminos diferentes. Debe nombrarse tal y como
se hace en el negocio. Se acompaña de la pregunta que debe hacerse el
proceso para tomar la decisión. También se puede usar la decisión cuando se
quieren juntar hilos de flujos (OR) y combinarlos de nuevo. Se representa
con un rombo.
 Barra de sincronización (synchronization)
Se utiliza para mostrar subflujos paralelos Ramifica el curso del diagrama en
múltiples caminos que se ejecutan a la misma vez. Permite mostrar caminos
concurrentes dentro del proceso. Señala el inicio y/o fin de hilos de ejecución.

Permiten mostrar caminos concurrentes dentro de un workflow. Se representa a través de una

barra horizontal o vertical.
 Rol o calle (swimlane)
Un diagrama de actividad puede estar particionado en swimlanes usando líneas
ss
rectas verticales. Cada calle representa una parte del workflow cuya
Swimlane
responsabilidad esta a cargo de una parte de la organización. Se utiliza para

mostrar un rol que participa en el proceso. Puede representar a un actor o
trabajador del negocio que participa en el proceso modelado por un caso de
uso. Se representa a través de líneas verticales desde la parte superior del diagrama hasta el
final. Se coloca el nombre del rol en la parte superior. El orden de presentación de los
swinlanes no tiene significado semántico. Cliente .
 Estado final (end state)
Representa el fin de un flujo de actividades en el workflow. Se coloca dentro del
swimlane correspondiente al rol que termina el caso de uso. Puede haber más de un
estado final. Se representa a través de un círculo de color negro dentro de un círculo
transparente.
 Uso de objetos
En los workflows En este contexto los flujos de objetos son usados para mostrar
como las entidades de negocio son creadas y usadas en un workflow. Los flujos
: Objeto de objetos permiten mostrar inputs y outputs desde actividades.
Diagrama De Actividades Del Negocio
Responsable Area Jefe Area Director Financiero Prov eedor Almacenero Encargado de Inv entarios
Solicita
Compra
Diligencia
Solicitud
Solicitud Autoriza Cotiza

Solicitud Solicitud
Crea Orden de Cotización

Compra
Orden Compra Aprueba Realiza la Compara

Orden Compra Entrega Bienes Solicitud
Verifica
Factura
Datos no son
correctos
Si datos
correctos
Registra Entrada
de almacen
Registro
Entrada
Verifica Datos de la Codifica Bien

Bienes entregados
Si decide Controla ubicación

distribuir bien del Bien
Reguistra Salida
de Alamacen
Registro
Salida
Recibe el Bien Entrega Bien

4.9.7. Determinación de requerimientos
La tarea más difícil de construir un sistema del software es precisamente decidir qué construir. Ninguna otra parte del
trabajo conceptual es tan difícil como establecer los requisitos, incluyendo todas las interfaces a las personas, a las máquinas,
y otros sistemas del software. Ninguna parte del trabajo lesiona tanto al sistema resultante si hace mal. Ninguna otra parte es
más difícil rectificar después."[Brooks, No Silver Bullets, 1987].
Un requisito es una condición o capacidad que debe cumplir o poseer un sistema o componente de
un sistema para satisfacer un contrato, standard, o especificación o algún otro documento impuesto.
El conjunto de requisitos forma la base para el desarrollo de un sistema o una componente de sistema.
Un requisito podría describir:
 Una facilidad a nivel usuario Ej.: ‘el procesador de palabras debe incluir un verificador de
ortografía y un comando de corrección’.
 Una propiedad muy general del sistema Ej.: ‘el sistema debe asegurar que la información
personal nunca se haga disponible sin autorización’.
 Una restricción específica del sistema. Ej.: ‘el sensor debe ser activado 10 veces por segundo’
 Una restricción para el desarrollo del sistema. Ej.: ‘el sistema debe ser desarrollado usando
C++’.
 Cómo llevar a cabo algún cálculo. Ej.: ‘la nota final debe ser calculada sumando las notas del
examen, proyecto y cursada del estudiante basado en la siguiente fórmula nota final =
nota_exam + 2 * nota_proy + 2/3 * nota_cursada’.
DETERMINACIÓN DE REQUERIMIENTOS
Es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras. Para
poder logra esto, es importante interrogarse de la siguiente manera:
 ¿Cuál es el proceso básico de la empresa?
 ¿Qué datos utiliza o produce este proceso?
 ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
 ¿Qué controles de desempeño utiliza?
Tipos de requisitos:
FUNCIONALES:
 Definición de los servicios que un sistema debe
 proveer, sus comportamientos a las diferentes
 entradas y situaciones.

Ejemplos: El sistema deberá almacenar la información de las ventas; el sistema deberá

poder desplegar la historia clínica en cualquiera de los nodos de acceso; el sistema deberá
registrar cualquier acceso o modificación sobre una historia clínica
Categorías de las funciones:
Categoría Significado
Evidente Debe realizarse y el usuario debería saber que se ha

realizado.
Oculta Debe realizarse aunque no sea visible para el usuario.
Superflua Opcionales; su inclusión no repercute significativamente

en el costo ni otras funciones.
Ejemplo:
Ref. # Función Categoría
R 2.1 Maneja los pagos en efectivo, capturando la cantidad evidente

ofrecida y calculando el saldo deudor.
R 2.2 Maneja los pagos a crédito, capturando la información evidente

crediticia mediante manuablemente y autorizando los pagos
con el servicio de autorización (externa) de créditos de la
tienda a través de una conexión por modem. evidente
R 2.3 Registra los pagos en el sistema de cuentas por cobrar, pues oculta
el servicio de autorización de crédito debe a la tienda el
monto del pago.
NO FUNCIONALES:

Ejemplo:
Atributo Detalles y restricciones de frontera
Tiempo de respuesta (restricción de frontera) Cuando se registre un producto vendido, la

descripción y el precio aparecerán en un segundo.
Metáfora de interfaz (detalle) Ventanas orientadas a la metáfora de un formulario y cuadros de

diálogo.
(detalle) Maximiza una navegación fácil con teclado y no con mouse.
Tolerancia a fallas (restricción de frontera) Debe registrar los pagos a crédito autorizados
que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun
cuando se produzcan fallas de energía o del equipo.
plataformas del sistema operativo (detalle) Microsoft Windows XP, vista o Windows 7.

5. BIBLIOGRAFÍA
1. Alves André. Conceitos E Características Dos Sistemas ERP.[en linea]. Visto 27 de febrero de
2013. URL:http://informacaoesistemas.blogspot.com/2009/11/conceitos-e-caracteristicas-
dos.html . 2009.
2. Burgos C. Ma. Soledad. Clasificación de los Sistemas de información. [En línea]. visto 03 de
febrero de 20012. URL:
http://introinfordesasunefa.files.wordpress.com/2012/05/clasificaci_n_de_los_sistemas_de_infor
maci_n.pdf. chile.2011.
3. Janeth. Justanother WordPress.com site.SistemaExpeerto para el Diagnóstico de Tuberculosis.

[En línea]. Visto 10 de febrero de 2013. URL:
http://jane15cl.wordpress.com/2011/04/04/sistema-experto-para-el-diagnostico-de-la-
tuberculosis/. 2011.
4. James A. Senn. Análisis Y Diseño De Sistemas De Información. Prentice Hall:Mexico; 1992.

5. Guilarte María. Sistemas de apoyo a la toma de decisiones. [En línea]. Visto 26 de febrero de
2013. URL:http://apoyotomadedecisiones.blogspot.com/2010_01_01_archive.html. 2010.
6. International Conference on eXtreme Programming and Agile Methods in Software

Development (XP200x).[En linea].Visto 26 de junio de 2012. URL sdisponible en:
http://www.xp2003.org
7. I. T. Hawryszkiewycz. Introducción Al Análisis Y Diseño De Sistemas. Rama;1986.
8. Kendall & Kendall. Análisis Y Diseño De Sistemas. Prentice-Hall:Mexico;1998.
9. Laudon K. Y Laudon J. 1996. Administración de los Sistemas de Información. 3era. Edición. Pág:
426 .
10. Letelier Patricio. Metodologías ágiles y XP. [Diapositiva]. Departamento de Sistemas
Informáticos y Computación. Universidad Politécnica de Valencia. 50 Diap.
11. Rumbaugh J, Jacobson I, Booch G., El Lenguaje e Modelado Unificado. 2ª. Ed. Perarson Addison
Manual de Referencia, Pearson Addison Wesley: Madrid; 2002. P. 161.
12. Senn J. 1992. Análisis y Diseño de Sistemas de Información. 2da. Edición. Pág: 33.
13. Sage A. Y Palmer. J. 199_. Software SystemsEngineering.Pág: 48.
14. Whitten J., Bentley L., Barlow V. 1996. Análisis y Diseño de Sistemas de Información. 3era.
Edición. Pág: 95.
15. XP Agile Universe. [en linea]. Visto en fecha 20 de Junio de 2012. URL disponible en:
http://www.agileuniverse.com
16. Yourdon Edward. 1993. Análisis Estructurado Moderno. Prentice-Hall:Mexico; 1989.Pág: 86.
17. Ulloa Yomberdith.Clasificación de los sistemas de información. [En línea]. Visto 25 de febrero de
2013. URL: http://yomberdithstyles.blogspot.com/. Maracaibo:Venezuela; 2010.

TABLA DE CONTENIDO
INTRODUCCIÓN ........................................................................................................................................................... 1
CAPITULO I ................................................................................................................................................................... 2
INTRODUCCIÓN AL ANÁLSIS DE SISTEMAS .................................................................................................................. 2
1.1. INTRODUCCIÓN .......................................................................................................................................... 2
1.2. ANÁLISIS ..................................................................................................................................................... 3
3.1.1. PRINCIPIOS DEL ANÁLISIS .................................................................................................................. 3
3.1.2. EL ANALISTA DE SISTEMAS ............................................................................................................... 4
3.1.3. ROLES DE L ANALISTA DE SISTEMAS.................................................................................................. 5
1.3. DISEÑO ....................................................................................................................................................... 6
3.1.4. PRINCIPIOS DEL DISEÑO .................................................................................................................... 6
1.4. SISTEMA ..................................................................................................................................................... 6
1.4.1. ELEMENTOS DE UN SISTEMA ................................................................................................................. 7
1.5. SISTEMA DE INFORMACIÓN ....................................................................................................................... 8
1.6. COMPONENTES DE UN SISTEMA DE INFORMACION ................................................................................. 8
1.7. LOS SISTEMA DE INFORMACION AUTOMATIZADOS .................................................................................. 9
1. UN SI NO NECESITA, PARA EXISTIR, ESTAR OBLIGATORIAMENTE BASADO EN EL USO DE ORDENADORES.
EL SI EXISTE SIEMPRE, ESTÉ MECANIZADO O NO. .................................................................................................. 9
2. LA APLICACIÓN DEL ORDENADOR A LOS SI PRODUCE LOS SISTEMAS DE INFORMACIÓN BASADOS EN
COMPUTADORA O SISTEMAS DE INFORMACIÓN AUTOMATIZADOS (SIA). ........................................................ 9
3. ............................................................................................................................................................................. 9
1.8. COMPONENTES DE UN SISTEMA DE INFORMACIÓN AUTOMATIZADO ..................................................... 9
1.8.1. TIPOS DE SISTEMAS DE INFORMACIÓN ............................................................................................... 10
3.1.5. NIVEL OPERATIVO ........................................................................................................................... 11
3.1.6. NIVEL DEL CONOCIMIENTO ............................................................................................................. 13
3.1.7. NIVEL ADMINISTRATIVO.................................................................................................................. 14
3.1.8. NIVEL ESTRATÉGICO ........................................................................................................................ 16
CAPÍTULO II ................................................................................................................................................................ 19
ESTRATÉGIAS PARA EL DESARROLLO DE ................................................................................................................... 19
SISTEMAS DE INFORMACIÓN .................................................................................................................................... 19
2.1. INTRODUCCIÓN ........................................................................................................................................ 19
2.2. CICLO VE VIDA .......................................................................................................................................... 19
2.3. ESTRATEGIAS, PRINCIPIOS Y CRITERIOS PARA LA EVALUACIÓN DEL CICLO DE VIDA DE DESARROLLO DE
SISTEMAS .............................................................................................................................................................. 22
2.4. EL CICLO DE VIDA TRADICIONAL .............................................................................................................. 23
2.5. MODELOS DE CICLOS DE VIDA ................................................................................................................. 24
3.1.9. MODELO EN CASCADA .................................................................................................................... 25
3.1.10. MODELO EN ESPIRAL ....................................................................................................................... 26
3.1.11. MODELO BASADO EN PROTOTIPOS ................................................................................................ 27
3.1.12. MODELO INCREMENTAL ................................................................................................................. 27
2.6. HERRAMIENTAS CASE .............................................................................................................................. 28
3.1.13. OBJETIVOS DE LAS HERRAMIENTAS CASE ....................................................................................... 29
3.1.14. CLASIFICACIÓN DE LAS HERRAMIENTAS CASE ................................................................................ 29
3.1.15. CLASES DE HERRAMIENTAS CASE FUNCIONALES ............................................................................ 31
CAPITULO III ............................................................................................................................................................... 32
TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN ........................................................................................................ 32
3.2. INTRODUCCIÓN ........................................................................................................................................ 32
3.3. METODOS EMPÍRICOS.............................................................................................................................. 33
3.3.1. OBSERVACIÓN CIENTÍFICA .............................................................................................................. 33
3.3.2. LA MEDICIÓN ................................................................................................................................... 35

3.4. TÉCNICAS DE INVESTIGACIÓN .................................................................................................................. 38

3.4.1. EL CUESTIONARIO ........................................................................................................................... 38
3.4.2. LA ENTREVISTA ................................................................................................................................ 44
3.4.3. LA ENCUESTA................................................................................................................................... 47
CAPITULO IV .............................................................................................................................................................. 50
METODOLOGÍAS PARA EL DESARROLLO DE SISITEMAS DE INFORMACIÓN .............................................................. 50
4.1. INTRODUCCIÓN ........................................................................................................................................ 50
4.2. LA METODOLOLOGÍA PARA EL DESARROLLO DE SOFTWARE .................................................................. 50
4.3. EL PROCESO DE DESARROLLO DE SOFTWARE.......................................................................................... 51
4.4. LA METODOLOGÍA Y EL-- CICLO DE VIDA ................................................................................................. 51
4.5. CLASIFICACIÓN DE LAS METODOLOGÍAS ................................................................................................. 52
4.5.1. METODOLOGÍAS ESTRUCTURADAS ................................................................................................. 52
4.5.2. METODOLOGÍAS NO ESTRUCTURADAS ........................................................................................... 53
4.6. QUE METODOLOGÍA ELEGIR .................................................................................................................... 53
4.7. LA METODOLOGÍA XP (EXTREME PROGRAMMING) ................................................................................ 54
4.7.1. OBJETIVOS DE XP ............................................................................................................................ 54
4.7.2. VALORES QUE INSPIRAN XP ............................................................................................................ 55
4.7.3. ROLES DE LAS PERSONAS PARTICIPANTES EN XP ........................................................................... 55
4.7.4. FASES DE XP ..................................................................................................................................... 57
4.7.5. CAPTURA DE REQUISITOS EN XP ..................................................................................................... 57
4.7.6. PLANIFICACIÓN EN XP ..................................................................................................................... 57
4.7.7. LA PROGRAMACIÓN EN XP.............................................................................................................. 58
4.7.8. TARJETA CRC (CLASE- RESPONSABILIDAD-COLABORADOR)............................................................ 58
4.7.9. PRÁCTICAS DE XP............................................................................................................................. 59
4.7.10. CICLO DE VIDA DE XP ....................................................................................................................... 59
4.8. METODOLOGÍA SCRUM ........................................................................................................................... 60
4.8.1. ROLES DE LAS PERSONAS PARTICIPANTES EN SCRUM .................................................................... 61
4.8.2. ELEMENTOS DE SCRUM................................................................................................................... 61
4.9. METODOLOGÍA RUP (RATIONAL UNIFIED PROCESS) ............................................................................... 62
4.9.1. HISTORIA ......................................................................................................................................... 62
4.9.2. PRINCIPIOS DEL RUP ........................................................................................................................ 63
4.9.3. CICLO DE VIDA DEL RUP .................................................................................................................. 66
4.9.4. FASES DEL RUP ................................................................................................................................ 67
4.9.5. EL LENGUAJE DE MODELADO UNIFICADO (UML)............................................................................ 68
4.9.6. EL MODELADO DEL NEGOCIO ......................................................................................................... 74
4.9.7. DETERMINACIÓN DE REQUERIMIENTOS ......................................................................................... 85
5. BIBLIOGRAFÍA ............................................................................................................................................... 88

Texto Análisis I - 2013

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

Texto Análisis I - 2013

Transféré par

Droits d'auteur :

Formats disponibles

UATF

M.Sc. Lic. Anny Mercado

Con el acelerado avance tecnológico de la información, la cantidad y la complejidad de los productos

UATF M.Sc. Lic. Anny Mercado Algarañaz -1-

INTRODUCCIÓN AL ANÁLSIS DE SISTEMAS

“Es necesario ser disciplinado y sistemático para desarrollar un buen sistema”

Desarrollar un sistema en la actualidad, implica un conjunto de procedimientos necesarios para poder

UATF M.Sc. Lic. Anny Mercado Algarañaz -2-

3.1.1. PRINCIPIOS DEL ANÁLISIS

• En general durante la etapa de análisis se deben especificar procesos, datos y control.

• Etimológicamente análisis significa “descomponer”, debe de responder a la pregunta ¿Qué?

Asimismo, el análisis presenta los siguientes principios:

UATF M.Sc. Lic. Anny Mercado Algarañaz -3-

3.1.2. El ANALISTA DE SISTEMAS

1.1.1.1. FUNCIONES DEL ANALISTA DE SISTEMAS

El analista de sistemas juega un papel primordial e importante en el desarrollo de sistemas ya que

Arqueólogo, ya que el analista descubre detalles y documenta la política de un negocio.

Mediador, debido a que usualmente se encuentra en medio de usuarios, administradores,

UATF M.Sc. Lic. Anny Mercado Algarañaz -4-

3.1.3. ROLES DE L ANALISTA DE SISTEMAS

UATF M.Sc. Lic. Anny Mercado Algarañaz -5-

El diseño es la primera parte del desarrollo de cualquier proyecto, etimológicamente significa

Otra definición menciona que el diseño es el proceso de planificar, reemplazar o

Finalmente es importante mencionar que Diseñar requiere principalmente consideraciones

3.1.4. PRINCIPIOS DEL DISEÑO

 El diseño establece ¿cómo? , como alcanzar el objetivo

 Todas las cosas siempre tienen primero una creación mental.

UATF M.Sc. Lic. Anny Mercado Algarañaz -6-

 La existencia de objetivos asociados al mismo en contribución al logro de un objetivo

1.4.1. ELEMENTOS DE UN SISTEMA

Entre los elementos que componen un sistema se tienen:

UATF M.Sc. Lic. Anny Mercado Algarañaz -7-

1.5. SISTEMA DE INFORMACIÓN

Un Sistema de Información es un conjunto de elementos interrelacionados entre sí que recolectan,

Otras definiciones de SI enfatizan que el objetivo es proporcionar información de calidad:

1.6. COMPONENTES DE UN SISTEMA DE INFORMACION

UATF M.Sc. Lic. Anny Mercado Algarañaz -8-

1.7. LOS SISTEMA DE INFORMACION AUTOMATIZADOS

1.8. COMPONENTES DE UN SISTEMA DE INFORMACIÓN AUTOMATIZADO

Todo sistema cuenta con los siguientes elementos que lo componen:

UATF M.Sc. Lic. Anny Mercado Algarañaz -9-

 Debe presentarse y entenderse el dominio de la información de un problema.

1.8.1. TIPOS DE SISTEMAS DE INFORMACIÓN

UATF M.Sc. Lic. Anny Mercado Algarañaz - 10 -

3.1.5. Nivel operativo

Sistema de Procesamiento de Transacciones (TPS)

Recolectan, almacenan, modifican y recuperan la información generada por las transacciones

• Entrada: transacciones, eventos

ÁREA DE VENTAS Y MARKETING

• SI de Planificación de Recursos Materiales

UATF M.Sc. Lic. Anny Mercado Algarañaz - 11 -

ÁREA DE FINANZAS Y CONTABILIDAD

ÁREA DE RECURSOS HUMANOS

Finalmente, a continuación se muestra el funcionamiento de un, la siguiente figura muestra de manera

UATF M.Sc. Lic. Anny Mercado Algarañaz - 12 -

3.1.6. Nivel del conocimiento

Se utilizan para el mejoramiento de la calidad de los servicios de la organización y aporte de nuevos

Sistemas de Conocimiento (KWS)

Auxilian a los trabajadores en la creación e integración de nuevo conocimiento en la organización.

Salida: diseños, gráficos

Sistemas de Automatización de Oficina (OAS)

UATF M.Sc. Lic. Anny Mercado Algarañaz - 13 -

3.1.7. Nivel Administrativo