PlanificaciÓn y Modelado Procesos de La Ingeniería

UNIDAD I

PLANIFICACIÓN Y MODELADO

Procesos de la Ingeniería de Requerimientos

3% 2%

47%

29%

19%

ENTREGADO PERO NUNCA USADO

SATISFACTORIAMENTE

PAGADO PERO NO

ENTREGADO

USADO TAL COMO SE ENTREGÓ

USADO DESPUÉS

DE CAMBIOS

USADO PERO AMPLIAMENTE

REELABORADO O ABANDONADO

DESPUÉS

GAO 1979

53%

31.10%

16.20%

TERMINADO Y OPERATIVO, PERO FUERA DE PLAZO,

FUERA DE PRESUPUESTO Y SIN SATISFACER TODOS

LOS REQUISITOS

TERMINADO DENTRO DE

PLAZO Y PRESUPUESTO CUMPLIENDO TODOS LOS REQUISITOS

CANCELADO DURANTE EL DESARROLLO

GRUPO STANDISH

M.C. Miriam Zulma Sánchez Hernández

FACTORES DE ÉXITO Y DE FRACASO

Implicación de los Usuarios

Apoyo de los directivos Enunciado claro de los

requisitos

Falta de información por parte de los usuarios

Especificaciones y requisitos incompletos

Especificaciones y requisitos cambiantes


“La parte más difícil de construir de un sistema de software es precisamente saber QUÉ construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna otra parte es más difícil de rectificar después”

Brooks 1995, pág.199


¿REQUISITO? : Definición

Según la IEEE Una condición o capacidad que un usuario

necesita para resolver un problema o lograr un objetivo

Una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificación u otro documento formal.


¿Qué son los requerimientos?

Los requerimientos son la pieza fundamental en un proyecto de desarrollo de software, en ellos se basan muchos participantes del proyecto para: Planear el proyecto y los recursos que se usarán

en él. Especificar el tipo de verificaciones que se

habrán de realizar al sistema. Planear la estrategia de prueba a la que habrá

de ser sometido el sistema. Son el fundamento del ciclo de vida del

proyecto.


¿QUÉ ES LA INGENIERÍA DE REQUERIMIENTOS?

SEGÚN ORTAS 1997:

La Ingeniería de Requerimientos es un conjunto de actividades en las cuáles, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución.


De acuerdo con Bohem, Es la disciplina para desarrollar una especificación

completa, consistente y no ambigüa, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema.

Según Rational Software Corporation La IR es un enfoque sistémico para recolectar,

organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto.


Desde otro enfoque… [Duran 2000]

Es un proceso de descubrimiento y comunicación de las necesidades de clientes y usuarios y la gestión de los cambios de dichas necesidades.


Especificación de Requerimientos (ERS)

Una especificación de Requerimientos de Software es un documento que contiene una descripción completa de qué hará el software sin describir cómo lo hará.


¿Porqué son importantes los Requerimientos?

¿Porqué perder mi tiempo preocupándome por los requerimientos?

¿Porqué no ahorro ese dinero eliminando esa etapa innecesaria?

“Si no se tienen los requerimientos correctos, no se puede diseñar o construir el producto correcto…”

COMPROBEMÓSLO!!COMPROBEMÓSLO!!


¿Porqué son importantes los Requerimientos?

HIPÓTESIS 1. Entre más tarde detecte un error en el ciclo de vida del desarrollo de software, más caro costará repararlo.

HIPÓTESIS 2. Muchos errores permanecen latentes y no son detectados hasta después de que la etapa ha sido terminada.

HIPÓTESIS 3. Los errores hechos en la especificación de requerimientos son típicamente hechos incorrectos, omisiones, inconsistencias y ambigüedades.

HIPÓTESIS 4. Los errores de requerimientos pueden ser detectados

Hipótesis 1

Entre más tarde detecte un error en el ciclo de vida del desarrollo de software, más caro costará repararlo.

ETAPA COSTO RELATIVODE REPARACIÓN

Requerimientos 0.1-0.2

Diseño 0.5

Codificación 1

Prueba 2

Pruebas de acept. 5

Mantenimiento 20

HIPÓTESIS 1

