SlideShare una empresa de Scribd logo

Tareas de ingenieria de requerimientos

nenyta08
nenyta08
1 de 12
Descargar para leer sin conexión
INSTITUTO
 TECNOLÓGICO DE
                                    NOMBRE DE LA UNIDAD:

    TUXTEPEC
                                    INGENERIA DE REQUISITOS



FUNDAMENTO DE INGENERIA
      DE SOFTWARE




             ALUMNOS:

  MARIA DEL ROSARIO ANTONIO GOMEZ
  CLEOTILDE JORGE RAFAEL
  KEREN ARADI MARTINEZ HERRERA
  CRISTHIAN JOAQUIN CONTI SANCHEZ                Tema
  ANTONIO VICIENTE MENDOZA          Tareas de ingeniería de
                                    software
                                    19/09/2012
Introducción


La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo
que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una
solución razonable, especificar la solución sin ambigüedades, validar la
especificación, y administrar los requisitos conforme estos se transforman en un
sistema operacional. Existen muchos procesos de desarrollo de software con una
gran serie de estándares para medir.En el proceso de la ingeniería de requisitos
se   ejecutan   las   tareas   de   inicio,   obtención,   elaboración,   negociación,
especificación, validación y gestión.     Dichas funciones deben adaptarse a las
necesidades y particularidades de cada proyecto. En este caso se hablara de las
tareas, actividades o funciones que debe efectuar para llegar a esta meta.
TAREAS DE INGENERÍA DE
                              SOTWARE

                                       INICIO
Tienepor objetivo identificar el ámbito general del proyecto. Comienza con una
serie de conversaciones informales entre los participantes del mismo (cliente,
usuarios, grupo de desarrollo).
Esta fase suele estar acompañada de los documentos de definición de la visión
global y la visión de dominio del sistema.


Según Carpers Jones dice “por lo general, las semillas de los desastres más
importantes en software se siembra en los primeros tres meses desde el comienzo
del proyecto”


En algunos casos una conversación informal es todo lo que se necesita para
precipitar un esfuerzo importante de ingeniería del software. Pero en general, la
mayoría de los proyectos comienza cuando se identifica una necesidad de
negocios o se descubre un nuevo mercado o servicio potencial. Los participantes
de la comunidad de negocios(es decir, los gerentes, gentes de mercadotecnia,
gentes de producto) definen un caso de negocios para la idea, tratan de identificar
la amplitud y profundidad del mercado, hacen un análisis preliminar de factibilidad,
e identifican una descripción funcional del ámbito del proyecto. Toda esta
información está sujeta a cambios (una situación probable) pero es suficiente para
suscitar conversaciones con la organización de ingeniería del software.
Al inicio del proyecto los ingenieros de software hacen una serie de preguntas
libres de contexto, el objetivo es establecer una comprensión básica del problema,
las personas que quieren una solución, la naturaleza de la solución que se desea,
y la efectividad de la comunicación preliminar entre el cliente y el desarrollador.
OBTENCIÓN
Sugiere a los ingenieros actividades de recopilación de requisitos de manera
organizada.Parece muy simple preguntar al cliente, a los usuarios y otros
interesados cuáles son los objetivos para el sistema o producto, que es lo que se
debe lograr, de que forma el producto satisface las necesidades del negocio y por
último como se utilizara el sistema o producto día a día. Pero no es simple, es muy
difícil ya que se identifican una serie de problemas que ayudan a entender porque
es difícil la obtención de requisitos:


       Problema de ámbito: El límite del sistema está mal definido o los
       clientes/usuarios especifican detalles técnicos innecesarios que pueden
       confundir, en lugar de clarificar, los objetivos generales del sistema.


       Problemas de comprensión: Los clientes/usuarios no están seguros por
       completo de que es lo se necesita, comprenden poco acerca de las
       capacidades ylimitaciones de sus ambiente de computo, no comprende del
       todo dominio del problema, tienen dificultades al comunicar necesidades al
       ingeniero de sistema, omiten información que consideran “obvia”,
       especifican requisitos que chocan          con las necesidades de otros
       clientes/usuarios, o especifican requisitos ambiguos o inestable.


       Problemas de volatilidad:Los problemas cambiara conformé transcurre el
       tiempo.
       Para ayudar a superar estos problemas, los ingenieros de requisitos deben
       realizar en forma organizada la actividad de recopilación de requisitos


                                  ELABORACIÓN
