Captulo 2 Marco Terico

El marco terico, marco referencial o marco conceptual tiene el propsito de dar a

la investigacin un sistema coordinado y coherente de conceptos y proposiciones que
permitan abordar el problema. De ste depender el resultado del trabajo. Significa
poner en claro para el propio investigador sus postulados y supuestos, asumir los
frutos de investigaciones anteriores y esforzarse por orientar el trabajo de un modo
coherente. De este modo, el fin que tiene el marco terico es el de situar el problema
que se est estudiando dentro de un conjunto de conocimientos, que permita orientar
la bsqueda y ofrezca una conceptualizacin adecuada de los trminos que se
utilizaran en el trabajo. El punto de partida para construir un marco de referencia lo
constituye el conocimiento previo de los fenmenos que se abordan, as como las
enseanzas que se extraigan del trabajo de revisin bibliogrfica que
obligatoriamente se tiene que hacer.
En general, se podra afirmar que el marco terico tiene como funciones:
Orientar hacia la organizacin de datos y hechos significativos para descubrir las
relaciones de un problema con las teoras ya existentes.
Evitar que el investigador aborde temticas que, dado el estado del
conocimiento, ya han sido investigadas o carecen de importancia cientfica.
Guiar en la seleccin de los factores y variables que sern estudiadas en la
investigacin, as como sus estrategias de medicin, su validez y confiabilidad.
Prevenir sobre los posibles factores de confusin o variables extraas que
potencialmente podran generar sesgos no deseados.

Antes de la aparicin de la ingeniera de requisitos, stos eran competencia exclusiva

del anlisis de sistemas. En esta rea se elaboraron algunos mtodos de desarrollo
estructurado como SA/SD (anlisis y diseo estructurados) (De Marco, 1978), SADT
(anlisis de sistemas y tcnica de diseo) (Ross y Schoman, 1977) o SSADM
(anlisis estructurado de sistema y mtodo de diseo) (Downs et al., 1992). La idea
general de todos estos mtodos consiste en comenzar analizando los requisitos
mediante un enfoque divide y vencers que permita ir fraccionando el sistema en
piezas ms pequeas y despus definir las funciones u objetivos que cada parte del
sistema debera realizar.
Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De
las muchas definiciones que existen para requerimiento, a continuacin se presenta la
definicin que aparece en el glosario de la IEEE.

Una condicin o necesidad de un usuario para resolver un problema o alcanzar

un objetivo. Una condicin o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estndar, especificacin u otro
documento formal. Una representacin documentada de una condicin o capacidad.
Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos
no funcionales.
Los requerimientos funcionales definen las funciones que el sistema ser capaz de
realizar. Describen las transformaciones que el sistema realiza sobre las entradas
para producir salidas.
Los requerimientos no funcionales tienen que ver con caractersticas que de una u
otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, estndares, etc.
Caractersticas de los requerimientos
Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto
de requerimientos en estado de madurez, deben presentar una serie de
caractersticas tanto individualmente como en grupo. A continuacin se presentan las
ms importantes.
Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el
sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad
no pueden ser reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender.
Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un
futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su
redaccin, es decir, si se proporciona la informacin suficiente para su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin.
El lenguaje usado en su definicin, no debe causar confusiones al lector.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera

que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis,
demostracin o pruebas.
Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes.

Son difciles de expresar en palabras (el lenguaje es ambiguo).
Existen muchos tipos de requerimientos y diferentes niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes
o ms estables que otros.
Los requerimientos estn relacionados unos con otros, y a su vez se relacionan
con otras partes del proceso.

Antecedentes (Del Negocio)

La exposicin debe referenciarse a investigaciones ms importantes (por su Actualidad
y valor terico) que se han realizado sobre el tema del estudio. Se debe asegurar que
la investigacin va a responder a un vaco de conocimiento, no una ignorancia de la
investigacin.
Es requisito imprescindible una exhaustiva revisin de la bibliografa; las ms
actualizadas, revistas, tesis, etc. Hacer una sntesis conceptual de las investigaciones.
El tratamiento de la informacin recopilada depende del nivel que le imprima el
investigador.
Los antecedentes tienen como fin dar a conocer como ha sido tratado el tema,
hacindose preguntas como:

Qu tipos de estudios se han efectuado?

Las caractersticas de lo investigado (objeto, sujeto)
Cmo se han recolectado los datos?
En qu lugares se ha llevado a cabo?

