PROPUESTA-DE-LEVANTAMIENTO-DE-REQUERIMIENTOS-EN-EL-DESARROLLO-DE-SISTEMAS-APLICANDO-METODOLOGAìA-TRIZ

Vista previa del material en texto

ÍNDICE 
Resumen. ............................................................................................................................................. i 
Introducción .......................................................................................................................................... ii 
Capítulo I Marco Metodológico ............................................................................................................ 1 
1.1 Planteamiento del problema.......................................................................................................... 1 
1.2 Pregunta de investigación ............................................................................................................. 1 
1.3 Hipótesis ........................................................................................................................................ 1 
1.4 Objetivo general ............................................................................................................................ 2 
1.5 Objetivos específicos .................................................................................................................... 2 
1.6 Justificación ................................................................................................................................... 2 
1.7 Universo o muestra ....................................................................................................................... 3 
1.8 Tipo de investigación ..................................................................................................................... 4 
1.9 Técnicas o instrumentos de medición ........................................................................................... 4 
Capítulo II Marco contextual o referencial ........................................................................................... 5 
2.1 Organización estratégica ............................................................................................................... 5 
2.2 Sistemas de información, organizaciones y procesos de negocio ............................................... 5 
2.3 Desarrollo de sistemas de información ......................................................................................... 7 
2.3.1 Definición y tipos de sistemas de información .................................................................... 7 
2.3.2 Efecto en las Organizaciones ............................................................................................. 7 
2.3.3 Desarrollo de los sistemas de información en las empresas.............................................. 9 
2.4 Ingeniería de Requerimientos ..................................................................................................... 13 
2.4.1 Importancia de una buena definición de requerimientos. ................................................. 14 
2.4.2 Principales riesgos de una mala definición de requerimientos ......................................... 15 
2.4.3 Gestión de Riesgos ........................................................................................................... 16 
2.4.4 Técnicas de levantamiento de requerimientos ................................................................. 18 
2.4.5 Selección de una buena técnica de levantamiento de requerimientos ............................ 19 
2.5 Empresa Lógica de Sistemas...................................................................................................... 19 
2.5.1 Historia .............................................................................................................................. 19 
2.5.2 Ubicación .......................................................................................................................... 20 
2.5.3 Organigrama ..................................................................................................................... 20 
2.5.4 Clientes ............................................................................................................................. 21 
Capítulo III Marco Teórico ................................................................................................................. 23 
3.1. Creatividad e Innovación ............................................................................................................ 23 
3.1.1 Técnicas y herramientas para el desarrollo de la creatividad y la generación de ideas .. 25 
3. 2 Clases de innovaciones ............................................................................................................. 27 
3.2.1 Importancia de la innovación ............................................................................................ 27 
3.2.2 Niveles de innovación ....................................................................................................... 28 
 
3.3 Kahoot como herramienta de innovación ................................................................................... 29 
3.4 Antecedentes de la Metodología TRIZ ........................................................................................ 29 
3.4.1 Bases de la metodología TRIZ ......................................................................................... 29 
3.4.2 39 Contradicciones del TRIZ ........................................................................................... 32 
3.4.3 40 Principios de TRIZ........................................................................................................ 32 
3.5 Principio de la Idealidad .............................................................................................................. 34 
3.6 Identificación de áreas de oportunidad ....................................................................................... 35 
3.7 Diagrama de Pareto .................................................................................................................... 36 
3.8 Seguridad .................................................................................................................................... 37 
3.8.1 Seis Sigma ........................................................................................................................ 38 
3.8.2 (RCM) Mantenimiento Centrado en la Confiabilidad ....................................................... 38 
3.8.3 ISO (Organización Internacional de Normalización) ......................................................... 39 
3.8.4 Cadena de valor ................................................................................................................ 42 
3.9 Conclusión de Seguridad ............................................................................................................ 43 
3.10 Diseño ....................................................................................................................................... 43 
3.11 Auditoria .................................................................................................................................... 45 
Capítulo IV Propuesta de la Metodología TRIZ aplicada en la fase de levantamiento de 
requerimientos ................................................................................................................................... 46 
4.1 Matriz TRIZ adaptada en la definición de requerimientos .......................................................... 46 
4.2 Adaptación de principios de la metodología TRIZ en el levantamiento de requerimientos ........ 46 
4.3 Proceso de adaptación de la metodología TRIZ al proceso de levantamiento de requerimientos 
en el proceso de desarrollo de sistemas. .......................................................................................... 51 
4.4 Análisis de diagrama de Pareto como Herramienta de calidad .................................................. 63 
4.5 Propuesta de evaluación con innovación como complemento deTRIZ ..................................... 72 
Capítulo V Análisis de los resultados ............................................................................................... 88 
5.1 Identificación de proyectos .......................................................................................................... 88 
5.2 Aplicación de la adaptación del modelo TRIZ en los proyectos ................................................. 91 
5.3 Validación de la propuesta en los proyectos ............................................................................. 103 
5.3.1 Evaluación del proyecto de servicio médico. .................................................................. 103 
5.3.2 Evaluación del proyecto de cartera de clientes .............................................................. 108 
5.3.3 Evaluación del proyecto encuestas ................................................................................ 112 
5.4 Resultado de la evaluación ....................................................................................................... 116 
Conclusiones ................................................................................................................................... 117 
Bibliografía ....................................................................................................................................... 119 
Glosario ........................................................................................................................................... 121 
Anexos ............................................................................................................................................. 125 
 
i 
 
Resumen. 
 
Actualmente es preponderante contar con herramientas que faciliten el trabajo dentro de una 
organización en cada uno de los niveles que la conforman, el proceso de negocio de Sistemas está 
definido por los niveles estratégico, táctico y operativo. Cada nivel o área que conforma la 
organización debe contar con información que mejore los procesos de negocio. La empresa, en el 
proceso de desarrollo de proyectos de Sistemas debe identificar y evaluar posibles omisiones antes 
del desarrollo y contemplar la mayoría de las necesidades en la fase de levantamiento de 
requerimientos. La presente tesina se enfoca en el área de sistemas, haciendo énfasis en dicha fase 
con la adaptación de la metodología TRIZ, la cual proporciona una matriz de soluciones, que mejore 
el proceso de levantamiento de requerimientos. El desarrollo de este proyecto con respecto a la 
adaptación de la matriz de Altshuller se estimó como una investigación de tipo exploratoria, sostenida 
en un diseño descriptivo. La elaboración de la matriz quedo sustentada con el análisis de distintas 
metodologías que nos permitieron establecer criterios que van de lo general a lo particular y su vez 
proponer un nivel de innovación de tipo uno. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ii 
 
Introducción 
 
La presente investigación se enfoca en el tema de desarrollo de sistemas remarcando la importancia 
del levantamiento de requerimientos que se puede definir como la especificación de lo que un 
sistema puede hacer, es decir sus funciones y sus propiedades esenciales y deseables. 
 
Para llevar a cabo la elaboración de la tesina es necesario ahondar dentro de la problemática que a 
esta confiere al existir diversas complicaciones en esta etapa de desarrollo de sistemas como son 
costos altos, incremento de tiempo en el desarrollo, no lograr una clara visión de lo que el usuario 
requiere, entre otros, el objetivo de este trabajo es proporcionar una herramienta que permita agilizar 
y hacer eficiente este proceso. 
 
Como consecuencia de la situación anteriormente planteada, para analizar esta problemática es 
necesario mencionar la metodología que seguimos: como primera instancia nos dimos a la tarea de 
realizar una investigación donde comparamos distintas metodologías que se relacionaban 
directamente con la metodología TRIZ, y por mencionar algunas encontramos: Seis Sigma, RCM, 
ISO 27000, Cadena de Valor, así determinamos como realizaríamos la investigación y se acordó que 
nuestro proyecto estaría basado en la parte documental y el estudio que se llevó a cabo fue de tipo 
descriptivo ya que ocupamos el análisis como base y correlacional porque se encontraron variables 
que intervinieron en esta investigación. 
 
En el capítulo uno de este trabajo se expone el análisis que se realizó para llevar a cabo la 
investigación lo que nos llevó a estudiar el desarrollo de sistemas como nuestro universo y de ahí 
surgió que nuestra muestra es la empresa Lógica de Sistemas, donde a partir de la metodología 
TRIZ llevamos a cabo una matriz tipo Altshuller adaptada en el desarrollo de sistemas de información 
en la etapa de definición de requerimientos y proponiendo un catálogo de recomendaciones. 
 
Dentro del capítulo dos se desarrollaron los temas de cómo se conforma la organización, cómo 
funcionan los sistemas de información dentro de las empresas y la importancia que tiene la definición 
de requerimientos en los procesos, a su vez los riesgos que se corren al no llevar a cabo de manera 
ordenada en esta fase del proceso, así mismo se describe la información general de la empresa 
Lógica de Sistemas, como son su fundación, ubicación, organigrama y clientes. 
 
