EcuRed - Contribuciones del colaborador [es]

Usuario:Laortizucihol

2012-09-14T12:42:18Z

Laortizucihol:

<div style="float: right; width: 30%;">
{{Sistema:Cuadro|negro
|título=Intereses y Afinidades
|enlace=
|logo=200px_Logotipo.png
|px=19
|leyenda=
|altura=120
|contenido={{Usuario:Etiquetas/anime}}
{{Usuario:Etiquetas/Real Madrid}}
}}
{{Ficha_Usuario_(avanzada)

|apellidos=Ortiz Azaharez
|nombre=Leydis
|nivel= Superior
|título=Ingeniero en Ciencias Informáticas
|temas=[[Informática]],[[Música]]
|institución= UCI
|municipio=[[Moa]]
|provincia=[[Holguín]]
|país=Cuba

|colaboradores=yes

}}</div>
<div style="float: left; width: 65%;"><br>
{{Sistema:Cuadro|azul
|título=Bienvenido a mi portal de colaborador
|enlace=
|logo=200px_Logotipo.png
|px=21
|leyenda=EcuRed
|altura=
|contenido=Hola, Mi nombre es Leydis Ortiz Azaharez y trabajo en el Centro de Desarrollo Territorial Holguín, perteneciente a la Universidad de Ciencias Informáticas (UCI).

'''''Trabajos Publicados'''''
* Servicio de Soporte(HELP DESK) .

'''''Correo Electrónico'''''
*[mailto:laortiz@hlg.uci.cu laortiz@hlg.uci.cu]

'''''Teléfono del Trabajo'''''
*422733 ext: 144

}}</div>

Help Desk

2012-09-14T12:33:28Z

Laortizucihol:

{{Definición
|nombre=HELP DESK
|imagen= helpdesk.jpg
}} <div align=justify>
''' HELP DESK'''. Un Help Desk (Ayuda de Escritorio) es una parte del grupo de soporte técnico establecido por una organización para mantener operando sus PCs en forma eﬁciente. El Help Desk lo opera, en la mayoría de los casos, un grupo de [[técnicos]] a quienes algunas veces se les llama [[analistas]] de Help Desk o técnicos de soporte; ellos están capacitados para arreglar todo tipo de PCs y aplicaciones de software.
El número de PCs, por lo general determina el número de técnicos del Help Desk que brindarán servicio a la [[comunidad informática]], sin embargo los técnicos no están sentados físicamente ante un escritorio: el Help Desk es realmente otro término empleado para denominar al departamento de ayuda.

== Objetivo ==
El Help Desk ayuda al departamento de Tecnología de la Información en el mantenimiento de altos niveles de servicio a la comunidad de [[usuarios ]] vinculados a la informática.
== Analista o técnicos de Soporte ==
El analista de Help Desk como rol principal dentro de este grupo debe tener habilidades, conocimientos y capacidades para desempeñar este cargo, debe usar lógica y razonamiento para identificar las fortalezas y debilidades de soluciones alternativas brindadas a los usuarios, en conocimientos, debe ser de [[software]], [[hardware]], comunicaciones, [[redes]], [[Internet]], [[correo electrónico]], temas relacionados con tecnología informática, y capacidades como escuchar y comprender la información y las ideas expuestas en forma oral, aplicar reglas generales a problemas específicos para lograr respuestas con sentido.

== Funciones ==
En la mayoría de las organizaciones, el Help Desk es parte del departamento de informática (TI). Sus funciones son varias pero, por lo general, proporciona soporte reactivo y proactivo, tanto para PCs como para el usuario final. A través del soporte reactivo, el Help Desk resuelve problemas que el usuario reporta y lo ayuda a realizar las tareas necesarias para llevar a cabo un [[proyecto]]. También trata diversos problemas, tales como casos de [[virus]] en la PC, problemas de interconexión a la [[red]] entre otros.