Los ingenieros de software crean un modelo de análisis con la información
obtenida del cliente en las fases de inicio y obtención.       El modelo de análisis
define el dominio de la información, las funciones y el compartimiento del
problema.La información conseguida con el cliente durante el inicio y obtención se
expande y se refina durante la elaboración. Esta actividad de la ingeniería de
requisitos se enfoca en el desarrollo de un modelo técnico refinado de las
funciones, características y restricciones del software.


La elaboración del modelado del análisis y su componente de una serie de tareas
de modelado y refinamiento. La elaboración se conduce mediante la creación y
refinamiento de escenarios del usuario que describen la forma en que el usuario
final(y otros actores) interactuaran con el sistema. Cada escenario del usuario se
analiza para obtener clases del análisis: entidades del dominio de negocios
visibles para el usuario final. Se definen los atributos de cada clase de análisis y
se identifican los servicios que requiere cada clase. Se identifican las relaciones y
la colaboración entre las clases y se produce una variedad de diagramas de UML
complementarios.


El resultado final de la elaboración es un modelo de análisis que definen el
dominio de la información, las funciones y el comportamiento del problema.


                                 NEGOCIACIÓN
Durante esta etapa el ingeniero de requisitos debe negociar con el cliente los
alcances y límites del sistema.     De forma iterativa los requisitos se priorizan,
modifican, combinan o eliminan buscando acuerdos que beneficien a todas las
partes.
Dados los recursos limitados del negocio, no resulta inusual que los clientes y
usuarios pidan más de lo que se puede lograr. También es relativamente común
que diferentes clientes o usuarios propongan requisitos que entran en conflicto
entre sí al argumentar que su versión es “esencial para nuestra necesidades
especiales”.
El ingeniero de requisitos debe conciliar estos conflictos por medio de un proceso
de negociación. Se pide a los clientes, usuarios y otros interesados que ordenen
sus requisitos y después discutan los conflictos relacionados con la prioridad. Se
identifican y analizan los riesgos asociados con cada requisito. Se hacen
“estimaciones” preliminares del esfuerzo requerido para su desarrollo y después
se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y
sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se
eliminan, combinan o modifican de forma que cada parte alcance cierto grado de
satisfacción.


                             ESPECIFICACIÓN
Es el producto final de la ingeniería de requisitos, y se convierte en la materia
prima para las actividades posteriores en el proceso de desarrollo del sistema. La
formalidad y especificación varían dependiendo de la complejidad del proyecto.


En el contexto de los sistemas basados en computadora (y en software), el
término especificación tiene significados diferentes para personas distintas. Una
especificación puede ser un documento escrito, un conjunto de modelos gráficos,
un modelo matemático formal, una colección de escenarios de uso, un prototipo o
cualquier combinación de estos.
Algunos sugieren que para una especificación se debe desarrollar y utilizar una
“plantilla estándar”argumenta que esto conduce a que los requisitos sean
presentados de una manera         másconsciente y por ende más entendible. Sin
embargo, algunas veces es necesario ser flexible mientras se desarrolla una
especificación.
Respecto de sistema grande el mejor enfoque podría ser un documento escrito
que combinara descripciones en el lenguaje natural y modelos gráficos. Por otro
lado, en cuanto a productos o sistemas más pequeños, podría ser que no se
necesite más que escenarios de uso, cuando dichos sistemas residan en
ambientes técnicos que se comprendan bien.
La especificación es el producto de trabajo final que genera a ingeniería de
requisitos. Sirve como base para las actividades de ingeniería de software
subsecuentes.