En el capítulo tres se mencionan todos los aspectos que se tomaron en cuenta para la realización 
de la investigación, con fundamento en la metodología TRIZ, sus principios y sus contradicciones y 
la estrecha relación para llevar a cabo la innovación. Se hizo una comparación de las distintas 
metodologías que se revisaron para el desarrollo de sistemas. Por lo que se describen atributos, 
conceptos, tipos y distintas maneras de análisis, para ampliar los criterios y lograr la adaptación de 
la metodología a la fase de definición de requerimientos. 
En el capítulo cuatro basándonos en la matriz de Altshuller desarrollamos una matriz de carácter 
genérico, después revisamos los principios que tenían mayor frecuencia, luego de identificarlos se 
ponderaron aquellos que tenían mayor relevancia en la fase de Levantamiento de Requerimientos y 
se procedió a vaciar la información en un diagrama de Pareto que nos arrojó los principios prioritarios 
a tomar en cuenta en la fase de Levantamiento de Requerimientos de manera porcentual, y así 
mismo pudimos segmentar la matriz de Altshuller, desarrollamos y adaptamos una matriz para cada 
una de las áreas de oportunidad dentro de la fase de Levantamiento de Requerimientos (Seguridad, 
Diseño y Auditoria), que encontramos y realizamos la adaptación a los principios según sus 
equivalentes en el campo de los sistemas. Lo anterior marcó la pauta para darnos a la tarea de 
 
iii 
 
adaptar para cada contradicción una recomendación y de la misma manera proponer la innovación 
de realizar encuestas de manera electrónica haciendo uso de la aplicación Kahoot. 
Para finalizar en el capítulo cinco ya que realizamos la adaptación de la matriz TRIZ en el 
levantamiento de requerimientos y obtuvimos los catálogos para cada una de las áreas de 
oportunidad que planteamos procedimos a elegir 4 proyectos ya realizados que nos proporcionó la 
empresa Lógica de Sistemas, donde fue posible proporcionar sugerencias haciendo uso de los 
catálogos de recomendaciones con base a la experiencia laboral de cada integrante que realizo la 
evaluación, así mismo se validó esta información con una matriz de riesgo que arrojo resultados 
importantes para validar el trabajo que se ha venido trabajando desde el inicio. 
 
 
 
 
 
 
 
 
1 
 
Capítulo I Marco Metodológico 
 
1.1 Planteamiento del problema 
 
El levantamiento de requerimientos en el desarrollo de sistemas de información ha sido planteado 
por diversos autores estos se han encargado de desarrollarmetodologías y técnicas que pretenden 
dar una guía para realizar esta labor, de manera que siguiendo los pasos que se plantean se lograra 
obtener una definición completa de los requerimientos del cliente. 
 
Sin embargo en los últimos años, debido a los crecientes cambios tecnológicos se ha incrementado 
la necesidad generar sistemas flexibles que permitan adaptarse a nuestro entorno, por lo cual las 
organizaciones buscan que dichos cambios se realicen de manera eficiente. 
Estos cambios implican tiempo-costo y desfasamiento de los tiempos programados para la entrega 
de un producto final. 
 
En el contexto de innovación se pretende realizar una adaptación de la Metodología TRIZ para 
levantamiento de requerimientos, planteando que los elementos de Seguridad Informática, Diseño y 
Auditoria son los que comúnmente generan re-trabajos al realizar la entrega del producto en la fase 
de pruebas. 
 
Al realizar el levantamiento de requerimientos se implementara esta herramienta para conocer de 
una manera más precisa las necesidades de los clientes y así poder dar solución a los conflictos que 
surjan, generando una serie de recomendaciones para los distintos elementos que generan re-
trabajos. 
 
El método empleado se basa en contestar preguntas la cuales son calificadas de acuerdo a la 
experiencia del analista y permite tener una mejor visión de los huecos existentes durante el 
levantamiento del requerimiento. Esto nos permite obtener una visión más amplia de la funcionalidad 
de los proyectos o prototipos según sea el caso. 
 
1.2 Pregunta de investigación 
 
¿La aplicación de la metodología TRIZ aportara beneficios en la etapa de definición de 
requerimientos? 
 
 
1.3 Hipótesis 
 
Al aplicar la metodología TRIZ adaptada a los procesos de desarrollo de sistemas en la etapa de 
definición de requerimientos, tendrá un impacto en la reducción de tiempo y costos en la cotización 
de un proyecto, la matriz TRIZ adaptada, será aplicada a proyectos cerrados en la empresa Lógica 
de Sistemas S.A., comprobando el impacto de haberse aplicado durante el proceso con ayuda de 
una herramienta tecnológica. 
 
 
 
 
2 
 
1.4 Objetivo general 
 
A partir de los principios de la metodología TRIZ, realizar una matriz adaptada sobre el desarrollo de 
sistemas de información en su etapa de definición de requerimientos, basada en las metodologías 
utilizadas para ello, aplicando las mejores prácticas recomendadas para lograr mayor eficiencia en 
la claridad y alcance del requerimiento del usuario. 
 
1.5 Objetivos específicos 
 
 Incorporar las destrezas administrativas a un proceso de investigación permanente, que dará 
como resultado un levantamiento de requerimientos exitoso. 
 Establecer la metodología TRIZ para el procesamiento de la información y su representación 
en forma accesible, sobre aquellos aspectos comunes que den mayor valor a los sistemas 
de información. 
 Contribuir en el mejoramiento de levantamiento de requerimientos mediante la adaptación 
de la metodología TRIZ integrando la planeación y operación de los sistemas de información 
para un mejor análisis. 
 Aplicar una herramienta tecnológica que nos permita analizar y evaluar la metodología TRIZ 
en la etapa del levantamiento de requerimientos. 
 
1.6 Justificación 
 
El desarrollo de un proyecto informático siempre ha generado beneficios a una institución o industria, 
teniendo una línea de tiempo en donde se han definido las actividades y la asignación de recursos, 
y donde el “Beneficio” de haber completado las actividades del proyecto ha sido la satisfacción de 
necesidades. 
 
El “Análisis de Requerimientos” se ha llevado a cabo para entender, comprender y analizar los 
problemas planteados para optimizar los procesos en las empresas, con base en este análisis se 
han definido las funciones y características de proyecto, y se han determinado las actividades y 
recursos que han sido asignados en las etapas subsecuentes obteniendo así propuestas de solución 
o prototipos, es por ello que hemos considerado como factor crítico de éxito el fortalecer esta etapa. 
 
El análisis o levantamiento de requerimientos debe ser documentado y es esencial para que el 
desarrollador o programador entregue el sistema correcto, pero debido a distintos factores no se ha 
documentado los requerimientos como es debido. En el desarrollo de sistemas se realizan planes 
que determinan una relación tiempo costo con base en los requerimientos y de ahí se realiza la 
programación y pruebas del sistema, en donde al no haber documentado los requerimientos 
adecuadamente se han tenido que realizar cambios sobre el alcance del proyecto, en el tiempo de 
programación y en nuevas ejecuciones de pruebas. 
 
Se sabe a priori que existen técnicas de “Ingeniería de Requerimientos” y otras tantas técnicas pero 
que al ponerse en práctica han seguido presentando deficiencias significativas, es por ello que se ha 
acentuado la importancia de desarrollar una propuesta que se pueda adaptar a las distintas 
necesidades, aplicando también herramientas y aplicaciones tecnológicas que nos permitan realizar 
una evaluación. 
 
 
3 
 
Nuestro proyecto, es una propuesta que instrumenta la metodología TRIZ como herramienta de 
apoyo en el proceso de definición de requerimientos, lo cual nos permitirá identificar todos aquellos 
principios y contradicciones a los procesos de negocio que se estén analizando, proponiendo 
alternativas basadas en mejores prácticas que complementen el levantamiento de requerimientos, y 
por tanto se presente una mejor propuesta a los clientes. 
 
La utilización de la herramienta TRIZ para la etapa de Levantamiento de Requerimientos brindara 
un apoyo significativo, incluyendo ahora las correspondientes contradicciones a los principios que se 
determinan con base al planteamiento del proyecto. 
 
Durante el estudio se revisarían las mejores prácticas de innovación para aplicar la metodología, 
logrando una mejor empatía entre los especialistas de LOG y sus clientes. 
 
Al final se estaría acortando el tiempo en el proceso de definición de requerimientos, y por lo tanto 
el costo que esto le implica a la empresa LOG, y las propuestas basadas en sus prototipos estarían 
considerando los beneficios de las mejores prácticas. 
Nuestro equipo de trabajo es totalmente interdisciplinario, con la visión de tres carreras, 
Administración Industrial, Ingeniería Industrial y Ciencias de la Informática, lo que permite realizar la 
investigación completa tanto en procesos como en temas técnicos. 
 
La carrera de Administración Industrial aporta conocimientos teóricos y prácticos para el desarrollo 
de esta investigación, con una visión que permite integrar el elemento humano en equipos de trabajo, 
diseñando e implementando modelos de mejora, a través de la implementación de tecnologías y 
normas que permitan hacer más eficientes a las organizaciones. 
 
La carrera de Ingeniería Industrial aporta conocimientos teóricos y prácticos para el desarrollo de 
esta investigación, enfocándose a la resolución de problemas, mediante el diseño, mejoramiento y 
operación de sistemas que contribuyan a aumentar la productividad y calidad, así como los cálculos 
necesarios para la correcta utilización de materiales y equipos. 
 
