capítulo 2 marco teórico (conceptos) parte 1

7/17/2019 Capítulo 2 Marco Teórico (conceptos) Parte 1

http://slidepdf.com/reader/full/capitulo-2-marco-teorico-conceptos-parte-1 1/11

Capítulo 2 Marco Teórico

El marco teórico, marco referencial o marco conceptual tiene el propósito de dar a

la investigación un sistema coordinado y coherente de conceptos y proposiciones quepermitan abordar el problema. De éste dependerá el resultado del trabajo. Significaponer en claro para el propio investigador sus postulados y supuestos, asumir losfrutos de investigaciones anteriores y esforarse por orientar el trabajo de un modocoherente. De este modo, el fin que tiene el marco teórico es el de situar el problemaque se está estudiando dentro de un conjunto de conocimientos, que permita orientarla b!squeda y ofreca una conceptualiación adecuada de los términos que seutiliaran en el trabajo. El punto de partida para construir un marco de referencia loconstituye el conocimiento previo de los fenómenos que se abordan, as" como lasense#anas que se e$traigan del trabajo de revisión bibliográfica queobligatoriamente se tiene que hacer.

En general, se podr"a afirmar que el marco teórico tiene como funciones%

& 'rientar hacia la organiación de datos y hechos significativos para descubrir lasrelaciones de un problema con las teor"as ya e$istentes.

& Evitar que el investigador aborde temáticas que, dado el estado delconocimiento, ya han sido investigadas o carecen de importancia cient"fica.

& (uiar en la selección de los factores y variables que serán estudiadas en lainvestigación, as" como sus estrategias de medición, su valide y confiabilidad.

& )revenir sobre los posibles factores de confusión o variables e$tra#as quepotencialmente podr"an generar sesgos no deseados.

*ntes de la aparición de la ingenier"a de requisitos, éstos eran competencia e$clusivadel análisis de sistemas. En esta área se elaboraron algunos métodos de desarrolloestructurado como S*+SD análisis y dise#o estructurados- De arco, /012-, S*D3análisis de sistemas y técnica de dise#o- 4oss y Schoman, /011- o SS*Danálisis estructurado de sistema y método de dise#o- Do5ns et al., /006-. 7a ideageneral de todos estos métodos consiste en comenar analiando los requisitosmediante un enfoque 8divide y vencerás9 que permita ir fraccionando el sistema enpieas más peque#as y después definir las funciones u objetivos que cada parte delsistema deber"a realiar.

:ormalmente, un tema de la ;ngenier"a de Soft5are tiene diferentes significados. Delas muchas definiciones que e$isten para requerimiento, a continuación se presenta ladefinición que aparece en el glosario de la ;EEE.



<na condición o necesidad de un usuario para resolver un problema o alcanarun objetivo. <na condición o capacidad que debe estar presente en un sistema ocomponentes de sistema para satisfacer un contrato, estándar, especificación u otrodocumento formal. <na representación documentada de una condición o capacidad.

7os requerimientos puedes dividirse en requerimientos funcionales y requerimientosno funcionales.7os requerimientos funcionales definen las funciones que el sistema será capa derealiar. Describen las transformaciones que el sistema realia sobre las entradaspara producir salidas.7os requerimientos no funcionales tienen que ver con caracter"sticas que de una uotra forma puedan limitar el sistema, como por ejemplo, el rendimiento en tiempo yespacio-, interfaces de usuario, fiabilidad robuste del sistema, disponibilidad deequipo-, mantenimiento, seguridad, portabilidad, estándares, etc.

=aracter"sticas de los requerimientos7as caracter"sticas de un requerimiento son sus propiedades principales. <n conjuntode requerimientos en estado de madure, deben presentar una serie decaracter"sticas tanto individualmente como en grupo. * continuación se presentan lasmás importantes.:ecesario% <n requerimiento es necesario si su omisión provoca una deficiencia en elsistema a construir, y además su capacidad, caracter"sticas f"sicas o factor de calidadno pueden ser reemplaados por otras capacidades del producto o del proceso.=onciso% <n requerimiento es conciso si es fácil de leer y entender.Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en unfuturo.=ompleto% <n requerimiento está completo si no necesita ampliar detalles en suredacción, es decir, si se proporciona la información suficiente para su comprensión.=onsistente% <n requerimiento es consistente si no es contradictorio con otrorequerimiento.:o ambiguo% <n requerimiento no es ambiguo cuando tiene una sola interpretación.