Los antecedentes son el punto de partida para delimitar el problema ya que permite
aclarar, juzgar e interpretar el problema planteado y sirve para ampliar o continuar lo
investigado.
Los antecedentes del problema consisten bsicamente en efectuar una revisin
bibliogrfica sobre el problema en cuestin y en consultar a expertos en la temtica.
Esta etapa aporta el marco conceptual en el que se desarrolla la investigacin.

Elementos de los antecedentes del problema:

El autor
Ao de Edicin
Ttulo del Tema
Poblacin y muestra
Conclusiones

Procesos de los Antecedentes del problema:

Detencin de la literatura y otros documentos

Obtencin de la literatura
Consulta de la literatura
Fichaje

En la situacin actual de crisis econmica se pone de manifiesto un nuevo escenario

para la negociacin de las empresas con las entidades financieras:

Restriccin del Crdito.

Mayores dificultades para acceder a crditos o prstamos.

Mayores exigencias por parte de las entidades financieras a los

empresarios para concederles prstamos.

Por todo ello, el Plan de Empresa es actualmente un requisito fundamental que exigen
las entidades financieras a los emprendedores que quieren poner en marcha su
proyecto de negocio, para que los Bancos puedan analizar la viabilidad econmica
financiera de dicho proyecto.
En una serie de vdeos voy a explicar las distintas partes que componen un Plan de
Empresa, y como realizarlo pas a paso.

2.2. Estado del Arte INGENIERIA DE REQUISITOS

El estado del arte es una modalidad de la investigacin documental que permite el
estudio del conocimiento acumulado (escrito en textos) dentro de un rea especfica.
Sus orgenes se remontan a los aos ochenta, poca en la que se utilizaba como

herramienta para compilar y sistematizar informacin especialmente el rea de ciencias

sociales, sin embargo, en la medida en que estos estudios se realizaron con el fin de
hacer balances sobre las tendencias de investigacin y como punto de partida para la
toma de decisiones, el estado del arte se posicion como una modalidad de
investigacin de la investigacin. Hoy en da se considera que en general, el estado del
arte puede abordarse desde tres perspectivas fundamentales. Sea cual fuere el
abordaje del estado del arte, se considera que su realizacin implica el desarrollo de
una metodologa resumida en tres grandes pasos: contextualizacin, clasificacin y
categorizacin; los cuales son complementados por una fase adicional que permita
asociar al estado del arte de manera estructural, es decir, hacer el anlisis (sinnimo de
investigacin). De esta manera se observa que la realizacin de estados del arte
permite la circulacin de la informacin, genera una demanda de conocimiento y
establece comparaciones con otros conocimientos paralelos a este, ofreciendo
diferentes posibilidades de comprensin del problema tratado; pues brinda ms de una
alternativa de estudio.

2.2.1 Requerimientos de proceso

Un requerimiento puede definirse como un atributo necesario dentro de un sistema, que
puede representar una capacidad, una caracterstica o un factor de calidad del sistema
de tal manera que le sea til a los clientes o a los usuarios finales.
A nivel general los requerimientos pueden clasificarse como requerimientos indicados o
reales. Los requerimientos indicados son los entregados por el usuario al comienzo del
proyecto, en tanto que los requerimientos reales son aquellos que reflejan la
satisfaccin de las necesidades del usuario en un sistema en particular.
El proceso para convertir los requerimientos indicados en requerimientos reales
consisten en un proceso de filtrado segn el significado y otros aspectos segn se
considere.

Un proceso es un conjunto ordenado de tareas; una serie de pasos que

involucran actividades, restricciones y recursos que producen una determinada
salida esperada.
Un proceso involucra por lo general un conjunto de herramientas y tcnicas.
Un proceso es un conjunto de procedimientos de tal modo que los productos que
se construyen satisfacen un conjunto de metas o estndares.
Un procedimiento es una serie de pasos; una manera de combinar herramientas
y tcnicas para generar un producto.

Caractersticas de los procesos:

Un proceso utiliza recursos

Est sujeto a una serie de restricciones

Genera productos intermedios y finales
Cada actividad del proceso tiene criterios de entrada y salida, es decir se conoce
cuando inicia y termina el proceso
Todo proceso tiene un conjunto de principios que permiten explicar las metas de
cada actividad
Las actividades se realizan secuencialmente. Cuando el proceso implica la
construccin de algn producto, solemos referirnos al proceso como un ciclo de
vida.
El proceso de desarrollo de software se denomina ciclo de vida del software.
Los procesos son importantes porque imponen consistencia y estructura sobre
un conjunto de actividades.

Los requerimientos de nuestro sistema sern:

Que tenga ayuda en lnea.
Que sea lo ms sencillo posible pero que funcione y tenga calidad.
Que tenga acceso a bsqueda rpida.
Que tenga catlogos de productos.
Que presente reportes por pantalla e impresora.
Que imprima los resultados al trmino de los inventarios.
Que almacene registros de ventas de productos.