Hipótesis 2

Muchos errores permanecen latentes y no son detectados hasta después de que la etapa ha sido terminada

HIPÓTESIS 2

Implementación

EL PROBLEMAREAL

Diseñocorrecto

Programascorrectos

Funcionescorrectas

Especificacióncorrecta

Especificaciónerrónea

Diseño erróneo

Diseño basado enEspecific. errónea

Errores deProgramación

Programas basados en diseño

erróneo

Programas basadosen especific. errónea

Errores corregibles

Erroresincorregibles

ErroresOcultos

Especificación deRequerimientos

Diseño

Pruebas

P R O G R A M A I M P E R F E C T O

Hipótesis 3

Los errores hechos en la especificación de requerimientos son típicamente hechos incorrectos, omisiones, inconsistencias y ambigüedades


0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

Tipos de Errores de Requerimientos confusos

HIPÓTESIS 3

Hipótesis 4

Los errores de requerimientos pueden ser detectados

¿Podemos encontrar los errores?6

5%

10

%

5%

10

%1

0%

0% 10% 20% 30% 40% 50% 60% 70%

Inspección

Pruebas

Integración

Evaluación

Otra

% de errores

HIPÓTESIS 4


CONCLUSIONES

Se cometen muchos errores de requerimientos al hacerlos

Muchos de estos errores no son detectados a tiempo

Muchos de estos errores pueden ser detectados a tiempo

No detectar estos errores puede contribuir a elevar los costos del software


PROCESO DE LA INGENIERÍA DE REQUERIMIENTOS


¿Para qué un Proceso de Ingeniería de Requerimientos?

El proceso de Ingeniería de Requerimientos es un conjunto estructurado de actividades, mediante las cuáles obtenemos, validamos y mantenemos el documento de especificación de requerimientos (ERS).


Participación del usuario

Estudio defactibilidad

Obtención yanálisis

Especificación Validación

Requerimientosdel usuario

Retroalimentacióndel usuario

Especificaciónde requerimientos

Modelos a validarpor el usuario

Modelo derequerimientosConocimiento

Necesidad de másconocimiento

Resultado devalidación

Proceso de la Ingeniería de Requerimientos


ESTUDIO DE FACTIBILIDAD Para todos los sistemas nuevos, el proceso de

la Ingeniería de Requerimientos empieza con el estudio de Factibilidad.

La entrada de este es una descripción resumida del sistema y de cómo se utilizará dentro de la organización. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la Ingeniería de Requerimientos y el proceso del desarrollo del sistema.

ORGANIZACIÓN¿SIRVE?

SISIINGENIERIA INGENIERIA

DEDEREQUERIMIENTOSREQUERIMIENTOS

NONO


ESTUDIO DE FACTIBILIDAD

Un estudio de factibilidad es un estudio corto y orientado a resolver varias preguntas. ¿El sistema contribuye a los objetivos

generales del sistema? ¿El sistema se puede implementar utilizando la

tecnología actual y con las restricciones de costo y tiempo?

¿El sistema puede integrarse a otros que existen en la organización?


OBTENCIÓN Y ANÁLISIS DE REQUERIMIENTOS

Es el proceso que sirve para determinar el dominio de la aplicación, cuales servicios debe proporcionar el sistema, así como su desempeño requerido, las restricciones de hardware, etc. Se trabaja estrechamente con los usuarios a fin de conocer la problemática en detalle.

Las actividades que cubre son: Comprensión del dominio Recolección de requerimientos Clasificación de requerimientos Resolución de conflictos Priorización Verificación de requerimientos


Verificación deRequerimientos

Comprensióndel dominio

Recolección de Requerimientos

Priorización

Resolución de conflictos

Clasificación

Especificación deRequerimientos

DOCUMENTO DEREQUERIMIENTOS

PROCESO DE OBTENCIONY ANÁLISIS DE

REQUERIMIENTOS


HERRAMIENTAS DE EXTRACCIÓN Y ANÁLISIS

Herramientas para recolección de datos Capturan detalles que describen sistemas y

procedimientos en uso. Documentan procesos y actividades de decisión.

Herramientas para Diagramación Crean representaciones gráficas de sistemas y