El lenguaje usado en su definición, no debe causar confusiones al lector.

>erificable% <n requerimiento es verificable cuando puede ser cuantificado de maneraque permita hacer uso de los siguientes métodos de verificación% inspección, análisis,demostración o pruebas.

Dificultades para definir los requerimientos



7os requerimientos no son obvios y vienen de muchas fuentes.

Son dif"ciles de e$presar en palabras el lenguaje es ambiguo-.

E$isten muchos tipos de requerimientos y diferentes niveles de detalle.

7a cantidad de requerimientos en un proyecto puede ser dif"cil de manejar.

:unca son iguales. *lgunos son más dif"ciles, más riesgosos, más importanteso más estables que otros.

7os requerimientos están relacionados unos con otros, y a su ve se relacionancon otras partes del proceso.

Antecedentes (Del Negocio)

7a e$posición debe referenciarse a investigaciones más importantes por su *ctualidady valor teórico- que se han realiado sobre el tema del estudio. Se debe asegurar quela investigación va a responder a un vac"o de conocimiento, no una ignorancia de lainvestigación.

Es requisito imprescindible una e$haustiva revisión de la bibliograf"a? las másactualiadas, revistas, tesis, etc. @acer una s"ntesis conceptual de las investigaciones.

El tratamiento de la información recopilada depende del nivel que le imprima elinvestigador.

7os antecedentes tienen como fin dar a conocer como ha sido tratado el tema,haciéndose preguntas como%

• ABué tipos de estudios se han efectuadoC• 7as caracter"sticas de lo investigado objeto, sujeto-• A=ómo se han recolectado los datosC• AEn qué lugares se ha llevado a caboC

7os antecedentes son el punto de partida para delimitar el problema ya que permiteaclarar, jugar e interpretar el problema planteado y sirve para ampliar o continuar loinvestigado.

7os antecedentes del problema consisten básicamente en efectuar una revisiónbibliográfica sobre el problema en cuestión y en consultar a e$pertos en la temática.Esta etapa aporta el marco conceptual en el que se desarrolla la investigación.



Elementos de los antecedentes del problema:

El autor *#o de Edición 3"tulo del 3ema

)oblación y muestra =onclusiones

Procesos de los Antecedentes del problema:

Detención de la literatura y otros documentos 'btención de la literatura

=onsulta de la literatura

ichaje

En la situación actual de crisis económica se pone de manifiesto un nuevo escenario

para la negociación de las empresas con las entidades financieras%

• 4estricción del =rédito.

• ayores dificultades para acceder a créditos o préstamos.

• ayores e$igencias por parte de las entidades financieras a los

empresarios para concederles préstamos.

)or todo ello, el )lan de Empresa es actualmente un requisito fundamental que e$igenlas entidades financieras a los emprendedores que quieren poner en marcha suproyecto de negocio, para que los ancos puedan analiar la viabilidad económicafinanciera de dicho proyecto.

En una serie de v"deos voy a e$plicar las distintas partes que componen un )lan deEmpresa, y como realiarlo pasó a paso.

2.2. Estado del Arte INGENIERIA DE RE!I"IT#"

El estado del arte es una modalidad de la investigación documental que permite elestudio del conocimiento acumulado escrito en te$tos- dentro de un área espec"fica.Sus or"genes se remontan a los a#os ochenta, época en la que se utiliaba como



herramienta para compilar y sistematiar información especialmente el área de cienciassociales, sin embargo, en la medida en que estos estudios se realiaron con el fin dehacer balances sobre las tendencias de investigación y como punto de partida para latoma de decisiones, el estado del arte se posicionó como una modalidad deinvestigación de la investigación. @oy en d"a se considera que en general, el estado del