2.2.2 Requerimientos de los usuarios (actores involucrados)

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a ms de
un tipo de usuario, los analistas de requisitos han de tomar en consideracin a todos
los implicados para que se obtengan y depuren sus requerimientos de la forma ms
fidedigna posible.
Realmente, son muchas las personas involucradas en el desarrollo de los
requerimientos de un sistema. Es importante saber que cada una de esas personas
tienen diversos intereses y juegan roles especficos dentro de la planificacin del
proyecto; el conocimiento de cada papel desempeado, asegura que se involucren a
las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes
actividades de la IR.
No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre
clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo
como en presupuesto.
Los roles ms importantes pueden clasificarse como sigue:

Usuario final: Son las personas que usarn el sistema desarrollado. Ellos estn
relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn
familiarizados con los procesos especficos que debe realizar el software, dentro de los
parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales
de usuario.
Usuario Lder: Son los individuos que comprenden el ambiente del sistema o el
dominio del problema en donde ser empleado el software desarrollado. Ellos
proporcionan al equipo tcnico los detalles y requerimientos de las interfaces
delsistema.
Personal de Mantenimiento: Para proyectos que requieran un mantenimiento
eventual, estas personas son las responsables de la administracin de cambios, de la
implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los
procesos del producto ya finalizado.
Analistas y programadores: Son los responsables del desarrollo del producto en s;
ellos interactan directamente con el cliente.
Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para
asegurar que las condiciones presentadas por el sistema son las adecuadas.
Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.
Otras personas que pueden estar involucradas, dependiendo de la magnitud del
proyecto, pueden ser: administradores de proyecto, documentadores, diseadores de
base de datos, entre otros.
Problemas relacionados con los actores involucrados
Las vas que pueden dificultar la determinacin de los requisitos se presentan a
Continuacin:
Relacionados con los usuarios.
Los usuarios no tienen claro lo que desean
Los usuarios no se involucran en la elaboracin de requisitos escritos
Los usuarios insisten en nuevos requisitos despus de que el coste y la programacin
se hayan fijado.

2.2.1.3 Para la gestin, negociacin y anlisis.

Una vez recopilados los requisitos, el producto obtenido configura la base del anlisis
de requisitos.
Los requisitos se agrupan por categoras y se organizan en sub conjuntos, se estudia
cada requisito en relacin con el resto, se examinan los requisitos en su consistencia,
completitud y ambigedad, y se clasifican en base a las necesidades de los
clientes/usuarios.
Es corriente en clientes y usuarios solicitar ms de lo que puede realizarse,
consumiendo recursos de negocios limitados.
Tambin es relativamente comn en clientes y usuarios el proponer requisitos
contradictorios, argumentando que esa versin es esencial por necesidades
especiales.
El ingeniero del sistema debe resolver estos conflictos a travs de un proceso de
negociacin. Los clientes, usuarios y el resto de intervinientes debern clasificar sus
requisitos y discutir los posibles conflictos segn su prioridad.
Los riesgos asociados con cada requisito sern identificados y analizados.
Se efectan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el
impacto de cada requisito en el costo del proyecto y en el plazo de entrega.

Obtener informacin acerca de lo que los usuarios desean Clasificar esos deseos para
comenzar a estructurar requerimientos Identificar los niveles de jerarqua del sistema y
empezar a alojar los ya clasificados requerimientos en cada nivel. Especificar
formalmente los requerimientos de acuerdo al nivel de audiencia que se desea. Los
requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de
software, este entendimiento es necesario para poder construir software que satisfaga
las necesidades de nuestro cliente.

2.2.1.4 IEEE 830

Segn IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga
estrictamente la organizacin y el formato dados en el estndar 830, si deber incluir,
de una forma o de otra, toda la informacin presentada en dicho estndar. El estndar
de IEEE 830 no est libre de defectos ni de prejuicios, y por ello ha sido justamente
criticado por mltiples autores y desde mltiples puntos de vista, llegndose a
cuestionar incluso si es realmente un estndar en el sentido habitual que tiene el
trmino en otras ingenieras. El presente documento no pretende pronunciarse ni a

favor ni en contra de unos u otros: tan solo reproduce, con propsitos