actividades. Apoyan el dibujo y revisión de DFD e íconos asociados con el análisis estructurado.

Herramientas para el Diccionario Registran y mantienen descripciones de los

elementos del sistema, tales como grupos de datos, procesos y almacenamiento de datos.

Herramientas automatizadas Prototipos

Hay de enfoque cerrado (desechable) y enfoque abierto (evolutivo)


HERRAMIENTAS DE EXTRACCIÓN Y ANÁLISIS

Herramienta Extracción Análisis Especificación Validación

Entrevistas y Cuestionario X

Sistemas existentes X X

Grabaciones video/audio X X

Brainstorming X X

Arqueología de doctos. X X

Aprendiz X

Observación X

Prototipos X X

FODA X

Diagrama de pescado X X X

Glosario X X X X

Casos de uso X X X X

Casa de Calidad QFD X

Checklist X X

Diagramas FD X X

Modelos de clases X X

Diagramas de estado (transición, actividades, redes de petri)

X X


ENTREVISTAS Y CUESTIONARIOS

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o grupos, información que se obtiene conversando con el encuestado.

Para realizar las entrevistas, conviene llevar preparado un cuestionario. Un cuestionario consiste en un conjunto de preguntas presentadas a una persona para su respuesta. La forma de la pregunta influye en las respuestas, por lo que hay que planearlas cuidadosamente.

Las preguntas se dividen en dos categorías: Abiertas y Cerradas.


SISTEMAS EXISTENTES

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido.

Por un lado, se pueden analizar las interfases de usuario, observando el tipo de información que se maneja y cómo es manejada. Esto puede ser útil para descubrir información importante, que tal vez el cliente/usuario haya fallado en comunicar.

También es útil analizar las distintas salidas que los sistemas producen (listados, consultas, etc), porque siempre pueden surgir nuevas ideas sobre la base de éstas.


GRABACIONES DE VIDEO Y AUDIO

Básicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algún proceso en particular.

Como apoyo, permite centrar la atención en la entrevista en vez de distraerse tomando notas de todo lo que se dice. Permite analizar los temas con más detenimiento y con una visión más global.

Como análisis de Procesos, permite ver y analizar el proceso la cantidad de veces que sea necesario, además de que al filmar el lugar de trabajo estamos capturando el proceso de trabajo, lo que evita que impongamos nuestras expectativas y preferencias.


BRAINSTORMING (Tormenta de ideas)

Este es un método que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema.

No se debe detener a pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primer instancia, muchas ideas. Luego se irán eliminando en base a distintos criterios como, por ejemplo, “caro”, “impracticable”, “imposible”, etc.


ARQUEOLOGÍA DE DOCUMENTOS

Con la aplicación de esta herramienta se tratan de determinar posibles requerimientos sobre la base de inspeccionar la documentación utilizada por la empresa; por ejemplo, boletas, facturas, remisiones, etc.

Sirve como complemento de las demás técnicas y ayuda a obtener información que de otra manera sería muy difícil de conseguir. ¿Cuál es el propósito de este documento? ¿Quién lo usa? ¿Por qué? ¿Para qué? ¿Cuáles son las tareas que realizan con este

documento?


APRENDIZ

Se basa en la idea del maestro y el aprendiz. El aprendiz es representado por el analista y el usuario/cliente cumple con el rol de maestro.

El aprendiz se sienta con el maestro a aprender por medio de la observación, haciendo preguntas como ¿por qué hizo eso? y ¿Qué significa eso?, y también realizando algún trabajo bajo la supervisión del maestro.

La aplicación de esta herramienta es muy útil, ya que a veces es difícil para el cliente/usuario el explicar cómo realiza su trabajo.


OBSERVACIÓN

Es sumamente difícil describir cómo hacer el nudo de un calzado deportivo, pero es sumamente fácil mostrar los pasos para hacerlo.

Observar como se hacen las cosas es una buena manera de entender lo que estas requieren.

Dentro de la estrategia de observar, se tienen que buscar estructuras y patrones. La estructura del trabajo para los usuarios suele ser invisible, por lo que será nuestro trabajo realizar las abstracciones necesarias.


ESPECIFICACIÓN Y DOCUMENTACIÓN DE LOS REQUERIMIENTOS