La carrera de Ciencias de la Informática aporta conocimientos teóricos y prácticos para el desarrollo 
de esta investigación, con un desarrollo de habilidades para el diseño, construcción, transferencia y 
adaptación de tecnologías de la información cuya aplicación en el sector productivo incremente la 
calidad, productividad, factibilidad y sustentabilidad de sus productos y servicios. 
 
1.7 Universo o muestra 
 
El principal campo en que se desarrolló nuestro proyecto es el estudio de sistemas de información 
y en lo particular el proceso de análisis y definición de requerimientos, por lo que jerarquizamos en 
un diagramala parte que comprende al objeto en estudio y se concluyó que es la parte de análisis 
de requisitos. 
 
4 
 
 
 
Figura 1.1. Diagrama representativo de universo o muestra. Elementos de muestreo 
Richard L. Scheaffer, William Mendenhall, Lyman Ott .Editorial Paraninfo, 2006 
 
1.8 Tipo de investigación 
 
El estudio exploratorio nos permitió identificar la problemática a la cual se enfrentan las empresas al 
ejecutar la fase de levantamiento de requerimientos de sistemas. El estudio nos permitió describir la 
justificación de las actividades que apoyaron en el proceso de manera que se coadyuvo a darle 
solución a las contrariedades generadas en el proceso de levantamiento de requerimientos. 
Adaptando aquellos principios que aplicasen de la metodología TRIZ a los procesos de definición de 
requerimientos en los procesos de negocio. 
 
El estudio descriptivo, por su parte este estudio develó de manera general el estado actual en el cual 
se realiza el proceso de levantamiento de requerimientos de sistemas en las empresas 
desarrolladoras de software. Pero sobre todo nos permitió conocer el proceso de levantamiento de 
requerimientos dentro de LOG. Definiendo así las mejores prácticas para dar respuesta a las 
contradicciones presentadas resultado del análisis. 
 
El estudio correlacional, nos permitió definir las interrelaciones que surgieron y que identificamos 
entre las variables dependientes e independientes y que se dan durante el proceso de levantamiento 
de requerimientos de sistemas. Gracias a ello pudimos emplear dinámicas de comunicación para 
aplicar la herramienta con los clientes de la empresa LOG. 
 
Estudio Explicativo, describió y justificó las acciones a llevar a cabo para solventar las contrariedades 
en las que opera la empresa. 
 
1.9 Técnicas o instrumentos de medición 
 
Técnicas documentales como: Fichas bibliográficas porque se consultaron libros especializados en 
la investigación, así como artículos relacionadas al tema. 
 
Técnicas de campo como: Observación y entrevistas al personal relacionado con el desarrollo e 
implementación de los sistemas de información. 
 
5 
 
Capítulo II Marco contextual o referencial 
 
2.1 Organización estratégica 
 
Dentro de las organizaciones las personas que conforman a la empresa necesitan y generan 
información, por lo cual podemos decir que todas las personas en algún momento con algún 
propósito van a necesitar acceso a esa información. 
 
Es importante resaltar que un sistema de información no requiere de un departamento nuevo, ni 
depende de un departamento funcional clásico. Un proyecto de sistemas de información debe de 
involucrar a todos los niveles jerárquicos de una empresa cuando así se requiera. 
 
El diseño de un sistema informático dentro de una organización debe cumplir ciertos criterios para 
que sea efectivo; uno de ellos es tener una visión muy amplia de la empresa y para que el sistema 
de información funcione adecuadamente, los directivos deberán dirigir el proceso, ya que son los 
indicados por tener una visión global de la empresa. La función principal de los directivos será 
encargarse de adaptar los recursos de la Organización a los cambios del entorno. 
 
El sistema de información debe ser afín a los sistemas que conforman la infraestructura de la 
empresa y debe acoplarse con todos ellos. La infraestructura de la empresa está diseñada en función 
de los objetivos que se pretenden alcanzar ( Lapiedra / Devece / Guiral, 2011 p.27). 
 
2.2 Sistemas de información, organizaciones y procesos de negocio 
 
Debido a la diversidad de los procesos de tratamiento de la información y los diferentes niveles (figura 
2.1), es posible estructurar los diversos datos y procesos, es indispensable la existencia de diversos 
sistemas de información capaces de englobar la información que la organización necesita. 
 
 
 
 
 
Figura 2.1. Niveles de informacion. Rafael Lapiedra / Carlos Devece / Joaquín Guiral Introducción 
a la gestión de sistemas de información en la empresa, edición 2011. 
 
 
 
 
 
 
6 
 
Sistemas de Información transaccionales: 
 
También se les denominan como Sistemas de Proceso de Datos. Buscan hacer un seguimiento de 
las actividades y las transacciones elementales de la organización. 
Responden a preguntas como: el dinero que ha entrado hoy en caja o si se han realizado los pagos 
de las nóminas del mes. 
 Capturan, procesan y almacenan datos de transacciones. 
 La información presenta un alto grado de detalle. 
 Ofrecen apoyo a las actividades operativas de la empresa. 
 En la actualidad están muy consolidados los paquetes integrados de gestión. 
 
Sistemas de información para la toma de decisiones: 
 
Son los sistemas en los que se apoya el seguimiento, control y toma de decisiones de los gerentes. 
 Trabajan con información tanto interna (del Sistema de Información Operacional) como 
externa. 
 Incorporan herramientas de análisis de los datos para servir de apoyo a la toma de 
decisiones. 
 Dentro de esta categoría encontramos diversos tipos de aplicaciones informáticas: DSS 
sistemas de apoyo a la decisión (Sistema de soporte de decisión), EIS Sistema de 
Información Ejecutiva (Sistema de información ejecutiva) y OLAP procesamiento analítico 
en línea (Procesamiento analítico en línea) por mencionar algunos. Este conjunto de 
tecnologías se suele denominar BI “Inteligencia de Negocios” (Inteligencia de Negocios). 
 
Sistemas de apoyo a la decisión (DSS) 
 
Como bien se sabe en una organización no todas las decisiones son de carácter repetitivo, sino que 
su frecuencia es variada, como puede que pase recurrentemente como que solo se presente una 
sola vez. Los sistemas de apoyo a la decisión son herramientas para la solución de problemas de 
significado menos preciso y de carácter más esporádico. 
 
Los sistemas de apoyo a la decisión ayudan a los directivos que deben tomar decisiones no 
estructuradas. Una decisión se considera no estructurada si no existen procedimientos claros para 
tomarla y tampoco es posible identificar, con anterioridad, todos los factores que deben considerarse 
en la decisión. 
 
Sistemas de información para ejecutivos (EIS) 
 
Los Sistemas de apoyo a la decisión (DSS) principalmente sirven de apoyo a tareas de planificación, 
mientras que los Sistema de Información Ejecutiva (EIS) constituyen una poderosa herramienta para 
llevar a cabo, principalmente, actividades de control. Un ejecutivo, utilizando un Sistema de 
Información Ejecutiva (EIS), gana habilidad para analizar todos los aspectos de operación de una 
compañía, y encontrar problemas y oportunidades1. 
 
Procesamiento Analítico en Línea (OLAP) 
 
Los sistemas OLAP son bases de datos orientadas al procesamiento analítico. Este análisis suele 
implicar, generalmente, la lectura de grandes cantidades de datos para llegar a extraer algún tipo de 
 
7 
 
información útil: tendencias de ventas, patrones de comportamiento de los consumidores, 
elaboración de informes complejos. Este sistema es típico de las “Bases de Datos Inteligentes”. 
 
 El acceso a los datos frecuentemente puede ser de sólo lectura. La acción más común es la 
consulta, con muy pocas inserciones, actualizaciones y/o eliminaciones. 
 Los datos se estructuran según las áreas de negocio, y los formatos de los datos están 
integrados de manera uniforme en toda la organización. 
 El historial de datos es a largo plazo, normalmente de dos a cinco años. 
 Las bases de datos OLAP se suelen alimentar de información procedente de los sistemas 
operacionales existentes, mediante un proceso de “extracción, transformación y carga” 
(ETL- Extract, Transform and Load). 
 
2.3 Desarrollo de sistemas de información 
2.3.1 Definición y tipos de sistemas de información 
 
Un sistema se define a partir del interés de la persona que pretende analizarlo. Como consecuencia, 
una organización se entiende comoun sistema o subsistema, o incluso un súper-sistema, lo que va 
a depender del análisis que se desee realizar. 
 
Las partes necesarias para que un sistema total funcione son conocidas comúnmente como 
subsistemas, y éstos a su vez se encuentran integrados por un conjunto de subsistemas más 
específicos. Por consiguiente, la jerarquía que llegan a tener los sistemas y el número de 
subsistemas depende de las necesidades de la organización. 
 
Al considerar los subsistemas, los analistas deben especificar cómo es que deben funcionar el 
sistema y sus subsistemas, las entradas requeridas y las salidas que se deben proporcionar, así 
como los trabajos que serán realizados de forma manual y los que serán realizados por medio de 
las computadoras. 
 