Recomendados

modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software Brihany Rossell
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónYare LoZada
 
TAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSTAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSxinithazangels
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwaresergio
 
Ingenieria de requerimientos 1
Ingenieria de requerimientos 1Ingenieria de requerimientos 1
Ingenieria de requerimientos 1jmpov441
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionalesAngel Minga
 
Requerimientos de usuario y del sistema
Requerimientos de usuario y del sistemaRequerimientos de usuario y del sistema
Requerimientos de usuario y del sistemaIsrael Rey
 

Más contenido relacionado

La actualidad más candente

25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de SoftwareCamila Arbelaez
 
MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMicky Jerzy
 
Modelado del análisis
Modelado del análisisModelado del análisis
Modelado del análisisJavier Rivera
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesCarlos Macallums
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clasesRamiro Estigarribia Canese
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 CapasFani Calle
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosCesar Prado
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftChuyito Alvarado
 
Pruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionPruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionAbner Gerardo
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional CristobalFicaV
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareEvelinBermeo
 
Tema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos
Tema N° 6 Técnicas para el Levantamiento y Recolección de RequisitosTema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos
Tema N° 6 Técnicas para el Levantamiento y Recolección de RequisitosSaraEAlcntaraR
 

La actualidad más candente (20)

25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWARE
 
Modelado del análisis
Modelado del análisisModelado del análisis
Modelado del análisis
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clases
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 Capas
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
 
Pruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionPruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacion
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Factores de calidad del software
Factores de calidad del softwareFactores de calidad del software
Factores de calidad del software
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
 
Rational rose
Rational roseRational rose
Rational rose
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
 
Ingeniería de software modelo incremental
Ingeniería de software  modelo incrementalIngeniería de software  modelo incremental
Ingeniería de software modelo incremental
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
Traductor y su estructura
Traductor y su estructuraTraductor y su estructura
Traductor y su estructura
 
Tema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos
Tema N° 6 Técnicas para el Levantamiento y Recolección de RequisitosTema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos
Tema N° 6 Técnicas para el Levantamiento y Recolección de Requisitos
 

Similar a Tareas de ingenieria de requerimientos

Tareas de la Ingenieria de Requisitos
Tareas de la Ingenieria de RequisitosTareas de la Ingenieria de Requisitos
Tareas de la Ingenieria de Requisitosjatovitos
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSJesus F Rosas
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosCarlos Chaves
 
Ingeniería de requisitos
Ingeniería de requisitos Ingeniería de requisitos
Ingeniería de requisitos CHICATEC
 
Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276marlev boadas
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de RequerimientosNaylu Rincón
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de RequerimientosNaylu Rincón
 
Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos unrated999
 
Ingeniería De Requisitos
Ingeniería De RequisitosIngeniería De Requisitos
Ingeniería De RequisitosssharLudena
 
Ingeniería De Requisitos
Ingeniería De RequisitosIngeniería De Requisitos
Ingeniería De RequisitosssharLudena
 
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezIngenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezkarolavergara
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
Disertacion corta
Disertacion cortaDisertacion corta
Disertacion cortaYesika72
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases3045433345
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSLuis Anibal
 

Similar a Tareas de ingenieria de requerimientos (20)

Ensayo ingenieria de requisitos
Ensayo ingenieria de requisitosEnsayo ingenieria de requisitos
Ensayo ingenieria de requisitos
 
Tareas de la Ingenieria de Requisitos
Tareas de la Ingenieria de RequisitosTareas de la Ingenieria de Requisitos
Tareas de la Ingenieria de Requisitos
 
Ingenieria de Requisitos
Ingenieria de RequisitosIngenieria de Requisitos
Ingenieria de Requisitos
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Ingeniería de requisitos
Ingeniería de requisitos Ingeniería de requisitos
Ingeniería de requisitos
 
Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de Requerimientos
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de Requerimientos
 
Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos
 
Ingeniería De Requisitos
Ingeniería De RequisitosIngeniería De Requisitos
Ingeniería De Requisitos
 