Esta actividad se enfoca al proceso de documentación del comportamiento deseado del sistema. La especificación de requerimientos es un acuerdo aprobado entre usuarios y desarrolladores del software y debe tener al menos las siguientes características: Contener todos los requerimientos deseados Cada requerimiento solo tiene una interpretación

posible El cumplimiento de cualquier requerimiento no debe

provocar conflictos con el cumplimiento de otro requerimiento, es decir, que sea consistente.

Prioridades definidas


Cómo expresar los Requerimientos de Sistemas

Los requerimientos deben de ser:

Especificados por escrito Posibles de probar o verificar Descritos como una característica del

sistema a entregar. Lo más abstracto y conciso posible.


Como expresar los requerimientos para una buena precisión y entendimiento

Entendimiento

Precisión

Lenguaje natural

Lenguaje estructurado

Metodologías (CASE,etc.)

EspecificacionesFormales


DOCUMENTACIÓN DE REQUERIMIENTOS DE SOFTWARE

Los requerimientos deben escribirse de modo que sean significativos no sólo para los clientes, sino también para los diseñadores que integran el equipo de desarrollo.

Definición de Requerimientos

Especificación de Requerimientos

Clases de documentosde Requerimientos


DOCUMENTO: DEFINICIÓN DE REQUERIMIENTOS

Está escrita en términos que el cliente puede entender. Es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Es escrito en forma conjunta por el cliente y el desarrollador.

1. Primero se perfila el propósito general del sistema.

2. Se describen los antecedentes y los objetivos del desarrollo del sistema.


DOCUMENTO: DEFINICIÓN DE REQUERIMIENTOS

3. Si el cliente tiene un nuevo enfoque propuesto para resolver el problema, se perfila una descripción del enfoque.

4. Una vez registrada esta vista global del problema, se describen en detalle las características del sistema propuesto. Se definen el límite del sistema y las interfaces que lo vinculan con el entorno.

5. Por último, se discute el ambiente en el cuál operará el sistema. Se incluyen requerimientos para el soporte, la seguridad y la privacidad.


DOCUMENTO: ESPECIFICACIÓN DE REQUERIMIENTOS

Se escribe desde la perspectiva del desarrollador. Reitera la definición de los términos técnicos apropiados para el desarrollo del diseño de un sistema; es la contrapartida técnica al documento de definición de requerimientos, y es escrito por analistas de requerimientos.

Por ejemplo, el cliente no puede comprender la definición de un requerimiento en términos de una relación matemática compleja definida con una serie de ecuaciones.


VALIDACIÓN DE LOS REQUERIMIENTOS

Esta actividad tiene mucho en común con el análisis, ya que implica encontrar problemas con los requerimientos. Sin embargo, son procesos distintos puesto que la validación comprende un bosquejo completo del documento de requerimientos, mientras que el análisis implica trabajar con los requerimientos incompletos. Durante esta actividad se deben llevar a cabo diferentes tipos de verificación en el documento de requerimientos que incluyen verificaciones de: Validez Consistencia Integridad Realismo Verificabilidad


EJERCICIOS

De acuerdo a los criterios que debe cumplir la especificación de requisitos de un sistema, comentar los siguientes: “Todos los clientes tienen el mismo

identificador” “Identificador de los clientes. A

determinar” “El sistema tendrá una interfaz amistosa” “Se asocia la factura con el documento

de pago y se cambia su estado”


EJERCICIOS

Representar una entrevista entre el dueño de un videoclub y un analista, teniendo en cuenta que en este caso el usuario desconoce por completo la informática. Prestar atención al modo en que se extrae información sobre el funcionamiento del videoclub, así como de las expresiones y posturas adoptadas por cada uno de los “actores”.

Elaborar un cuestionario para el análisis de requisitos de una red de concesionarios de venta de automóviles. Téngase en cuenta los volúmenes de los datos, y las operaciones, características de seguridad, estándares, etc.


1.1. REQUERIMIENTOS DE PROCESO1.2. REQUERIMIENTOS DE LOS USUARIOS1.3. REQUERIMIENTOS PARA EL ANÁLISIS Y NEGOCIACIÓN1.4. REQUERIMIENTOS PARA LA GESTIÓN