arte puede abordarse desde tres perspectivas fundamentales. Sea cual fuere elabordaje del estado del arte, se considera que su realiación implica el desarrollo deuna metodolog"a resumida en tres grandes pasos% conte$tualiación, clasificación ycategoriación? los cuales son complementados por una fase adicional que permitaasociar al estado del arte de manera estructural, es decir, hacer el análisis sinónimo deinvestigación-. De esta manera se observa que la realiación de estados del artepermite la circulación de la información, genera una demanda de conocimiento yestablece comparaciones con otros conocimientos paralelos a este, ofreciendodiferentes posibilidades de comprensión del problema tratado? pues brinda más de unaalternativa de estudio.

2.2.$ Re%ueri&ientos de proceso

<n requerimiento puede definirse como un atributo necesario dentro de un sistema, quepuede representar una capacidad, una caracter"stica o un factor de calidad del sistemade tal manera que le sea !til a los clientes o a los usuarios finales.

* nivel general los requerimientos pueden clasificarse como requerimientos indicados oreales. 7os requerimientos indicados son los entregados por el usuario al comieno delproyecto, en tanto que los requerimientos reales son aquellos que reflejan la

satisfacción de las necesidades del usuario en un sistema en particular.El proceso para convertir los requerimientos indicados en requerimientos realesconsisten en un proceso de filtrado seg!n el significado y otros aspectos seg!n seconsidere.

• <n proceso es un conjunto ordenado de tareas? una serie de pasos queinvolucran actividades, restricciones y recursos que producen una determinadasalida esperada.

• <n proceso involucra por lo general un conjunto de herramientas y técnicas.• <n proceso es un conjunto de procedimientos de tal modo que los productos que

se construyen satisfacen un conjunto de metas o estándares.• <n procedimiento es una serie de pasos? una manera de combinar herramientas

y técnicas para generar un producto.

=aracter"sticas de los procesos%

• <n proceso utilia recursos