Los sistemas de información se clasifican en: 
 
 Sistemas transaccionales 
 Sistemas para la gestión de información 
 Sistemas de información ejecutiva 
 Sistemas de apoyo a las decisiones 
 Sistemas expertos 
 
2.3.2 Efecto en las Organizaciones 
 
Un sistema de información tiene la capacidad de reducir costos, reemplazando capital y mano de 
obra, pero también disminuye el costo de las transacciones, esto es, el costo que se genera por la 
participación de una empresa en un mercado. 
 
Un sistema de información también llega a reducir los costos internos de administración. Teoría de 
la agencia: cada empleado pelea por sus propios intereses, pero cuando hay tecnología de por medio 
es más fácil de controlar, algo que tiene mucha más importancia cuando una empresa está en 
crecimiento. 
 
 
8 
 
En la teoría conductual se describe el funcionamiento de una empresa individual. La tecnología de 
la información puede modificar su jerarquía o la toma de sus decisiones en cualquier organización al 
reducir sus costos de adquirir información y al incrementar la distribución de la misma. En la 
actualidad, una autoridad de base es más importante por su conocimiento que por el cargo que se 
le ha asignado, y es muchísimo más fácil armar los equipos de trabajo cuando éstos están 
conectados por medio de la red. 
 
Dentro de una organización existen pugnas políticas y resistencias al cambio entre quienes las 
conforman. Así pues, otra ventaja de la implementación de los sistemas de información es que éstos 
tienen la capacidad de modificar la estructura, la cultura, la política y el trabajo de una organización. 
Por último, es necesario señalar que el Internet también aumenta la accesibilidad, el almacenamiento 
y la distribución de información y conocimientos en las organizaciones con excelentes resultados. Al 
momento de clasificar los Sistemas de Información, existe una gran variedad de criterios 
 
En la Tabla 2.1 podemos ver algunas de las principales tipologías de sistemas de Información que 
nos podemos encontrar: 
Tabla 2.1 
Tipología de Sistemas de Información 
 
 
 
 
Fuente: (Basado en García Bravo, 2000 y Edwars, Ward y Bythesway, 1998) 
 
Sin embargo, la clasificación más útil es la propuesta por K y J Laudon (1996). En ella los sistemas 
de Información se agrupan según su utilidad en los diferentes niveles de la organización empresarial. 
La organización consta de 4 niveles básicos: un nivel operativo referido a las operaciones diarias de 
la organización, un nivel del conocimiento que afecta a los empleados encargados del manejo de la 
información (generalmente el departamento de informática), un nivel administrativo (abarcaría a los 
gerentes intermedios de la organización) y un nivel estratégico (la alta dirección de la empresa). 
 
 
 
 
Tipo de Sistema de Información Tipos 
Grado de formalidad  Formales 
 Informales 
Automatización  Manuales 
 Informáticos 
Relación con la toma de decisiones  Estratégicos (alta dirección) 
 Gerencial (nivel intermedio) 
 Operativos (control operativo) 
Funcionalidad  Gestión comercial 
 Gestión contable 
 Gestión financiera 
 Gestión de Recursos 
Humanos 
 Gestión de la Producción 
Grado Especialización  Específicos 
 Generales 
 
9 
 
Según estos niveles, K y J Laudon establecen la siguiente clasificación de sistemas de información: 
 
a) Sistema de Procesamiento de Operaciones (SPO): encargados de la administración de 
aquellas operaciones de rutina necesarias en la gestión empresarial (aplicaciones de 
nóminas, seguimiento de pedidos, auditoría, registro y datos de empleados). Se encargan 
de generar la información que requieren el resto de sistemas de la compañía, siendo 
empleados por el personal de niveles inferiores. (Nivel Operativo) 
 
b) Sistemas de Trabajo del Conocimiento (STC): encargados de apoyar a los agentes que 
manejan información en la creación e integración de nuevos conocimientos para la empresa. 
 
c) Sistemas de automatización en la oficina (SAO): empleados para incrementar la 
productividad de los empleados que manejan la información en los niveles inferiores de la 
organización, se encuentran en el nivel de conocimiento. 
 
d) Sistemas de información para la administración (SIA): empleados en el proceso de 
planificación, control y toma de decisiones proporcionando informes sobre las actividades 
ordinarias. Se emplean por la gerencia y directivos de los niveles intermedios de la 
organización. 
 
e) Sistemas para el soporte de decisiones (SSD): ayudan a los distintos usuarios en el proceso 
de toma de decisiones suelen ser interactivos al utilizar diferentes datos y modelos para la 
resolución de problemas no estructurados (análisis de costes, análisis de precios y 
beneficios, análisis de ventas por zona geográfica). Son empleados por la gerencia 
intermedia de la organización. 
 
f) Sistemas de Soporte Gerencial (SSG): se encuentran en un nivel estratégico de la 
organización y están diseñados para toma de decisiones estratégicas mediante el uso de 
comunicaciones avanzadas y gráficos. Se emplean en la alta dirección de la organización 
con el fin de elaborar la estrategia general de la empresa. 
 
Todos estos sistemas de información a su vez podrían analizarse según las diferentes áreas de la 
empresa: ventas y mercadotecnia, manufactura y producción, finanzas, contabilidad y recursos 
humanos. Para cada una de estas áreas existe un conjunto específico de aplicaciones informáticas 
y equipos, los cuales han de estar coordinados entre sí. 
 
 
2.3.3 Desarrollo de los sistemas de información en las empresas 
 
La consecución de una ventaja competitiva utilizando los sistemas de información dependerá en gran 
medida del correcto desarrollo y puesta en funcionamiento del sistema de información. Aquellas 
organizaciones que simplemente adquieren tecnologías de información sin tener en cuenta las 
necesidades existentes en la compañía fracasarán, poniendo en peligro la supervivencia de la 
empresa. 
 
El proceso de desarrollo de los sistemas de información consta de siete etapas fundamentales. 
 
1. Definición del proyecto: en esta etapa se determina si la empresa presenta problemas y 
como estos pueden solucionarse mediante la implantación de un sistema de información. En 
 
10 
 
ella se identificarán cuáles son los objetivos del uso de los sistemas de información y como 
estos se ubican dentro de la estrategia global de la compañía. En esta fase resulta 
fundamental que la alta dirección considere los sistemas de información como un arma 
estratégica y confíen realmente en ello. 
 
2. Análisis de sistemas: tras haber identificado los diferentes problemas de la organización 
estos serán analizados detenidamente, identificando causas que lo originan y planteando 
soluciones. En esta fase se producirá un estudio de factibilidad, para ver si las soluciones 
son posibles dados los recursos de la organización. 
 
3. Diseño de Sistemas: ya elegida la solución, se detallará cómo el sistema de información 
satisface los requisitos planteados por la organización. Al diseñar los sistemas, hemos de 
indicarque componentes de los sistemas de información utilizaremos (nivel hardware, 
software y tecnología de telecomunicaciones) y como se interrelacionarán dichos 
componentes entre sí. De esta forma se definirán las especificaciones del sistema de 
información. 
 
4. Programación: se traducirán las especificaciones funcionales del sistema desarrolladas en 
la etapa anterior, llevándose a cabo la programación y el desarrollo del software. 
 
5. Fase de pruebas: se evalúa el correcto funcionamiento del sistema de información, será 
necesario llevar a cabo un proceso exhaustivo y profundo para determinar si el sistema de 
información funciona en diversas condiciones y si los resultados se corresponden con lo que 
se esperaba. 
 
6. Conversión: ya comprobando que el sistema de información funciona correctamente se 
llevará a cabo la implantación, o bien la sustitución o actualización del antiguo sistema de 
información por el nuevo. 
 
7. Producción y mantenimiento: una vez instalado el nuevo sistema de información, se dice que 
el sistema está en producción. A partir de aquí existirá un proceso constante de evaluación 
del sistema de información por parte de los usuarios y del personal especializado. Tras ello 
se identificarán nuevos errores y se planteará la corrección de estos, si es que existen. 
 
La totalidad de las fases analizadas constituirían el denominado ciclo de vida de los sistemas de 
información. Sin embargo, para muchas compañías desarrollar un sistema de información siguiendo 
la totalidad de las etapas anteriores puede resultarle muy costoso tanto en tiempo como en dinero. 
Otros inconvenientes vendrían dados por los continuos cambios de los requisitos de la información 
que puede originar que un sistema de información quede obsoleto incluso en la etapa de desarrollo. 
Por ello las empresas al desarrollar un sistema de información pueden optar por otro conjunto de 
estrategias que le pueden permitir obtener resultados tan positivos como los conseguidos utilizando 
el ciclo de vida de los sistemas de información. 
 
Otras posibles estrategias a adoptar por las empresas serían las siguientes: 
 
Elaboración de prototipos: la empresa desarrolla un sistema de información no funcional, el cual será 
una versión preliminar del sistema de información total. La elaboración de un prototipo supone la 
reducción de las etapas seguidas en el ciclo de vida de sistemas, buscando la rapidez en el desarrollo 
y la reducción de costes tanto en tiempo como en dinero. Los prototipos son evaluados por los 
 
11 
 