1.1. REQUERIMIENTOS DE PROCESO

Los requerimientos del proceso son a nivel organizacional, describen el “cómo”, es decir, describen los procedimientos y políticas que las organizaciones deben seguir así como las restricciones que deben obedecer, por ejemplo, estándares usados en los procesos, los requerimientos de implementación, etc.

Los requerimientos de proceso se imponen a menudo como la manera de alcanzar un cierto requerimiento de alto nivel del producto. Por ejemplo, un requerimiento del costo máximo del desarrollo (requerimiento de proceso) se puede imponer para ayudar a alcanzar un requerimiento del precio máximo de venta (requerimiento del producto).


1.2. REQUERIMIENTOS DE LOS USUARIOS

Los requerimientos de los usuarios son todas sus necesidades, las cuales se traducen a los requerimientos de lo que esperan que un nuevo sistema realice y de las restricciones que lleva consigo. Un ejemplo de tales necesidades pueden ser las siguientes: Obtener soluciones a problemas en su trabajo bajo

el sistema actual

Una interfaz más amigable, rápida de aprender, fácil de usar

Un tiempo de respuesta más corto, etc.


Requerimientos de usuarios…

Requerimientos de usuario Requerimientos del sistema

LENGUAJE COTIDIANO LENGUAJE TÉCNICO


Los usuarios…

Cuando se están investigando los requerimientos, el analista se encuentra con el problema de la comunicación con el usuario pues el lenguaje cotidiano de ambos no es igual. Por ejemplo:

Falta de claridad Conocen de manera muy general lo que desean obtener No saben expresar o explicar lo que quieren del sistema Usan terminologías distintas Confunde los requerimientos funcionales y los no

funcionales Confusión de requerimientos, pues expresan de varias

formas un mismo requerimiento

???


PARTICIPANTES EN EL PROCESO DE SOFTWARE (stakeholders)

Los supervisores del contrato

Los clientes y los usuarios

Los gerentes del negocio

Los diseñadores

Los verificadores


1.3. REQUERIMIENTOS PARA EL ANÁLISIS Y LA NEGOCIACIÓN

Una vez identificados los requerimientos completos, consistentes y no ambiguos, se procede a clasificarlo. El analista debe hacerse la siguiente pregunta con cada uno de los requerimientos: ¿El requerimiento es necesario o representa una característica añadida que puede no ser esencial cuando se haya finalizado el sistema? La razón de esta pregunta se debe a que es común en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados, cómo sería el sobrepasar el presupuesto y el tiempo requerido para el desarrollo del sistema.

La clasificación de estos requerimientos es la siguiente: requerimientos esenciales, aquellos que deben ser

absolutamente satisfechos. requerimientos deseables, que son importantes pero no

indispensables. requerimientos opcionales, que son posibles pero que podrían

eliminarse


Proceso de Negociación

Después de hacerse la clasificación de requerimientos, el analista de sistemas realiza un proceso de negociación con clientes, usuarios y el resto de los involucrados para resolver los conflictos relacionados con ciertos requerimientos según su prioridad. Parte de la negociación de los requerimientos incluye identificar y analizar los riegos asociados a cada requerimiento además de efectuar estimaciones de costo, tiempo y esfuerzo. Estas estimaciones ayudarán a una mejor elección de cuáles requerimientos tienen mayor prioridad que otros.


1.3. REQUERIMIENTOS PARA EL ANÁLISIS Y LA NEGOCIACIÓN

En esta actividad se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:

Documentar todos los requerimientos a un nivel de detalle apropiado.

Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a requerimientos antes

de aceptarlos. Establecer las relaciones entre requerimientos que indiquen

dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones


1.4. REQUERIMIENTOS PARA LA GESTIÓN

La gestión de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema y se lleva a cabo junto con el proceso de ingeniería de requerimientos. La planeación comienza al mismo tiempo que la obtención inicial de requerimientos y la administración activa debe iniciar tan pronto esté lista la primera versión del documento de requerimientos.

[Checar documento para ampliar la información]

Documents

PlanificaciÓn y Modelado Procesos de La Ingeniería