Ingeniería De Requisitos
Ingeniería De RequisitosIngeniería De Requisitos
Ingeniería De Requisitos
 
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diezIngenierýa requerimiento -_gustavo_rodrýguez_diez
Ingenierýa requerimiento -_gustavo_rodrýguez_diez
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Disertacion corta
Disertacion cortaDisertacion corta
Disertacion corta
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
 
Presentación1
Presentación1Presentación1
Presentación1
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 

Más de nenyta08

Actividad 1
Actividad 1Actividad 1
Actividad 1nenyta08
 
Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)nenyta08
 
Desarrollo suste
Desarrollo susteDesarrollo suste
Desarrollo sustenenyta08
 
Desarrollo suste
Desarrollo susteDesarrollo suste
Desarrollo sustenenyta08
 
Autobiografia
AutobiografiaAutobiografia
Autobiografianenyta08
 
Autobiografia
AutobiografiaAutobiografia
Autobiografianenyta08
 
Autobiografia
AutobiografiaAutobiografia
Autobiografianenyta08
 
Introducción(1)
Introducción(1)Introducción(1)
Introducción(1)nenyta08
 
Introducción(1)
Introducción(1)Introducción(1)
Introducción(1)nenyta08
 
Conclusión
ConclusiónConclusión
Conclusiónnenyta08
 
Conclusión
ConclusiónConclusión
Conclusiónnenyta08
 
Introducción
IntroducciónIntroducción
Introducciónnenyta08
 
Mi reflexión
Mi reflexiónMi reflexión
Mi reflexiónnenyta08
 
Mi reflexión
Mi reflexiónMi reflexión
Mi reflexiónnenyta08
 
Taxonomia de la herramientas case
Taxonomia de la herramientas caseTaxonomia de la herramientas case
Taxonomia de la herramientas casenenyta08
 
Investigacion historia
Investigacion historiaInvestigacion historia
Investigacion historianenyta08
 
Investigacion historia
Investigacion historiaInvestigacion historia
Investigacion historianenyta08
 

Más de nenyta08 (20)

Actividad 1
Actividad 1Actividad 1
Actividad 1
 
Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)
 
Desarrollo suste
Desarrollo susteDesarrollo suste
Desarrollo suste
 
Desarrollo suste
Desarrollo susteDesarrollo suste
Desarrollo suste
 
Autobiografia
AutobiografiaAutobiografia
Autobiografia
 
Autobiografia
AutobiografiaAutobiografia
Autobiografia
 
Autobiografia
AutobiografiaAutobiografia
Autobiografia
 
Introducción(1)
Introducción(1)Introducción(1)
Introducción(1)
 
Introducción(1)
Introducción(1)Introducción(1)
Introducción(1)
 
Conclusión
ConclusiónConclusión
Conclusión
 
Conclusión
ConclusiónConclusión
Conclusión
 
Introducción
IntroducciónIntroducción
Introducción
 
Mi reflexión
Mi reflexiónMi reflexión
Mi reflexión
 
Mi reflexión
Mi reflexiónMi reflexión
Mi reflexión
 
Taxonomia de la herramientas case
Taxonomia de la herramientas caseTaxonomia de la herramientas case
Taxonomia de la herramientas case
 
Investigacion historia
Investigacion historiaInvestigacion historia
Investigacion historia
 
Investigacion historia
Investigacion historiaInvestigacion historia
Investigacion historia
 
Glosario
GlosarioGlosario
Glosario
 
Glosario
GlosarioGlosario
Glosario
 
Glosario
GlosarioGlosario
Glosario
 