empleados en su puesto de trabajo y se van continuamente adaptando a las necesidades de estos. 
Una vez que se comprueba su correcto funcionamiento el prototipo se irá extendiendo por el resto 
de áreas de la empresa. Suelen utilizarse en organizaciones pequeñas o con bajas necesidades de 
información; en grandes organizaciones no son muy recomendables. 
 
Paquetes de software de aplicaciones: adquisición por parte de la empresa de paquetes de software 
de aplicaciones ya existentes en el mercado y que utilizará para manejar la información. Resulta una 
solución muy sencilla para las organizaciones, pues la empresa simplemente adquiere el programa 
y lo instala en la organización. Los paquetes de software suelen ser aplicarse a una gran variedad 
de áreas de la empresa (nominas, contabilidad, personal...) y son muy útiles cuando la empresa no 
dispone del suficiente capital para poder desarrollar por ella misma el sistema de información. 
 
Sin embargo, el principal inconveniente sería la ausencia de flexibilidad de estos para adaptarse a 
las necesidades específicas de la empresa. Han de valorarse cuestiones tales como los recursos 
que posee la empresa, las funciones del software, el esfuerzo de instalación y mantenimiento del 
paquete de software, el coste y la facilidad de manejo de este. 
 
Desarrollo por los usuarios finales: el desarrollo de las aplicaciones informáticas durante los últimos 
años tales como las hojas de cálculo, editores de texto, bases de datos, permite que sean los propios 
usuarios finales quienes elaboren y desarrollen sus propios sistemas de información, existiendo una 
escasa participación por parte de los especialistas técnicos. Esta solución permite un mayor control 
del sistema por parte de los usuarios, así como el ahorro en coste. 
Sin embargo, los principales inconvenientes serían la excesiva proliferación de sistemas de 
información sin control, el incumplimiento de unos mínimos de calidad y la falta de valoración de la 
organización desde un punto de vista global. 
 
Subcontratación de los sistemas de información: la empresa decide contratar a empresas externas 
para que desarrollen sus sistemas de información. Las empresas se beneficiarían del 
aprovechamiento de economías de escala por parte del proveedor, se asegurarían de calidad en el 
servicio, no existiría incertidumbre en los costes y la adaptación a las necesidades de las empresas 
sería más adecuada. 
 
Por otro lado, subcontratar supone una cierta pérdida de control por parte de las empresas, siendo 
clave el poder negociador con el proveedor de los servicios informáticos. Igualmente, información 
considerada como estratégica por la organización es conocida por organizaciones ajenas a la 
empresa, surgiendo además una dependencia del proveedor. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 
 
En la siguiente Tabla comparamos los diferentes enfoques de desarrollo de sistemas. 
 
Tabla 2.2 
Comparación de enfoques de desarrollo de sistemas 
 
Enfoque Características Ventajas Desventajas 
Ciclo de vida 
de 
Sistemas 
 Secuencial. 
 Realización de un 
proceso formal. 
 Especificaciones y 
aprobaciones por 
escrito. 
 Los usuarios tienen 
un papel limitado. 
 Necesario para 
Sistemas y proyectos 
muy complejos y 
grandes. 
 Lento y costoso. 
 No estimula los 
cambios en la 
organización. 
 Se ha de elaborar 
mucha 
documentación 
Elaboración 
de 
Prototipos 
 Requerimientos 
especificados 
dinámicamente con 
Sistema experimental. 
 Proceso rápido, 
informal e iterativo. 
 Los usuarios 
interactúan rápido con 
el proceso. 
 Rápido y barato. 
 Útil cuando existe 
incertidumbre en los 
requisitos de 
información o los 
usuarios finales son 
importantes. 
 Inadecuado para 
Sistemas grandes y 
complejos. 
 Puede ser superficial 
al obviar el análisis, 
documentación y 
pruebas. 
Paquete de 
software 
para la 
aplicación 
 El software comercial 
evita necesidad de 
programas 
desarrollados 
internamente. 
 Se reducen el diseño, 
programación, 
instalación y 
mantenimiento. 
 Ahorro en tiempo y 
coste. 
 Disminuye la necesidad 
de poseer recursos 
internos. 
 Puede no satisfacer 
los requerimientos 
de la institución. 
 Puede no 
desempeñar bien 
algunas funciones. 
Desarrollo 
de 
usuarios 
finales 
 Sistema creado por y 
para usuarios finales. 
 Rápido e informal. 
 Poca influencia 
especialistas de la 
Información. 
 Usuarios controlan la 
construcción de los 
Sistemas. 
 Ahorra el coste y 
tiempo de desarrollo. 
 Proliferación 
excesiva de 
sistemas sin 
interconexión entre 
ellos. 
 En muchas 
ocasiones no 
cumplen las normas 
de calidad. 
Fuentes 
externas 
 Sistemas construidos 
y operados por 
proveedores externos. 
 Reduce y controla 
mejor los costes. 
 Se obtienen sistemas 
cuando existe carencia 
de recursos en la 
empresa. 
 Pérdida de control 
sobre el área de 
Sistemas de 
Información. 
 Dependencia de la 
dirección técnica y la 
prosperidad de los 
proveedores. 
 externos 
Fuente: Los sistemas de información: evolución y desarrollo, Alejandro Hernández Trasobares 
 
 
 
13 
 
2.4 Ingeniería de Requerimientos 
 
La ingeniería de requerimientos se encuentra en la segunda fase del proceso del proyecto, es en 
esta fase donde se debe generar la correspondiente información para estructurar las siguientes fases 
del proceso.Figura 2.2 Fases de un proceso 
 
Es de suma importancia contar con los requerimientos bien detallados para construir la 
especificación funcional, sin embargo en todos los desarrollos no siempre es posible tener completos 
todos los requerimientos. 
 
Dentro del proceso de levantamiento de requerimientos es necesario tener la interacción con los 
interesados en el desarrollo del sistema (a menos que sea estrategia de la empresa que los usuarios 
sean ellos los que se tienen que adaptar a el sistema tal cual está, como por ejemplo los programas 
de uso masivo) el tiempo empleado en las constantes entrevistas con los diferentes representantes 
del cliente, sin haber mostrado prototipos del sistema, en donde se le realiza una y otra vez las 
mismas preguntas y sin haber comprendido aun el negocio del cliente. 
 
Un requerimiento es una característica del sistema o una descripción de algo que el sistema es capaz 
de hacer con el objeto de satisfacer el propósito del sistema, lo que ha sido apropiadamente 
documentado y validado por el solicitante. 
 
En base a la definición se pueden resaltar los siguientes puntos: 
 
 Para que un pedido o deseo de un usuario o cliente pueda ser considerado como un 
requerimiento este debe ser documentado apropiadamente y debe ser validado por el 
solicitante. 
 Los programadores no deben de ser los encargados de realizar los levantamientos de 
requerimientos, su función es la de traducir los requerimientos en código máquina. 
 Los requerimientos están traducidos en el entorno del sistema no dentro de él. Las palabras 
XML, clase, subrutina etc. No pueden formar parte del requerimiento. 
 
Recurrentemente en el desarrollo de sistemas de software los requerimientos no solo ocupan la 
primera fila sino la única en el proceso de desarrollo. Esta es la causa de innumerables 
modificaciones puesto que la gran mayoría de los casos los sistemas se modifican por que sean 
funcionalmente incorrectos sino porque son difíciles de mantener, portar, escalar o porque son muy 
lentos o vulnerables. Estos sistemas no se mejoran agregando dos o tres funciones, normalmente 
se deben realizar cambios importantes en diferentes partes del sistema. 
 
La tarea del levantamiento de requerimientos es ardua, debido a que se debe entablar una buena 
relación entre el solicitante o cliente y la persona que está tratando de interpretar las funciones y 
características con las que debe cumplir el sistema para que sea aceptado, esta tarea debe ser 
 
14 
 
compacta y consistente. La ingeniería de requerimientos es un proceso de descubrimiento, 
refinamiento, modelización, especificación y validación de lo que se desea construir. 
El usuario o cliente y la persona que está llevando a cabo el levantamiento, deben compartir el mismo 
lenguaje que asegure la comunicación entre ambos. 
 
Utilizando la Ingeniería de Requerimientos se genera un mecanismo apropiado para entender lo que 
desea el cliente, analizar las necesidades, evaluar la factibilidad, definir una solución razonable y 
generar la propuesta de solución sin ambigüedades, validar la especificación y administrar los 
requerimientos a medida que se transforman en un sistema funcional. 
 
La Ingeniería de Requerimientos comienza con la actividad de la comunicación y continua en la fase 
de desarrollo, la cual debe adaptarse a las necesidades del proceso, del proyecto, del producto y de 
las personas que realizan la actividad de levantamiento de datos para plasmarlo en respuestas y en 
modelos gráficos que a su vez ayudaran a rastrear cualquier situación en donde se presente una 
omisión o falta de seguimiento a un proceso. 
 
Las necesidades del negocio generan la parte fundamental del levantamiento de requerimientos es 
aquí en donde se definen los escenarios, funciones y características así como las restricciones del 
proyecto. 
 