• Está sujeto a una serie de restricciones• (enera productos intermedios y finales• =ada actividad del proceso tiene criterios de entrada y salida, es decir se conoce

cuando inicia y termina el proceso• 3odo proceso tiene un conjunto de principios que permiten e$plicar las metas de

cada actividad• 7as actividades se realian secuencialmente. =uando el proceso implica la

construcción de alg!n producto, solemos referirnos al proceso como un ciclo devida.

• El proceso de desarrollo de soft5are se denomina ciclo de vida del soft5are.• 7os procesos son importantes porque imponen consistencia y estructura sobre

un conjunto de actividades.

7os requerimientos de nuestro sistema serán%• Bue tenga ayuda en l"nea.• Bue sea lo más sencillo posible pero que funcione y tenga calidad.• Bue tenga acceso a b!squeda rápida.• Bue tenga catálogos de productos.• Bue presente reportes por pantalla e impresora.• Bue imprima los resultados al término de los inventarios.• Bue almacene registros de ventas de productos.

2.2.2 Re%ueri&ientos de los usuarios (actores in'olucrados)

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más deun tipo de usuario, los analistas de requisitos han de tomar en consideración a todoslos implicados para que se obtengan y depuren sus requerimientos de la forma másfidedigna posible.

4ealmente, son muchas las personas involucradas en el desarrollo de losrequerimientos de un sistema. Es importante saber que cada una de esas personastienen diversos intereses y juegan roles espec"ficos dentro de la planificación delproyecto? el conocimiento de cada papel desempe#ado, asegura que se involucren alas personas correctas en las diferentes fases del ciclo de vida, y en las diferentes

actividades de la ;4.

:o conocer estos intereses puede ocasionar una comunicación poco efectiva entreclientes y desarrolladores, que a la ve traer"a impactos negativos tanto en tiempocomo en presupuesto.

7os roles más importantes pueden clasificarse como sigue%



Usuario final: Son las personas que usarán el sistema desarrollado. Ellos estánrelacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema? estánfamiliariados con los procesos espec"ficos que debe realiar el soft5are, dentro de losparámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manualesde usuario.

Usuario Líder: Son los individuos que comprenden el ambiente del sistema o eldominio del problema en donde será empleado el soft5are desarrollado. Ellosproporcionan al equipo técnico los detalles y requerimientos de las interfacesdelsistema.

Personal de Mantenimiento% )ara proyectos que requieran un mantenimientoeventual, estas personas son las responsables de la administración de cambios, de laimplementación y resolución de anomal"as. Su trabajo consiste en revisar y mejorar losprocesos del producto ya finaliado.

Analistas y programadores: Son los responsables del desarrollo del producto en s"?

ellos interact!an directamente con el cliente.

Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas paraasegurar que las condiciones presentadas por el sistema son las adecuadas.

Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

'tras personas que pueden estar involucradas, dependiendo de la magnitud delproyecto, pueden ser% administradores de proyecto, documentadores, dise#adores debase de datos, entre otros.

Problemas relacionados con los actores involucrados

7as v"as que pueden dificultar la determinación de los requisitos se presentan a

=ontinuación%

4elacionados con los usuarios.

7os usuarios no tienen claro lo que desean

7os usuarios no se involucran en la elaboración de requisitos escritos

7os usuarios insisten en nuevos requisitos después de que el coste y la programaciónse hayan fijado.

2.2.$. ara la gestión* negociación + an,lisis.



<na ve recopilados los requisitos, el producto obtenido configura la base del análisisde requisitos.

7os requisitos se agrupan por categor"as y se organian en sub conjuntos, se estudiacada requisito en relación con el resto, se e$aminan los requisitos en su consistencia,

completitud y ambigFedad, y se clasifican en base a las necesidades de losclientes+usuarios.

Es corriente en clientes y usuarios solicitar más de lo que puede realiarse,consumiendo recursos de negocios limitados.

3ambién es relativamente com!n en clientes y usuarios el proponer requisitoscontradictorios, argumentando que esa versión es esencial por necesidadesespeciales.

El ingeniero del sistema debe resolver estos conflictos a través de un proceso denegociación. 7os clientes, usuarios y el resto de intervinientes deberán clasificar susrequisitos y discutir los posibles conflictos seg!n su prioridad.

7os riesgos asociados con cada requisito serán identificados y analiados.

Se efect!an estimaciones del esfuero de desarrollo que se utilian para valorar elimpacto de cada requisito en el costo del proyecto y en el plao de entrega.

'btener información acerca de lo que los usuarios desean =lasificar esos deseos paracomenar a estructurar requerimientos ;dentificar los niveles de jerarqu"a del sistema yempear a alojar los ya clasificados requerimientos en cada nivel. Especificar formalmente los requerimientos de acuerdo al nivel de audiencia que se desea. 7osrequerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo desoft5are, este entendimiento es necesario para poder construir soft5are que satisfagalas necesidades de nuestro cliente.

2.2.$.- IEEE /

Seg!n ;EEE, un buen Documento de 4equisitos, pese a no ser obligatorio que sigaestrictamente la organiación y el formato dados en el estándar 2GH, si deberá incluir,de una forma o de otra, toda la información presentada en dicho estándar. El estándar de ;EEE 2GH no está libre de defectos ni de prejuicios, y por ello ha sido justamentecriticado por m!ltiples autores y desde m!ltiples puntos de vista, llegándose acuestionar incluso si es realmente un estándar en el sentido habitual que tiene eltérmino en otras ingenier"as. El presente documento no pretende pronunciarse ni a



favor ni en contra de unos u otros% tan solo reproduce, con propósitosfundamentalmente docentes, como se organiar"a un Documento de 4equisitos seg!nel estándar ;EEE 2GH.

Definiciones: En general las definiciones de los términos usados en estasespecificaciones están conforme a las definiciones proporcionadas en ;EEE StdI/H./6J/00H.

/./ =ontrato% <n documento es legalmente obligatorio y en el estarán de acuerdo laspartes del cliente y proveedor. Esto incluye los requisitos técnicos y requerimientos dela organiación, costo y tiempo para un producto. <n contrato también puede contenerla información informal pero !til como los compromisos o e$pectativas de las partesinvolucradas.

/.6 =liente% 7a persona s- que pagan por el producto y normalmente pero nonecesariamente- definen los requisitos. En la práctica el cliente y el proveedor puedenser miembros de la misma organiación.

/.G )roveedor% 7a persona s- que producen un producto para un cliente.