fundamentalmente docentes, como se organizara un Documento de Requisitos segn
el estndar IEEE 830.
Definiciones: En general las definiciones de los trminos usados en estas
especificaciones estn conforme a las definiciones proporcionadas en IEEE Std
610.12-1990.
1.1 Contrato: Un documento es legalmente obligatorio y en el estarn de acuerdo las
partes del cliente y proveedor. Esto incluye los requisitos tcnicos y requerimientos de
la organizacin, costo y tiempo para un producto. Un contrato tambin puede contener
la informacin informal pero til como los compromisos o expectativas de las partes
involucradas.
1.2 Cliente: La persona (s) que pagan por el producto y normalmente (pero no
necesariamente) definen los requisitos. En la prctica el cliente y el proveedor pueden
ser miembros de la misma organizacin.
1.3 Proveedor: La persona (s) que producen un producto para un cliente.
1.4 Usuario: La persona (s) que operan o actan recprocamente directamente con el
producto. El usuario (s) y el cliente (s) no es (son) a menudo las mismas persona(s).
Propsito
En esta subseccin se definir el propsito del documento ERS y se especificara
A quien va dirigido el documento.
mbito del Sistema
En esta subseccin:
Se podr dar un nombre al futuro sistema (p.ej. Mi Sistema)
Se explicara lo que el sistema har y lo que no har.
Se describirn los beneficios, objetivos y metas que se espera alcanzar
Con el futuro sistema.
Se referenciaran todos aquellos documentos de nivel superior (p.e. en Ingeniera
De Sistemas, que incluyen Hardware y Software, debera mantenerse
La consistencia con el documento de especificacin de requisitos
Globales del sistema, si existe).
1.3. Definiciones, Acrnimos y Abreviaturas
En esta subseccin se definirn todos los trminos, acrnimos y abreviaturas
Utilizadas en la ERS.
1.4. Referencias
En esta subseccin se mostrara una lista completa de todos los documentos
Referenciados en la ERS.
2 DESCRIPCION GENERAL 4

1.5. Visin General del Documento

Esta subseccin describe brevemente los contenidos y la organizacin del
Resto de la ERS.
2. Descripcin General
En esta seccin se describen todos aquellos factores que afectan al producto
Y a sus requisitos. No se describen los requisitos, sino su contexto. Esto
Permitir definir con detalle los requisitos en la seccin 3, haciendo que sean
Ms fciles de entender.
Normalmente, esta seccin consta de las siguientes subsecciones: Perspectiva
Del producto, funciones del producto, caractersticas de los usuarios,
Restricciones, factores que se asumen y futuros requisitos.
2.1. Perspectiva del Producto
Esta subseccin debe relacionar el futuro sistema (producto software) con
Otros productos. Si el producto es totalmente independiente de otros productos,
Tambin debe especificarse aqu. Si la ERS define un producto que
Es parte de un sistema mayor, esta subseccin relacionara los requisitos del
Sistema mayor con la funcionalidad del producto descrito en la ERS, y se
Identificaran las interfaces entre el producto mayor y el producto aqu descrito.
Se recomienda utilizar diagramas de bloques.
2.2. Funciones del Producto
En esta subseccin de la ERS se mostrara un resumen, a grandes rasgos,
De las funciones del futuro sistema. Por ejemplo, en una ERS para un programa
De contabilidad, esta subseccin mostrara que el sistema soportar a el
Mantenimiento de cuentas, mostrara el estado de las cuentas y facilitara la
Facturacin, sin mencionar el enorme detalle que cada una de estas funciones
Requiere.
Las funciones debern mostrarse de forma organizada, y pueden utilizarse
Grficos, siempre y cuando dichos grficos reflejen las relaciones entre Funciones y no
el diseo del sistema.

2 DESCRIPCION GENERAL 5
2.3. Caractersticas de los Usuarios
Esta subseccin describir las caractersticas generales de los usuarios del
Producto, incluyendo nivel educacional, experiencia y experiencia tcnica.
2.4. Restricciones
Esta subseccin describir aquellas limitaciones que se imponen sobre los
Desarrolladores del producto
Polticas de la empresa

Limitaciones del hardware

Interfaces con otras aplicaciones
Operaciones paralelas
Funciones de auditoria
Funciones de control
Lenguaje(s) de programacin
Protocolos de comunicacin
Requisitos de habilidad
Criticidad de la aplicacin
Consideraciones acerca de la seguridad

2.5. Suposiciones y Dependencias

Esta subseccin de la ERS describir aquellos factores que, si cambian,
Pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presuponer
Una cierta organizacin de ciertas unidades de la empresa, o pueden
Presuponer que el sistema correr sobre cierto sistema operativo. Si cambian
Dichos detalles en la organizacin de la empresa, o si cambian ciertos detalles
Tcnicos, como el sistema operativo, puede ser necesario revisar y cambiar los
Requisitos.