Las herramientas que ofrece la Ingeniería de requerimientos permiten entender lo que realmente 
necesita el cliente, realizar análisis tanto técnicos como de factibilidad, realizar las correspondientes 
adaptaciones de funcionalidad así como la pertinente validación de la especificación, dando pauta 
para generar la programación de personas e insumos necesarios en el desarrollo del proyecto y sin 
dejar de comentar los costos a los que se incurren, claro teniendo en cuenta que en realidad se trata 
de una proyección de la situación tal cual se tiene en esos momentos. 
 
La declaración de un proyecto establece el entendimiento básico de un problema, los grupos que 
desean una solución al mismo, así como la estrecha comunicación que debe existir entre los equipos 
que definen las características y del que lo traduce en código máquina. 
 
2.4.1 Importancia de una buena definición de requerimientos. 
 
El desarrollo de un proyecto tiene como finalidad entregar un beneficio en función de plazos de 
cumplimiento, dentro de las etapas del proyecto está el demostrar la factibilidad de realización del 
proyecto, el levantamiento de los requerimientos, Desarrollo, Fase de pruebas, Entrega del proyecto 
y Soporte después de la implementación. 
 
En el proceso de “Levantamiento de Requerimientos” se realiza el plano definitivo de lo que será 
desarrollado, probado y entregado al solicitante o mejor conocido como cliente; es aquí donde se 
debe expresar de manera clara y concisa que se desea obtener como “Beneficio”. Si la persona que 
está realizando el levantamiento del requerimiento no amplía la definición y solo registra su 
percepción sin el uso de algún método entonces comete un grave error ya que al momento que se 
realiza esta labor de Levantamiento de requerimientos solo se considera la definición simple. 
 
Cuando se inicia la fase de Desarrollo y Pruebas con los usuarios se generan nuevos requerimientos 
o las expectativas quedan por debajo de lo que se esperaba, es en este momento cuando se tienen 
que dar dos pasos atrás y peligra la conclusión del proyecto ya que si se solicitan cambios de alcance 
 
15 
 
o nuevas funciones son actividades, tiempos y costos que no se tenían contemplados en el 
levantamiento del requerimiento. 
 
2.4.2 Principales riesgos de una mala definición de requerimientos 
 
En el Levantamiento de Requerimientos el cometer errores incrementa altamente los costos de 
desarrollo y de mantenimiento de los sistemas de software, la corrección de errores puede involucrar 
desde modificaciones al código fuente, rediseño de componentes o inclusive el replantear total o 
parcialmente la solución propuesta. Los costos por corrección de errores en los requisitos se 
incrementan en cada fase de desarrollo del software. La incidencia del costo de corrección de 
requisitos erróneos ha sido ampliamente estudiada por autores como Michael Fagan [Fagan 74], 
Barry Boehm [Boehm 76], Bell y Thayer [Bell 76], Edmund Daly [Daly 77], Victor Basili [Basili 81] y 
Alan Davis [Davis 93] entre otros. Barry Boehm [Boehm 81] estudió varios proyectos de desarrollo 
de software a gran escala para determinar el costo de corrección de errores en los requisitos (ver 
tabla), y que eran descubiertos tardíamente en el proceso de desarrollo. 
 
Tal como se muestra en la tabla, la reparación de un requisito erróneo que permanece sin ser 
detectado ni corregido hasta la etapa de operación, puede costar hasta 100 veces más que si fuera 
detectado y corregido en la fase de establecimiento de los requisitos. 
 
Tabla 2.3 
Costo relativo de corrección de errores 
 
Fase donde se detectó el error Costo promedio 
Definición de requisitos 1 
Diseño 3-6 
Codificación 10 
Prueba de desarrollo 15-40 
Prueba de aceptación 30-70 
Operación 40-100 
Fuente: Boehm, 81 
 
 
 
Principales aspectos a considerar. 
 
1) Cuanto más tarde en detectarse un error durante el ciclo de vida, más costoso es repararlo. 
El crecimiento de los costos de reparación es producto de la catarata de errores que se 
producen: erroresoriginados en una etapa se arrastran en fases sucesivas y más nuevos 
errores se originan en cada una de ellas. 
 
2) Muchos errores permanecen latentes y no son detectados hasta bastante después de la 
etapa en que se cometieron. El 54% de los errores se detectan después de la fase de 
codificación y prueba. Estos errores provienen en un 45% de la fase de requisitos y en un 
9% de la fase de codificación. 
 
3) Se están cometiendo demasiados errores. El 56% de los errores tienen su origen en la etapa 
de requisitos. 
 
 
16 
 
4) Los errores de requisitos responden a una clasificación típica. 
 
a) hechos incorrectos 49% 
b) omisiones 31% 
c) inconsistencias 13% 
d) ambigüedades 5% 
e) otros (requisitos mal ubicados) 2%. 
 
5) Los errores en los requisitos pueden detectarse. La detección puede realizarse a través de 
distintas técnicas: hechas a la medida, inspecciones, pruebas unitarias, pruebas de 
integración, evaluación (pruebas de aceptación), entre otras. Las inspecciones detectan el 
65% de errores, las pruebas unitarias: 10%, pruebas de integración: 6%, evaluación: 10%, 
otros: 9%. 
 
En respuesta a la baja calidad de los productos de software con altos costos de corrección y 
mantenimiento, muchos desarrolladores de software e investigadores se han planteado la necesidad 
de profundizar en el proceso previo al diseño del software. Sus investigaciones y prácticas 
profesionales han apuntado a garantizar la producción de software de alta calidad y bajo costo 
basándose en el establecimiento de un punto de partida de alta confiabilidad, mediante la detección 
de errores lo más tempranamente posible. Es necesario entonces contar con procesos de producción 
de Levantamiento de Requerimientos confiables. 
 
El reconocimiento de los defectos en el Levantamiento de Requerimientos mediante el estudio de 
sus causas y efectos ha permitido, en los últimos años, el establecimiento de procesos de definición 
de requerimientos atentos a esta grave circunstancia. 
 
2.4.3 Gestión de Riesgos 
 
El objetivo de la gestión de riesgos consiste en aumentar la probabilidad y el impacto de los efectos 
positivos y reducir la probabilidad y el impacto de los efectos negativos dentro de un proyecto, para 
lo cual se describen una serie de actividades a realizar y que se describen a continuación: 
 
 Planificar la gestión de los riesgos: El proceso de definir cómo realizar las actividades de 
gestión de riesgos de un proyecto. 
 Identificar los riesgos: El proceso de determinar los riesgos que pueden afectar al proyecto 
y documentar sus características. 
 Realizar el análisis cualitativo de los riesgos: El proceso de priorizar riesgos para análisis o 
acción posterior evaluando y combinando la probabilidad de ocurrencia e impacto de dichos 
riesgos. 
 Realizar el Análisis Cuantitativo de Riesgos: El proceso de analizar numéricamente el efecto 
de los riesgos identificados sobre los objetivos generales del proyecto. 
 Planificar la respuesta a los riesgos: El proceso de desarrollar opciones y acciones para 
mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. 
 Controlar los Riesgos: El proceso de implementar los planes de respuesta a los riesgos, dar 
seguimiento a los riesgos identificados, monitorear los riesgos residuales, identificar nuevos 
riesgos y evaluar la efectividad del proceso de gestión de los riesgos a través del proyecto. 
 
 
17 
 
El riesgo de un proyecto en cualquiera de sus fases es un suceso inherente e implícito que, de 
producirse, puede llegar a tener un efecto positivo o negativo en uno o más de los objetivos del 
proyecto. 
 
Un riesgo puede tener una o más causas y, de materializarse, uno o más impactos. Una causa puede 
ser un requerimiento especificado o potencial, un supuesto, una restricción o una condición que crea 
la posibilidad de consecuencias tanto negativas como positivas. Si se produjese algún evento 
incierto, podría haber un impacto en el alcance, el costo, el cronograma, la calidad o el desempeño 
del proyecto. Las condiciones de riesgo pueden incluir aspectos del entorno del proyecto o de la 
organización que contribuyan a poner en riesgo el proyecto, tales como las prácticas deficientes de 
dirección de proyectos, la falta de sistemas de gestión integrados, la concurrencia de varios 
proyectos o la dependencia de participantes externos fuera del ámbito de control directo del proyecto. 
Los riesgos del proyecto tienen su origen en la incertidumbre que está presente en todos los 
proyectos. Los riesgos conocidos son aquellos que han sido identificados y analizados, lo que hace 
posible planificar respuestas para tales riesgos. Los riesgos desconocidos no se pueden gestionar 
de manera proactiva y por lo tanto se les puede asignar una reserva de gestión. Un riesgo negativo 
del proyecto que se ha materializado se considera un problema. 
 
Los riesgos individuales del proyecto son diferentes del riesgo global del proyecto. El riesgo global 
del proyecto representa el efecto de la incertidumbre sobre el proyecto en su conjunto. Es más que 
la suma de los riesgos individuales del proyecto, ya que incluye todas las fuentes de incertidumbre 
del proyecto. Representa la exposición de los interesados a las implicaciones de las variaciones en 
los resultados del proyecto, tanto positivas, como negativas. 
 