/.K <suario% 7a persona s- que operan o act!an rec"procamente directamente con elproducto. El usuario s- y el cliente s- no es son- a menudo las mismas personas-.

PropósitoEn esta subsección se definirá el propósito del documento E4S y se especificara

* quien va dirigido el documento.

Lmbito del Sistema MEn esta subsección%

• Se podrá dar un nombre al futuro sistema p.ej. i Sistema-• Se e$plicara lo que el sistema hará y lo que no hará.• Se describirán los beneficios, objetivos y metas que se espera alcanar • =on el futuro sistema.• Se referenciaran todos aquellos documentos de nivel superior p.e. en ;ngenier"a• De Sistemas, que incluyen @ard5are y Soft5are, deber"a mantenerse• 7a consistencia con el documento de especificación de requisitos• (lobales del sistema, si e$iste-.

/.G. Definiciones, *crónimos y *breviaturas

En esta subsección se definirán todos los términos, acrónimos y abreviaturas<tiliadas en la E4S.

/.K. 4eferenciasEn esta subsección se mostrara una lista completa de todos los documentos4eferenciados en la E4S.

6 DES=4;)=;': (E:E4*7 K



/.N. >isión (eneral del DocumentoEsta subsección describe brevemente los contenidos y la organiación del4esto de la E4S.

6. Descripción (eneral

En esta sección se describen todos aquellos factores que afectan al productoO a sus requisitos. :o se describen los requisitos, sino su conte$to. Esto)ermitirá definir con detalle los requisitos en la sección G, haciendo que seanás fáciles de entender.:ormalmente, esta sección consta de las siguientes subsecciones% )erspectivaDel producto, funciones del producto, caracter"sticas de los usuarios,4estricciones, factores que se asumen y futuros requisitos.

6./. )erspectiva del )roductoEsta subsección debe relacionar el futuro sistema producto soft5are- con'tros productos. Si el producto es totalmente independiente de otros productos,

3ambién debe especificarse aqu". Si la E4S define un producto queEs parte de un sistema mayor, esta subsección relacionara los requisitos delSistema mayor con la funcionalidad del producto descrito en la E4S, y se;dentificaran las interfaces entre el producto mayor y el producto aqu" descrito.Se recomienda utiliar diagramas de bloques.

6.6. unciones del )roductoEn esta subsección de la E4S se mostrara un resumen, a grandes rasgos,De las funciones del futuro sistema. )or ejemplo, en una E4S para un programaDe contabilidad, esta subsección mostrara que el sistema soportar a elantenimiento de cuentas, mostrara el estado de las cuentas y facilitara laacturación, sin mencionar el enorme detalle que cada una de estas funciones4equiere.7as funciones deberán mostrarse de forma organiada, y pueden utiliarse(ráficos, siempre y cuando dichos gráficos reflejen las relaciones entre unciones y noel dise#o del sistema.

6 DES=4;)=;': (E:E4*7 M N6.G. =aracter"sticas de los <suariosEsta subsección describirá las caracter"sticas generales de los usuarios del)roducto, incluyendo nivel educacional, e$periencia y e$periencia técnica.

6.K. 4estricciones• Esta subsección describirá aquellas limitaciones que se imponen sobre los• Desarrolladores del producto• )ol"ticas de la empresa



• 7imitaciones del hard5are• ;nterfaces con otras aplicaciones• 'peraciones paralelas• unciones de auditoria• unciones de control• 7enguajes- de programación• )rotocolos de comunicación• 4equisitos de habilidad• =riticidad de la aplicación• =onsideraciones acerca de la seguridad

6.N. Suposiciones y DependenciasEsta subsección de la E4S describirá aquellos factores que, si cambian,)ueden afectar a los requisitos. )or ejemplo, los requisitos pueden presuponer <na cierta organiación de ciertas unidades de la empresa, o pueden

)resuponer que el sistema correrá sobre cierto sistema operativo. Si cambianDichos detalles en la organiación de la empresa, o si cambian ciertos detalles3écnicos, como el sistema operativo, puede ser necesario revisar y cambiar los4equisitos.

capítulo 2 marco teórico (conceptos) parte 1

Documents