A través del soporte proactivo, el Help Desk trabaja para evitar que ocurran problemas. Por ejemplo, sus técnicos les enseñan a los usuarios cómo realizar tareas que les ayudarán a evitar problemas comunes relacionados con las PCs antes de que estos ocurran. De esta forma, cuanto más soporte proactivo proporcione un Help Desk, menos soporte reactivo tendrá que realizar.
El Help Desk se basa en un conjunto de recursos técnicos y humanos que permiten dar soporte a diferentes niveles de usuarios informáticos de una [[empresa]].

== Fuentes ==
* Artículo: [http://es.scribd.com/doc/4348991/Manual-Help-Desk-1 ]. Disponible en_ " http://es.scribd.com”. Consultado: 10 de septiembre del 2012.
* Artículo: [http://helpdeskspecialist.blogspot.com/2011/01/definicion.html ]. Disponible en_ " http://helpdeskspecialist.blogspot.com”. Consultado: 11 de septiembre del 2012.
* Artículo: [http://mmujica.wordpress.com/2008/10/09/help-desk/]. Disponible en_ "http://mmujica.wordpress.com”. Consultado: 11 de septiembre del 2012.

[[Categoría: Ciencias informáticas]]

Help Desk

2012-09-14T12:29:54Z

Laortizucihol:

{{Definición
|nombre=HELP DESK
|imagen= helpdesk.jpg
}} <div align=justify>
''' HELP DESK'''. Un Help Desk (Ayuda de Escritorio) es una parte del grupo de soporte técnico establecido por una organización para mantener operando sus PCs en forma eﬁciente. El Help Desk lo opera, en la mayoría de los casos, un grupo de [[técnicos]] a quienes algunas veces se les llama analistas de Help Desk o técnicos de soporte; ellos están capacitados para arreglar todo tipo de [[PCs ]] y aplicaciones de software.
El número de PCs, por lo general determina el número de técnicos del Help Desk que brindarán servicio a la [[comunidad informática]], sin embargo los técnicos no están sentados físicamente ante un escritorio: el Help Desk es realmente otro término empleado para denominar al departamento de ayuda.

== Objetivo ==
El Help Desk ayuda al departamento de Tecnología de la Información en el mantenimiento de altos niveles de servicio a la comunidad de [[usuarios ]] vinculados a la informática.
== Analista o técnicos de Soporte ==
El analista de Help Desk como rol principal dentro de este grupo debe tener habilidades, conocimientos y capacidades para desempeñar este cargo, debe usar lógica y razonamiento para identificar las fortalezas y debilidades de soluciones alternativas brindadas a los usuarios, en conocimientos, debe ser de [[software]], [[hardware]], comunicaciones, redes, [[Internet]], correo electrónico, temas relacionados con tecnología informática, y capacidades como escuchar y comprender la información y las ideas expuestas en forma oral, aplicar reglas generales a problemas específicos para lograr respuestas con sentido.

== Funciones ==
En la mayoría de las organizaciones, el Help Desk es parte del departamento de informática (TI). Sus funciones son varias pero, por lo general, proporciona soporte reactivo y proactivo, tanto para PCs como para el usuario final. A través del soporte reactivo, el Help Desk resuelve problemas que el usuario reporta y lo ayuda a realizar las tareas necesarias para llevar a cabo un [[proyecto]]. También trata diversos problemas, tales como casos de [[virus]] en la PC, problemas de interconexión a la [[red]] entre otros.

A través del soporte proactivo, el Help Desk trabaja para evitar que ocurran problemas. Por ejemplo, sus técnicos les enseñan a los usuarios cómo realizar tareas que les ayudarán a evitar problemas comunes relacionados con las PCs antes de que estos ocurran. De esta forma, cuanto más soporte proactivo proporcione un Help Desk, menos soporte reactivo tendrá que realizar.
El Help Desk se basa en un conjunto de recursos técnicos y humanos que permiten dar soporte a diferentes niveles de usuarios informáticos de una [[empresa]].

== Fuentes ==
* Artículo: [http://es.scribd.com/doc/4348991/Manual-Help-Desk-1 ]. Disponible en_ " http://es.scribd.com”. Consultado: 10 de septiembre del 2012.
* Artículo: [http://helpdeskspecialist.blogspot.com/2011/01/definicion.html ]. Disponible en_ " http://helpdeskspecialist.blogspot.com”. Consultado: 11 de septiembre del 2012.
* Artículo: [http://mmujica.wordpress.com/2008/10/09/help-desk/]. Disponible en_ "http://mmujica.wordpress.com”. Consultado: 11 de septiembre del 2012.

[[Categoría: Ciencias informáticas]]

Help Desk

2012-09-14T12:27:15Z

Laortizucihol: Página creada con '{{Definición |nombre=HELP DESK |imagen= helpdesk.jpg }} <div align=justify> ''' HELP DESK'''. Un Help Desk (Ayuda de Escritorio) es una parte del grupo de soporte técnico est...'

{{Definición
|nombre=HELP DESK
|imagen= helpdesk.jpg
}} <div align=justify>
''' HELP DESK'''. Un Help Desk (Ayuda de Escritorio) es una parte del grupo de soporte técnico establecido por una organización para mantener operando sus PCs en forma eﬁciente. El Help Desk lo opera, en la mayoría de los casos, un grupo de [[técnicos]] a quienes algunas veces se les llama analistas de Help Desk o técnicos de soporte; ellos están capacitados para arreglar todo tipo de [[PCs ]] y aplicaciones de software.
El número de PCs, por lo general determina el número de técnicos del Help Desk que brindaran servicio a la [[comunidad informática]], sin embargo los técnicos no están sentados físicamente ante un escritorio: el Help Desk es realmente otro término empleado para denominar al departamento de ayuda.

== Objetivo ==
El Help Desk ayuda al departamento de Tecnología de la Información en el mantenimiento de altos niveles de servicio a la comunidad de [[usuarios ]] vinculados a la informática.
== Analista o técnicos de Soporte ==
El analista de Help Desk como rol principal dentro de este grupo debe tener habilidades, conocimientos y capacidades para desempeñar este cargo, debe usar lógica y razonamiento para identificar las fortalezas y debilidades de soluciones alternativas brindadas a los usuarios, en conocimientos, debe ser de [[software]], [[hardware]], comunicaciones, redes, [[Internet]], correo electrónico, temas relacionados con tecnología informática, y capacidades como escuchar y comprender la información y las ideas expuestas en forma oral, aplicar reglas generales a problemas específicos para lograr respuestas con sentido.

== Funciones ==
En la mayoría de las organizaciones, el Help Desk es parte del departamento de informática (TI). Sus funciones son varias pero, por lo general, proporciona soporte reactivo y proactivo, tanto para PCs como para el usuario final. A través del soporte reactivo, el Help Desk resuelve problemas que el usuario reporta y lo ayuda a realizar las tareas necesarias para llevar a cabo un [[proyecto]]. También trata diversos problemas, tales como casos de [[virus]] en la PC, problemas de interconexión a la [[red]] entre otros.
A través del soporte proactivo, el Help Desk trabaja para evitar que ocurran problemas. Por ejemplo, sus técnicos les enseñan a los usuarios cómo realizar tareas que les ayudarán a evitar problemas comunes relacionados con las PCs antes de que estos ocurran. De esta forma, cuanto más soporte proactivo proporcione un Help Desk, menos soporte reactivo tendrá que realizar.
El Help Desk se basa en un conjunto de recursos técnicos y humanos que permiten dar soporte a diferentes niveles de usuarios informáticos de una [[empresa]].

== Fuentes ==
* Artículo: [http://es.scribd.com/doc/4348991/Manual-Help-Desk-1 ]. Disponible en_ " http://es.scribd.com”. Consultado: 10 de septiembre del 2012.
* Artículo: [http://helpdeskspecialist.blogspot.com/2011/01/definicion.html ]. Disponible en_ " http://helpdeskspecialist.blogspot.com”. Consultado: 11 de septiembre del 2012.
* Artículo: [http://mmujica.wordpress.com/2008/10/09/help-desk/]. Disponible en_ "http://mmujica.wordpress.com”. Consultado: 11 de septiembre del 2012.

[[Categoría: Ciencias informáticas]]

Archivo:Helpdesk.jpg

2012-09-14T12:25:29Z

Laortizucihol:

== Sumario ==

== Estado de copyright: ==

== Fuente: ==

Metodología para la elicitación de requisitos

2011-12-16T21:10:58Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= Tareas_elicitacion.jpeg‎
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.

* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.

* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .

* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .

* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información.

* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: [[casos de uso]], plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.

* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los [[requisitos no funcionales]] del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las [[entrevistas]], el [[Joint Application Development]] (JAD) o Desarrollo Conjunto de Aplicaciones, el [[Brainstorming]] o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y [[análisis]] por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:

#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#[[Planificar]] las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por [[IBM]] en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se basa en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una [[filosofía]] de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :

#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :

#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un [[lenguaje natural]].

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Usuario:Laortizucihol

2011-12-16T21:07:27Z

Laortizucihol:

<div style="float: right; width: 30%;">
{{Sistema:Cuadro|negro
|título=Intereses y Afinidades
|enlace=
|logo=200px_Logotipo.png
|px=19
|leyenda=
|altura=120
|contenido={{Usuario:Etiquetas/anime}}
{{Usuario:Etiquetas/Real Madrid}}
}}
{{Ficha_Usuario_(avanzada)

|apellidos=Ortiz Azaharez
|nombre=Leydis
|nivel= Superior
|título=Ingeniero en Ciencias Informáticas
|temas=[[Informática]],[[Música]]
|institución= UCI
|municipio=[[Moa]]
|provincia=[[Holguín]]
|país=Cuba

|colaboradores=yes

}}</div>
<div style="float: left; width: 65%;"><br>
{{Sistema:Cuadro|azul
|título=Bienvenido a mi portal de colaborador
|enlace=
|logo=200px_Logotipo.png
|px=21
|leyenda=EcuRed
|altura=
|contenido=Hola, Mi nombre es Leydis Ortiz Azaharez y trabajo en el Centro de Desarrollo Territorial Holguín, perteneciente a la Universidad de Ciencias Informáticas (UCI).

'''''Trabajos Publicados'''''
* Metodología para la elicitación de requisitos.

'''''Correo Electrónico'''''
*[mailto:laortiz@hlg.uci.cu laortiz@hlg.uci.cu]

'''''Teléfono del Trabajo'''''
*422733 ext: 144

}}</div>

Metodología para la elicitación de requisitos

2011-12-16T21:05:04Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= Tareas_elicitacion.jpeg‎
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: [[casos de uso]], plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los [[requisitos no funcionales]] del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las [[entrevistas]], el [[Joint Application Development]] (JAD) o Desarrollo Conjunto de Aplicaciones, el [[Brainstorming]] o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y [[análisis]] por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:

#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#[[Planificar]] las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por [[IBM]] en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se basa en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una [[filosofía]] de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :

#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :

#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un [[lenguaje natural]].

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Metodología para la elicitación de requisitos

2011-12-16T21:00:02Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= Tareas_elicitacion.jpeg‎
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Metodología para la elicitación de requisitos

2011-12-16T20:58:11Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= elicitacion.jpg
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Metodología para la elicitación de requisitos

2011-12-16T20:56:40Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= elicitacion.jpg
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Otras técnicas ==

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Metodología para la elicitación de requisitos

2011-12-16T20:55:46Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= Tareas_elicitacion.jpg
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Otras técnicas ==

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Metodología para la elicitación de requisitos

2011-12-16T20:54:39Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= elicitacion.jpg
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Otras técnicas ==

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Archivo:Tareas elicitacion.jpeg

2011-12-16T20:53:14Z

Laortizucihol:

== Sumario ==

== Estado de copyright: ==

== Fuente: ==

Metodología para la elicitación de requisitos

2011-12-16T20:49:57Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png

}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= Tareas_elicitacion.jpeg
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Otras técnicas ==

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Metodología para la elicitación de requisitos

2011-12-16T20:41:52Z

Laortizucihol:

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.png
|concepto= La elicitación de requisitos es la actividad que se considera como el primer paso en un proceso de ingeniería de requisitos.
}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= Tareas.jpg
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Otras técnicas ==

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]

Archivo:Metodología elicitación.png

2011-12-16T20:40:19Z

Laortizucihol:

== Sumario ==

== Estado de copyright: ==

== Fuente: ==

Metodología para la elicitación de requisitos

2011-12-16T20:37:30Z

Laortizucihol: Página creada con ' {{Definición |nombre=Metodología para la elicitación de requisitos |imagen= Metodología_elicitación.jpg |concepto= La elicitación de ...'

{{Definición
|nombre=Metodología para la elicitación de requisitos
|imagen= Metodología_elicitación.jpg
|concepto= La elicitación de requisitos es la actividad que se considera como el primer paso en un proceso de ingeniería de requisitos.
}}<div align=justify>
'''Metodología para la elicitación de requisitos'''. La [[elicitación de requisitos]] es la actividad que se considera como el primer paso en un proceso de [[ingeniería de requisitos]]. Debido a que existen muchas [[técnicas]] disponibles para elicitar [[requisitos]], es necesario contar con un método que sirva de guía para su aplicación, teniendo en cuenta que, cada método tiene fortalezas y debilidades y que además está orientado hacia un dominio específico .

== Objetivo ==

El objetivo fundamental en la aplicación de esta [[metodología]] es la definición de las tareas a realizar , los [[productos]] que se van a obtener y las técnicas a emplear durante el desarrollo de la elicitación de requisitos en la fase de ingeniería de requisitos del desarrollo de un sistema o [[software]].
Esta metodología se basa en la creación de dos tipo de [[productos]]: los productos entregables que no son más que los que se le hace una entrega oficial al cliente dada una fecha previamente acordada; y los productos no entregables que son los que se generan internos al desarrollo del [[proceso]] y no se entregan al [[cliente]]. Es importante destacar que dentro de los productos entregables se pueden destacar el [[Documento de Requisitos del Sistema]].

== Funciones ==
{{Definición
|nombre=Tareas de elicitación de requisitos
|imagen= Tareas.jpg
}}
La ingeniería de software es más que [[programar]] y por su parte la ingeniería de requerimientos tine que ver con aquellas [[actividades]] en pos de entender las necesidades de los clientes y éstas llevarlas a un conjunto de sentencias precisas y no ambiguas. Por esta razón es que se emplean metodologías para llevar a cabo los procesos relacionados con la elicitación de requisitos y con ellas traen aparejados un cúmulo de tareas recomendadas para obtener los productos que se necesitan.
* '''Tarea 1: Obtener información sobre el dominio del problema y el sistema actual''': Esta tarea puede ser opcional y tiene como objetivo fundamental conocer el dominio del problema y los contextos organizacional y operacional, o sea, la situación actual. Se recomienda la construcción de un glosario de términos y un modelado del sistema actual.
* '''Tarea 2: Preparar y realizar las reuniones de elicitación/negociación''': De acuerdo a la información recopilada anteriormente es necesario identificar a los usuarios participantes con el propósito de conocer las necesidades de los clientes y resolver, por parte del equipo de desarrollo, los posibles conflictos. Se recomiendan técnicas de elicitación de requisitos y técnicas de negociación como WinWin .
* '''Tarea 3: Identificar/revisar los objetivos del sistema''': A partir de la tarea anterior se identifican los objetivos a alcanzar una vez que el software a desarrollar esté en explotación y revisar los objetivos identificados, en caso de haber conflictos . Se recomiendan análisis de factores críticos o alguna técnica similar de identificación de objetivos y la plantilla para especificar los objetivos del sistema .
* '''Tarea 4: Identificar/revisar los requisitos de información ''': A partir de la información de las tareas 1 y 2, y los objetivos identificados en la 3, en esta tarea se debe identificar, o revisar si existen conflictos, qué información es relevante para el cliente y se deberá gestionar y almacenar el sistema software a desarrollar, así como qué restricciones o reglas de negocio debe cumplir dicha información . Se recomiendan: la plantilla para requisitos de almacenamiento de información y la plantilla para requisitos de restricciones de información .
* '''Tarea 5: Identificar/revisar los requisitos funcionales ''': De acuerdo a las tareas anteriores se debe identificar los actores que interactuarán con el sistema, los requisitos funcionales, expresados en casos de uso así como su especificación correspondiente y su revisión en caso de conflictos . Se recomiendan técnicas como: casos de uso, plantillas para actores, plantillas para casos de uso y plantillas para requisitos funcionales.
* '''Tarea 6: Identificar/revisar los requisitos no funcionales ''': Con la información obtenida anteriormente se deben identificar y revisar los requisitos no funcionales del sistema software a desarrollar. Se recomiendan técnicas como la plantilla para requisitos no funcionales .
* '''Tarea 7: Priorizar objetivos y requisitos '''.

== Técnicas ==

La metodología para la elicitación de requerimientos de software describe algunas de las técnicas que se proponen para obtener los productos de las tareas que se han descrito. Las que se usan con más frecuencia son: las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el Brainstorming o tormenta de ideas y la utilización de escenarios, más conocidos como casos de uso. A éstas que se describen a continuación se le adicionan otras complementarias como la observación in situ, el estudio de documentación, los cuestionarios, la inmersión en el negocio del cliente o haciendo que los ingenieros de requisitos sean aprendices del cliente .

*'''Entrevistas'''
Es la técnica de elicitación más utilizada, y de hecho es prácticamente inevitable en cualquier proceso de desarrollo de un sistema software ya que es una de las formas de comunicación más natural entre personas. En esta técnica se pueden identificar tres fases: preparación, realización y análisis por lo que no deben improvisarse, o sea debe tener una preparación previa a través de tareas como:
#Estudiar el dominio del problema.
#Seleccionar a las personas a las que se va a entrevistar .
#Determinar el objetivo y contenido de las entrevistas .
#Planificar las entrevistas .

*'''Join Application Development (JAD)'''
La técnica denominada JAD, desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales. Con la aplicación de esta técnica se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Se base en cuatro principios: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.
Dentro de la técnica del JAD se distinguen tres fases :
#Adaptación .
#Celebración de las sesiones JAD (presentación , definir objetivos y requisitos , delimitar el ámbito del sistema , documentar temas abiertos , concluir la sesión ) .
#Conclusión (completar la documentación , revisar la documentación , validar la documentación ) .

*'''Brainstorming'''
El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas . Es muy fácil de aprender y requiere poca organización .
En el brainstorming se distinguen las siguientes fases :
#Preparación .
#Generación .
#Consolidación (revisar , descartar y priorizar ideas ).
#Documentación.

*'''Utilización de escenarios o casos de uso:'''
Un caso de uso es la descripción de una secuencia de actividades entre el sistema y uno o más actores. Presentan ciertas ventajas ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios . Para su descripción se proponen plantillas, en las que se describen las interacciones usando un lenguaje natural.

== Otras técnicas ==

== Fuentes ==

* Eduardo Fernández-Medina y Mario Piattini . "Elicitación de Requisitos de Seguridad en Procesos de Negocio" . Departamento de Tecnologías y Sistemas de Información, Universidad de Castilla-La Mancha , Ciudad Real , España .
* Amador Durán Toro y Beatriz Bernárdez Jiménez . "Metodología para la Elicitación de Requisitos de Sistemas Software ". Departamento de Lenguajes y Sistemas Informáticos, Escuela Técnica Superior de Ingeniería Informática , Sevilla. Octubre de 2001 . Informe Técnico LSI–2000–10 (revisado) .
* Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico(Quinta Edición). Madrid: Concepción Femández Madrid, [[2002]]. 0-07-709677-0.

[[Category:Ciencias_informáticas]]