Las organizaciones perciben el riesgo como el efecto de la incertidumbre sobre los objetivos del 
proyecto y de la organización. Las organizaciones y los interesados están dispuestos a aceptar 
diferentes niveles de riesgo, en función de su actitud frente al riesgo. Las actitudes frente al riesgo 
de la organización y de los interesados pueden verse afectadas por una serie de factores, los cuales 
se clasifican a grandes rasgos en tres categorías: 
 
 Apetito de riesgo, que es el grado de incertidumbre que una entidad está dispuesta a aceptar, 
con miras a una recompensa. 
 Tolerancia al riesgo, que es el grado, cantidad o volumen de riesgo que podrá resistir una 
organización o individuo. 
 Umbral de riesgo, que se refiere a la medida del nivel de incertidumbre o el nivel de impacto 
en el que un interesado pueda tener particular interés. Por debajo de ese umbral de riesgo, 
la organización aceptará el riesgo. Por encima de ese umbral, la organización no tolerará el 
riesgo. 
 
Por ejemplo, la actitud frente al riesgo de una organización puede incluir su apetito por la 
incertidumbre, su umbral para los niveles de riesgo que son inaceptables o su tolerancia al riesgo, a 
partir de lo cual la organización puede seleccionar una respuesta al riesgo diferente. 
 
Los riesgos positivos se conocen normalmente como oportunidades y los negativos como amenazas. 
El proyecto puede aceptarse si los riesgos se encuentran dentro de las tolerancias y están en 
equilibrio con el beneficio que puede obtenerse al asumirlos. Los riesgos positivos que ofrecen 
oportunidades dentro de los límites de la tolerancia al riesgo se pueden emprender a fin de generar 
un mayor valor a la empresa. 
 
 
18 
 
Las personas adoptan actitudes frente al riesgo lo cual define la manera en que responderán a él, 
son motivadas por la percepción, las tolerancias y otras predisposiciones, que deben hacerse 
explícitas siempre que sea posible. Para cada proyecto debe desarrollarse un enfoque coherente en 
materia de riesgos, y la comunicación sobre el riesgo y su gestión debe ser abierta y honesta. Las 
respuestas a los riesgos reflejan el equilibrio que percibe una organización entre asumir y evitar los 
riesgos. 
 
Para tener éxito, una organización debe comprometerse a abordar la gestión de riesgos de manera 
proactiva y consistente a lo largo del proyecto. Se debería realizar una elección consciente a todos 
los niveles de la organización para identificar activamente y procurar una gestión de riesgos eficaz 
durante la vida del proyecto.El riesgo del proyecto puede existir desde el mismo momento en que se inicia el proyecto. El avanzar 
en un proyecto sin un enfoque proactivo de la gestión de riesgos es probable que dé lugar a un 
mayor número de problemas, como consecuencia de las amenazas no gestionadas. 
 
2.4.4 Técnicas de levantamiento de requerimientos 
 
El levantamiento de requerimientos es la actividad de mayor reto, la más crítica y la que requiere 
mayor conocimiento, ya que requiere la colaboración de diferentes stakeholders1 que pueden estar 
distribuidos geográficamente y que no necesariamente son de la misma área de conocimiento. Se 
encarga de encontrar el origen de los requerimientos y de cómo los analistas pueden recolectarlos. 
Esta es la primera etapa de construcción del entendimiento del problema que el software debe 
resolver. Es fundamentalmente una actividad humana en la cual se identifican los stakeholders y se 
establecen las relaciones que éstos van a tener a lo largo del proceso de desarrollo, recordando. 
 
Asociado a la importancia del levantamiento y a todos los beneficios que su buena realización trae, 
existen diversos factores por los cuales este proceso se hace más complejo y demanda de mayor 
cuidado y gestión. A continuación se listan algunas de estas dificultades: 
 
a) Problemas de Alcance: Muchas veces la complejidad del sistema analizado es de un tamaño 
tal que no se tiene claridad acerca de lo que el sistema hará y lo que no hará. 
b) Problemas de Entendimiento: Los requerimientos generalmente provienen de alguna fuente, 
pero en ciertas ocasiones dicha fuente no es capaz de expresarlos como el ingeniero 
desearía. 
c) Problemas de Volatilidad: Generalmente cuando un proyecto de desarrollo de software lleva 
un tiempo muy extenso en su desarrollo, los requerimientos tienden a cambiar. 
Entre los ejemplos de técnicas de recopilación de información utilizadas en la identificación de 
riesgos se cuentan: 
 
• Tormenta de ideas. El objetivo de la tormenta de ideas es obtener una lista completa de los riesgos 
del proyecto. Por lo general, el equipo del proyecto efectúa tormentas de ideas, a menudo con un 
grupo multidisciplinario de expertos que no forman parte del equipo. Bajo el liderazgo de un 
facilitador, se generan ideas acerca de los riesgos del proyecto, ya sea por medio de una sesión 
tradicional y abierta de tormenta de ideas, o en una sesión estructurada donde se utilizan técnicas 
de entrevista masiva. Como marco de referencia pueden utilizarse categorías de riesgo, como en 
una estructura de desglose de riesgos. Posteriormente se identifican y categorizan los riesgos según 
su tipo, y se refinan sus definiciones. 
 
 
19 
 
• Técnica Delphi. Es una manera de lograr un consenso de expertos. Los expertos en riesgos del 
proyecto participan en esta técnica de forma anónima. Un facilitador utiliza un cuestionario para 
solicitar ideas acerca de los riesgos importantes del proyecto. Las respuestas son resumidas y 
posteriormente enviadas nuevamente a los expertos para recabar comentarios adicionales. En pocas 
rondas de este proceso se puede lograr el consenso. La técnica Delphi ayuda a reducir sesgos en 
los datos y evita que cualquier persona ejerza influencias indebidas en el resultado. 
 
• Entrevistas. La realización de entrevistas a los participantes experimentados del proyecto, a los 
interesados y a los expertos en la materia ayuda a identificar los riesgos. 
 
• Análisis de causa raíz. El análisis de causa raíz es una técnica específica para identif icar un 
problema, determinar las causas subyacentes que lo ocasionan y desarrollar acciones preventivas. 
 
 
 2.4.5 Selección de una buena técnica de levantamiento de requerimientos 
 
Una técnica, es una serie de pasos documentados que van de la mano con unas reglas para su uso 
y criterios para verificar su corrección. Una técnica usualmente aplica a un proceso en el modelo de 
procesos. Algunas veces, dicha técnica incluye una notación y/o una herramienta asociada. 
 
El levantamiento de requerimientos generalmente se realiza usando una metodología o varias 
técnicas. Muchas de esas metodologías y técnicas ya existen y tienen como objetivo asistir a los 
analistas en la tarea de entender las necesidades del cliente. A pesar de que algunos analistas 
consideran que la selección de una única técnica aplica para todas las situaciones, una metodología 
o técnica no puede ser suficiente para todas las condiciones del proyecto. 
 
Por esto, la selección de las técnicas apropiadas para el levantamiento de requerimientos entre las 
técnicas disponibles, afecta enormemente el éxito o fracaso de todo el proceso de levantamiento. 
 
 
2.5 Empresa Lógica de Sistemas 
 
2.5.1 Historia 
 
La Empresa Lógica de Sistemas S.A., (LOG) fue fundada en el año 1997 por un grupo de 
profesionistas que compartieron la idea de ofrecer algo diferente en el desarrollo de sistemas, ellos 
observaron que si bien la programación orientada a objetos tenía gran impacto en la forma de 
programar, no todos dominaban la técnica, es así que decidieron formar una nueva empresa donde 
todos sus integrantes tuvieran certificaciones en productos Microsoft y técnicas de programación. 
 
Cuatro fueron los integrantes Rolando Islas, Claudia, Rafael Menchaca y Jorge Palomero, los que 
formaron la empresa e iniciaron desarrollando sistemas para Banca Mifel, esto generó un experiencia 
en modelos financieros y estadísticos. El crecimiento de LOG se dio cuando logro proyectos en la 
Empresa Teléfonos de México, en el desarrollo del sistema de Indicadores de Productividad y el 
Sistema de Previsión Social. 
 
A lo largo del tiempo fueron incorporando nuevas a nuevos clientes y recursos que cumplieran con 
la misma filosofía, así como el servicio de trabajo externo de personal de sistemas. 
 
20 
 
 
Un cambio importante fue 10 años después de su creación, decidieron abrir una oficina en la ciudad 
de Vancouver Canadá, incursionando en el mercado de Norteamérica, con un modelo donde el 
desarrollo lo realizaban en México y el software lo vendían como empresa Canadiense. Su estrategia 
abarco las tiendas de servicio minoritarias ofertando sistemas de uso para el hogar como control de 
hipotecas, seguros, servicios, presupuestos, etc. 
 
En la actualidad continúan con el desarrollo de sistemas a la medida para clientes y con el servicio 
de Trabajo Externo de personal especializado en sistemas 
 
2.5.2 Ubicación 
 
La ubicación de la empresa Lógica de Sistemas S.A. 
Dirección: Av. Patriotismo 8, Oficina 201, Colonia Hipódromo Condesa 
 
 
Figura 2.3 Ubicación geográfica de la empresa Lógica de Sistemas 
 
2.5.3 Organigrama 
 