Tareas de ingenieria de requerimientos

  • 1. INSTITUTO TECNOLÓGICO DE NOMBRE DE LA UNIDAD: TUXTEPEC INGENERIA DE REQUISITOS FUNDAMENTO DE INGENERIA DE SOFTWARE ALUMNOS: MARIA DEL ROSARIO ANTONIO GOMEZ CLEOTILDE JORGE RAFAEL KEREN ARADI MARTINEZ HERRERA CRISTHIAN JOAQUIN CONTI SANCHEZ Tema ANTONIO VICIENTE MENDOZA Tareas de ingeniería de software 19/09/2012
  • 2. Introducción La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación, y administrar los requisitos conforme estos se transforman en un sistema operacional. Existen muchos procesos de desarrollo de software con una gran serie de estándares para medir.En el proceso de la ingeniería de requisitos se ejecutan las tareas de inicio, obtención, elaboración, negociación, especificación, validación y gestión. Dichas funciones deben adaptarse a las necesidades y particularidades de cada proyecto. En este caso se hablara de las tareas, actividades o funciones que debe efectuar para llegar a esta meta.
  • 3. TAREAS DE INGENERÍA DE SOTWARE INICIO Tienepor objetivo identificar el ámbito general del proyecto. Comienza con una serie de conversaciones informales entre los participantes del mismo (cliente, usuarios, grupo de desarrollo). Esta fase suele estar acompañada de los documentos de definición de la visión global y la visión de dominio del sistema. Según Carpers Jones dice “por lo general, las semillas de los desastres más importantes en software se siembra en los primeros tres meses desde el comienzo del proyecto” En algunos casos una conversación informal es todo lo que se necesita para precipitar un esfuerzo importante de ingeniería del software. Pero en general, la mayoría de los proyectos comienza cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. Los participantes de la comunidad de negocios(es decir, los gerentes, gentes de mercadotecnia, gentes de producto) definen un caso de negocios para la idea, tratan de identificar la amplitud y profundidad del mercado, hacen un análisis preliminar de factibilidad, e identifican una descripción funcional del ámbito del proyecto. Toda esta información está sujeta a cambios (una situación probable) pero es suficiente para suscitar conversaciones con la organización de ingeniería del software. Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres de contexto, el objetivo es establecer una comprensión básica del problema, las personas que quieren una solución, la naturaleza de la solución que se desea, y la efectividad de la comunicación preliminar entre el cliente y el desarrollador.
  • 4. OBTENCIÓN Sugiere a los ingenieros actividades de recopilación de requisitos de manera organizada.Parece muy simple preguntar al cliente, a los usuarios y otros interesados cuáles son los objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y por último como se utilizara el sistema o producto día a día. Pero no es simple, es muy difícil ya que se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos: Problema de ámbito: El límite del sistema está mal definido o los clientes/usuarios especifican detalles técnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema. Problemas de comprensión: Los clientes/usuarios no están seguros por completo de que es lo se necesita, comprenden poco acerca de las capacidades ylimitaciones de sus ambiente de computo, no comprende del todo dominio del problema, tienen dificultades al comunicar necesidades al ingeniero de sistema, omiten información que consideran “obvia”, especifican requisitos que chocan con las necesidades de otros clientes/usuarios, o especifican requisitos ambiguos o inestable. Problemas de volatilidad:Los problemas cambiara conformé transcurre el tiempo. Para ayudar a superar estos problemas, los ingenieros de requisitos deben realizar en forma organizada la actividad de recopilación de requisitos ELABORACIÓN Los ingenieros de software crean un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. El modelo de análisis define el dominio de la información, las funciones y el compartimiento del
  • 5. problema.La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad de la ingeniería de requisitos se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración del modelado del análisis y su componente de una serie de tareas de modelado y refinamiento. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describen la forma en que el usuario final(y otros actores) interactuaran con el sistema. Cada escenario del usuario se analiza para obtener clases del análisis: entidades del dominio de negocios visibles para el usuario final. Se definen los atributos de cada clase de análisis y se identifican los servicios que requiere cada clase. Se identifican las relaciones y la colaboración entre las clases y se produce una variedad de diagramas de UML complementarios. El resultado final de la elaboración es un modelo de análisis que definen el dominio de la información, las funciones y el comportamiento del problema. NEGOCIACIÓN Durante esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se priorizan, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Dados los recursos limitados del negocio, no resulta inusual que los clientes y usuarios pidan más de lo que se puede lograr. También es relativamente común que diferentes clientes o usuarios propongan requisitos que entran en conflicto entre sí al argumentar que su versión es “esencial para nuestra necesidades especiales”. El ingeniero de requisitos debe conciliar estos conflictos por medio de un proceso de negociación. Se pide a los clientes, usuarios y otros interesados que ordenen sus requisitos y después discutan los conflictos relacionados con la prioridad. Se
  • 6. identifican y analizan los riesgos asociados con cada requisito. Se hacen “estimaciones” preliminares del esfuerzo requerido para su desarrollo y después se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan, combinan o modifican de forma que cada parte alcance cierto grado de satisfacción. ESPECIFICACIÓN Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. La formalidad y especificación varían dependiendo de la complejidad del proyecto. En el contexto de los sistemas basados en computadora (y en software), el término especificación tiene significados diferentes para personas distintas. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos. Algunos sugieren que para una especificación se debe desarrollar y utilizar una “plantilla estándar”argumenta que esto conduce a que los requisitos sean presentados de una manera másconsciente y por ende más entendible. Sin embargo, algunas veces es necesario ser flexible mientras se desarrolla una especificación. Respecto de sistema grande el mejor enfoque podría ser un documento escrito que combinara descripciones en el lenguaje natural y modelos gráficos. Por otro lado, en cuanto a productos o sistemas más pequeños, podría ser que no se necesite más que escenarios de uso, cuando dichos sistemas residan en ambientes técnicos que se comprendan bien. La especificación es el producto de trabajo final que genera a ingeniería de requisitos. Sirve como base para las actividades de ingeniería de software subsecuentes.
  • 7. Describe la función yel desempeño de un sistema basado en computadora y las restricciones que regirán su desarrollo. VALIDACIÓN Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de los requisitos. La calidad de los productos de trabajo procedentes de la ingeniería de requisitos se evalúa durante un paso de validación. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y queestos han sido corregidos, y que los producto de trabajo cumplen con los estándares establecidos para el proceso, proyecto y producto. El mecanismo primario para la validación de requisitos es la revisión técnica formal. El equipo de revisión que valida los requisitos incluye ingenieros de software, clientes, usuarios y otros interesados que examinan la especificación y buscan errores en el contenido o la interpretación, áreas que tal vez requieran una clasificación, información faltante, inconsistencia (que es problema importante) cuando se desarrollan productos o sistemas grandes), conflictos entre los requisitos, o requisitos irreales (inalcanzables). GESTIÓN DE REQUISITOS Ayuda al equipo de proyecto a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas; de forma que pueda identificarse con rapidez para entender cómo afectará una modificación diferentes aspectos del sistema a construir. La gestión de requisitos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en
  • 8. cualquier momento mientras se desarrolla el proyecto.Muchas de estas actividades son idénticas a las actividades de la gestión de la configuración del software(GGS). La gestión de requisitos comienza con la identificación. Cada requerimiento se asigna a un solo identificador. Una vez identificados los requisitos se desarrollan las tablas de rastreabilidad que son las siguientes: Tabla de rastreabilidad de las características. Muestra la manera en que los requisitos se relacionan con las características del sistema/producto observables para el cliente. Tabla de rastreabilidad de la fuente. Identifica la fuente de cada requisito. Tabla de rastreabilidad de dependencia.Indica la forma en que los requisitos están relacionados entre sí. Tablas de rastreabilidad del subsistema. Establece categorías entre los requisitos de acuerdo con el (los) subsistema(s) que gobierna(n). Tablas de rastreabilidad de la interfaz. Muestra la forma en que los requisitos se relacionan con las interfaces internas y externas del sistema. En muchos casos, esas tablas de rastreabilidad se mantienen como parte de la base de datos de los requisitos de forma que pueda buscársele con rapidez para entender como el cambio en un requisito afectara diferentes aspectos del sistema que se construirá. Los requerimientos en un proyecto no solo comprenden las tareas de captura y manejo de los cambios a lo largo de todo el proyecto, también comprenden de estas otras tareas: 1. I d e n t i f i c a r l o s s t a k e h o l d e r s ( s e refiere a «quienes pueden afectar o son afectados por las actividades de una empresa»): Se describe una lista de toda la persona interesada en el desarrollo del sistema. 2. Entender las necesidades de los usuarios y clientes necesarias para planear el sistema y sus expectativas.
  • 9. 3. I d e n t i f i c a r l o s r e q u e r i m i e n t o s : Inicialmente los requerimientos provienen de los objetivos que plantea el negocio. En esta actividad los requerimientos se indican por medio de sentencias. En un escenario de negocio se usa para entender los requerimientos del negocio. 4. Aclarecer y refinar los requerimientos:Esta actividad se ejecuta cuando se tiene plena seguridad plena certeza de que los requerimientos indican las necesidades reales del cliente y que estos pueden ser usados por el resto de equipos en el proyecto. 5. A n a l i z a r l o s r e q u e r i m i e n t o s : Se realiza cuando los requerimientos se encuentran bien definidos y cumplen con el criteriode un buen requerimiento. 6. Definir los requerimientos de forma estándar para los stakeholders:Debido a que cada stakeholders tiene una perspectiva diferente del sistema y susrequerimientos, es importante esforzar un poco de tiempo en la descripción de losrequerimientos usando un vocabulario adecuado. 7. E s p e c i f i c a r los r e q u e r i m i e n t o s : Cada requerimiento debe expresarse en forma detallada de tal manera que pueda ser incluido en otros documentos de especificación o en otros proyectos. 8. P r i o r i z a r l o s r e q u e r i m i e n t o s : Todos los requerimientos tienen niveles diferentes de importancia para los clientes yusuarios. Unos tienen prioridad críticas, otros no tanta y otros de bajo nivel de prioridad.La priorización de los requerimientos es una actividad que nos va a permitir desarrollar nuevas versiones de nuestro proyecto de forma continua sin verse retrasadas por tiempo ensus salidas. 9. D e r i v a r l o s r e q u e r i m i e n t o s : Esta actividad nos permite detallar requerimientos no visibles para nuestros clientes ousuarios que no se han logrado identificar, pero que son importantes para el funcionamientoadecuado del requerimiento en detalle. 10. Particionarlos requerimientos:donde se clasifican los requerimientos en diferentes criterios: Hardware, software yentrenamiento.
  • 10. 11. Asignar los requerimientos:Esta actividad asigna los requerimientos a diferentes subsistemas y componentes internos. 12. Hacer seguimiento a los requerimientos:Se desarrolla la capacidad de permitir que un requerimiento satisfecho pueda ser referenciado dentro del sistema. 13. Manejar los requerimientos:Se desarrolla un sistema de control de los requerimientos, necesario para adicionar, modificar y borrar requerimientos, al igual que la implantación de un repositorio para estos. 14. Probar y verificar los requerimientos:En esta actividad se validan los requerimientos, diseños, código,etc... Para asegurarse quelos requerimientos están bien. 15. Validar los requerimientos:Finalmente se confirman los requerimientos reales que han sido implementados.
  • 11. Conclusión Es de mucha importancia tomarse el tiempo necesario para conocer a los clientes y usuarios, así como su ambiente de trabajo. Esto ayuda a establecer una buena relación de trabajo y comunicación entre el equipo de desarrollo y los clientes. Es realmente necesario que los clientes y usuarios participen en la definición de sus requerimientos, y con estos tareas, funciones o actividades que acabamos de ver, son necesario porque ponen una serie de estándares para medir y certificar la calidad tanto del sistema que está a desarrollar, como también del proceso de desarrollo que con lleva ya que esto son los que deciden el destino del proyectoy se decidedel gusto o inconformidady además del financiamientoque dará de fruto el proyecto.