Lógica de Sistemas S. A. tiene una estructura organizacional orientada a los servicios que ofrecen. 
Cuenta con un director general y dos oficinas. La de Ciudad de México atiende proyectos en dos 
giros, la primera en renta de especialistas de sistemas y la segunda en desarrollo de sistemas de 
acuerdo a las necesidades de los clientes. 
 
La oficina de Vancouver da seguimiento a proyectos de consultoría y desarrollo de sistemas, los 
cuales son desarrollados por la oficina de la Ciudad de México. 
 
Por último se cuenta con un área Administrativa donde se revisar los temas internos y externos 
orientados al servicio a los clientes 
 
21 
 
 
Figura 2.4 Organigrama de la Empresa Lógica de Sistemas 
 
2.5.4 Clientes 
 
Tabla 2.4 
Clientes de la empresa lógica de sistemas 
Empresa Proyecto en el que intervino LOG 
 
Sistema de manejo de indicadores para Telmex 
 
Sistema de financiamiento para Planfía 
 
Servicio de Trabajo Externo de desarrollo para Server 
Grupo Scanda 
 
Servicio de Trabajo Externo de sistemas para coca cola 
FEMSA 
 
22 
 
 
Sistema de planeación de la producción para grupo Auriga-
Aurex 
 
Sistema de control de pedidos para Cinram Latinoamericana 
 
Sistema de control de equipajede Mexicana 
 
23 
 
Capítulo III Marco Teórico 
 
3.1. Creatividad e Innovación 
 
La creatividad y la innovación son dos conceptos que van de la mano. En el entorno empresarial 
resultan de vital importancia porque a medida que los mercados se hacen más competitivos las 
organizaciones pueden desarrollar ventajas que permitan mantenerse con éxito. La capacidad 
creativa se puede definir como: “la habilidad para generar de manera fácil ideas, alternativas y 
soluciones a un determinado problema”. En relación con el concepto de innovación, la creatividad 
representa el proceso de generación de ideas, es la inspiración que nos permite crear nuevas 
soluciones. Por su parte, la innovación es la capacidad de convertir estas ideas en algo aplicable, de 
darles sentido y valor dentro de un contexto. 
 
Ambas resultan de vital importancia porque trabajan en conjunto para dar como resultado cambios 
que conlleven a una mayor satisfacción de los clientes. 
 
Existe un proceso para la generación de ideas y aplicación en forma de innovación, cuyo análisis y 
aplicación facilita la solución de problemas y generación de estrategias de cambio que nos permitan 
adaptarnos a cualquier situación. Este comprende las siguientes fases: 
 
Figura 3.1. Fases de la creatividad e innovación. 
Fuente: www.creabussinesidea/test_g30/modulo_noticia_2.01/panel/tmp/ficha_172_1.pdf 
Manual de la creatividad empresarial. 
 
 
 
 
24 
 
Fase I. Identificación y definición del problema. 
 
La presencia de un problema que requiere de un cambio este suele ser el motivo más común de la 
utilización de un proceso creativo ya que de ello deriva la idea de que exista un buen análisis y 
compresión de lo que se desea resolver para ofrecer una solución acertada. 
Esta fase resulta fundamental ya que si se obtiene una versión alterada de la realidad caeremos en 
decisiones y definiciones de estrategias que difícilmente puedan ayudarnos a superar la situación 
existente. 
 
Fase II. Generación y selección de ideas. 
 
Constituye el centro del proceso ya que es aquí donde se producen ideas que servirán de punto de 
partida para el diseño de propuestas para aportar una solución al problema o situación. 
 
En el desarrollo de ideas podemos partir de dos fases, una es el pensamiento divergente donde se 
podrán generar ideas sin restricciones ofreciéndonos un amplio catálogo para una posterior 
selección. La segunda es el pensamiento convergente esta busca poner un orden a las ideas 
previamente generadas. 
 
Fase III. Consenso y puesta en marcha de la idea desarrollada. 
 
El final de este proceso incluye la aceptación de alguna de las soluciones debatidas y desarrolladas 
a partir de las ideas previamente propuestas. Una vez determinada la solución definitiva permitirá 
que estas ideas se conviertan en un proyecto concreto, es decir innovación. 
 
Los cambios que se presentan en la sociedad son cada vez más profundos, y estos afectan de gran 
manera la forma en la que comprendemos el entorno, no solamente son importantes por la 
intensidad, estos también se producen a gran velocidad, lo que demanda mayor flexibilidad y 
capacidad de adaptación por parte de las organizaciones y personas. 
 
El conocimiento es una base fundamental ya que es el responsable de que con la misma base 
tecnológica, los bienes y servicios generen un valor añadido y se vuelvan competitivos que los que 
el resto ofrecen. 
 
En este nuevo contexto surge un nuevo factor, ligado a la innovación y al conocimiento, pero 
constituye un elemento distintivo de las economías más avanzadas: la creatividad. 
 
La creatividad como herramienta para generar procesos de cambio y mejora aplicados a la empresa 
tiene objetivos específicos como: 
 
 Acortar los ciclos de vida de los productos, introduciendo innovaciones incrementales que 
permitan sustituirlos por otros. 
 Ampliar la oferta mediante la creación de nuevos productos y servicios. 
 Dar respuesta a la demanda de unos consumidores crecientemente exigentes en cuanto a 
la calidad y servicios ofrecidos. 
 Desarrollar nuevas tecnologías que le permitan abaratar costes y crear nuevos productos. 
 Cambiar los sistemas de gestión hacia modelos más flexibles. 
 Mejorar el diseño de los productos. 
 
25 
 
 Aumentar los mercados a los que llegan nuestra oferta de productos y servicios. 
 Alcanzar nuevos nichos de mercado objetivo (nuevas empresas, nuevas personas, etc.) 
 
La utilización de enfoques y técnicas creativos permite alimentar y mejorar los procesos de innova-
ción, que es el elemento diferencial de las empresas que se posicionan en la vanguardia del 
mercado. 
 
Los beneficios de la actividad creativa en la empresa se pueden clasificar en cuatro grandes grupos: 
 
I. Desarrollo del negocio. Mediante la creatividad se pueden contribuir a la realización de 
nuevos modelos de negocio, donde se implementen metodologías que fomenten la 
participación de los trabajadores. 
II. Relación con el cliente. La mejora de los productos o servicios a partir de las estrategias 
creativas e innovadoras, no solo permite que las empresas retengan a los clientes sino 
que puede favorecer al descubrimiento de un nuevo mercado. 
III. Nuevas oportunidades. La ampliación de los mercados o incursión de nuevas acciones 
de negocio, dependen de la capacidad de desarrollar productos y servicios novedosos. 
IV. Mejora de la competitividad. Dado la aplicación de enfoques creativos e innovadores se 
puede obtener mayores rendimientos por un aprovechamiento más eficiente de la 
tecnología. Este tipo de estrategias se traducen en una mayor capacidad para competir 
frente a otras empresas. 
 
3.1.1 Técnicas y herramientas para el desarrollo de la creatividad y la generación de ideas 
 
Existen una serie de herramientas y técnicas que facilitan el trabajo de la generación de ideas. (Tabla 
3.1) 
 
Estas técnicas pueden utilizarse para la generación de ideas en un sentido más general o tener un 
carácter más específico en función de las necesidades de la empresa a las que se quiera responder, 
a pesar de que un individuo tenga o no habilidades y aptitudes creativas o una organización permita 
favorecer el flujo creativo. En este sentido se pueden encontrar técnicas que sirvan para diferentes 
fines: 
• La comprensión del problema al que se enfrentan. 
• Generar ideas ante una escasez en el flujo creativo. 
• La selección de ideas existentes. 
• La planificación de actividades. 
 
Del mismo modo, existen técnicas clasificadas por el número de personas que se necesita para su 
utilización: 
 
• Individuales. 
• Grupales. 
 
 
 
 
 
 
 
26 
 
Tabla 3.1 
Herramientas y técnicas para la generación de ideas 
Fuente: www.creabussinesidea/test_g30/modulo_noticia_2.01/panel/tmp/ficha_172_1.pdf 
Manual de la creatividad empresarial. 
 
La empresa es una organización en la que se trabaja conjuntamente para lograr objetivos y 
crecimiento. Trabajando conjuntamente se obtiene una visión más amplia basada en conocimientos 
y experiencias del equipo de trabajo, compartiendo ideas entre unos y otro y generando una 
participación más recíproca. 
 
Dependiendo de las necesidades de la empresa o de la fase del proceso creativo en el que se 
encuentre, se requerirá del uso de unas técnicas creativas u otras. Junto a la clasificación realizada 
en función del número de personas participantes, se distinguen técnicas dirigidas a: 
 La generación de ideas, que permitan superar situaciones donde se requiere de ideas 
innovadoras en particular o de ideas en general. 
 La selección de ideas, apropiadas para su uso cuando las ideas fluyen con normalidad o ya 
se han utilizado técnicas de generación y es necesario identificar o evaluar los resultados 
obtenidos. 
 
Además de las técnicas previamente mencionadas podemos encontrar: 
 
 4x4x4 
 Análisis Morfológico 
 Biónica 
 CRE-IN 
 Defectología 
