desarrollo de software - ing de req i

Ingeniera de

Requerimientos

Parte I

Introduccin

La parte ms difcil de construir un sistema de software es

decidir precisamente qu construir. Ninguna otra parte del

trabajo conceptual es tan difcil como establecer los

requerimientos tcnicos detallados... Ninguna otra parte del

trabajo afecta tanto el sistema resultante si se hace

incorrectamente. Ninguna otra parte es tan difcil de

rectificar ms adelante

Fred Brooks - No Silver Bullet - Essence and Accidents of

Software Engineering. IEEE Computer, Abril de 1987.

Tesis: El problema es que...

El usuario no sabe lo

que quiere!

Ingeniera de Requerimientos:

Introduccin

Los de sistemas quieren que

les hagamos su trabajo!

Los usuarios no saben

lo que quieren!


Introduccin

Segn IEEE Standard Glossary of Software Engineering

Terminology (1990), un requerimiento se define como:

Una condicin o capacidad requerida por un usuario para

resolver un problema o lograr un objetivo.

Una condicin o capacidad que debe ser alcanzada o

desarrollada por un sistema o componente de sistema para

satisfacer un contrato, standard, especificacin u otro

documento formal impuesto.

Una representacin documentada de una condicin o capacidad

como en los puntos anteriores.


Introduccin

El desarrollo y gestin de los

requerimientos es una de las actividades

ms importantes en el desarrollo de un

proyecto porque:

Establece el objetivo del proyecto.

Define y mantiene el alcance del proyecto.

Exige una conversin sobre un objetivo comn de la

aplicacin.

Influye en los costos.


Introduccin

Y, sin embargo, la ingeniera de requerimientos

es un rea an no explorada a cabalidad. Esto,

porque:

Los requerimientos nacen a partir de necesidades.

Tienen un fuerte componente humano.

La variedad de escenarios en que debe aplicarse es

amplia.


Introduccin

Es por esto de la

importancia de

clasificar los

requerimientos en

tipos.

Las distintas

clasificaciones

prestan diferentes

utilidades al

proceso de toma

de requerimientos

FUNCIONAL NO-FUNCIONAL

Requerimiento

de Negocio

Doc. de Visin y Alcance

Requerimiento

de Usuario

Doc. De Casos de Uso

Requerimiento

Funcional

Reglas de

Negocio

Atributos de

Calidad

Interfaces

Externas

restricciones

Esp. De Requerimientos

Requerimiento

de Sistema


Introduccin

Por ejemplo: supongamos un sistema de

compra y venta de repuestos de automviles

Requerimientos de Negocio:

Agilizar el proceso de adquisiciones

Fortalecer la relacin con los concesionarios y clientes.

Disminuir costos.

Requerimientos de Usuario:

Comprar repuestos

Actualizar stock

Requerimientos Funcionales:

Crear un pedido

Consultor un articulo


Introduccin

A su vez, estos requerimientos pueden verse

afectados por aspectos no funcionales, por

ejemplo:

Reglas de Negocio:

Tipos de pedidos estn supeditados al tipo de mayorista.

Atributos de calidad:

De respuesta rpida y amigable.

Interfaces externas:

Con sistema contable y financiero.

Restricciones:

Legislatura para otorgar crditos.

Descarga de precios 2 veces por semana como mximo


Introduccin

Es importante destacar la diferencia entre

desarrollo de requerimientos y su gestin.

Esta diferencia resulta de suma importancia

para una buena gestin de los proyectos


Introduccin

Las gestin de los requerimientos est ms

enfocada a establecer y mantener acuerdos con

el cliente acerca del alcance de los

requerimientos de software del proyecto. Para

esto, se ejecutan actividades de:

Establecer el estado actual de los requerimientos

Ejecutar controles de cambios sobres estos

Mantener planes en concordancia con los

requerimientos existentes

Seguir los cambios a los requerimientos


Introduccin

El desarrollo de requerimientos, sin embargo,

est ms orientado a su elaboracin . Para esto,

se ejecutan actividades como:

Levantamiento

Anlisis

Especificacin

Validacin


Introduccin

En este ltimo punto, una buena especificacin

de requerimientos puede ser de gran utilidad en

evitar futuros problemas durante el proyecto.

Un requerimientos debiera ser:

Completo

Correcto

Viable

Necesario

Priorizado

No ambiguo

Verificable


Introduccin

Ejemplo:

Existir una interfaz amigable que permitir la descarga masiva de artculos y sus datos relevantes, incluyendo precios

La palabra amigable implica un deseo del usuario que no es posible medir ni verificar

La frases datos relevantes y descarga masiva se pueden prestar para distintas interpretaciones, es ambiguo

Re fraseando el requerimiento:

Existir una interfaz que permitir la descarga de un mximo de 100

artculos y sus datos de: cdigo, proveedor, descripcin, y precio hasta

el servidor central. La interfaz ser Windows-compatible y mostrar

fecha de transaccin, nombre del archivo y lugar de almacenamiento


Introduccin

Sin embargo, la toma de requerimientos no es

una tarea fcil y debiera estar siempre

acompaada de alguna tcnica adecuada.

En este sentido, es conveniente conocer

distintos tipos de modelos

Si la nica herramienta que uno conoce es un

martillo, todo le parecer un clavo


Introduccin

Para esto es muy importante entender de que

se trata cada una de las ms importantes

actividades que involucra el desarrollo de los

requerimientos

Levantamiento Anlisis Especificacin Validacin

clarificar

Re-evaluar

Re-escribir

Corregir y cerrar ambivalencias


Introduccin

Adems de conocer los

modelos y herramientas,

el rol del analista requiere

de ciertas habilidades

soft necesarias para levantar y documentar

requerimientos

Sponsor

Usuarios

Otros stakeholders

Testeadores

Desarrolladores

Jefe de proyecto


Levantamiento

La extraccin de requerimientos consiste en obtener de

los usuarios lo que ellos saben y nosotros no

Es un proceso de captura

todo lo que se obtiene se registra

Es un proceso de comunicacin

e interaccin

La informacin suele ser contradictoria

Importante: observarlos en

su hbitat natural


Levantamiento

Esta etapa se enfoca a la preparacin y levantamiento de las necesidades de los usuarios y grupos interesados en el sistema a construir.

Su objetivo es establecer el ambiente operacional en el que el sistema ejecutar. Para esto, considera actividades tales como:

Establecer las actividades del proceso del desarrollo de requerimientos.

Identificar grupos de usuarios y usuarios claves

Definir visin y alcances del sistema

Facilitar mecanismos de recoleccin de requerimientos


Levantamiento

Las principales actividades durante el desarrollo

de un requerimiento deben ser organizadas

dentro del proyecto, en otras palabras, se debe

indicar que ciclo de vida estas seguirn.

Existen distintos tipos de ciclos de vida de un

proyectos, a saber:

Cascada

Iterativo

Espiral

otros


Levantamiento

Uno de los primeras acciones que debe ejecutarse durante un proyecto es establecer sus alcances, para esto, se establece lo que comnmente se conoce como Documento de visin y alcance.

Es muy importante definir la visin del proyecto desde el principio, con esto, se evitan conflictos de inters en etapas posteriores.

El alcance del proyecto est supeditado a la visin de ste y permite determinar cundo un requerimientos se encuentra dentro o fuera de alcance.


Levantamiento

La visin del proyecto facilita la toma de

decisiones a travs del proyecto.

La siguiente plantilla permite establecer una buena

definicin de visin, los pasos son los siguientes:

Para: cliente/usuario objetivo

Quin: describir la necesidad u oportunidad que el sistema

logra

El: indique el nombre de la aplicacin

De tipo: indique la categora de la aplicacin

Que: identifique sus beneficios

A diferencia: compare que hace esta aplicacin con lo ya

existente

Nuestro producto: indique las ventajas de la aplicacin


Levantamiento

Ejemplo de Visin:

Para el personal de administracin, ventas y

concesionarios Quienes requieren un rpido y expedito

acceso a la adquisicin y compra de repuestos

automotrices se ha definido El Sistema de Compra en Lnea , una aplicacin De tipo en lnea y transaccional, Que permitir la reserva y compra de repuestos para

automviles en el extranjero publicndolos en el sistema

y permitiendo a clientes y distribuidores autorizados a

acceder a ellos. A diferencia del sistema anterior,

Nuestro sistema incluye nuevas facilidades de acceso

y reservas en lnea que permitir una mejor atencin a

usuario final


Levantamiento Al igual que cuando adquirimos un nuevo equipo mvil

(celular), se debe establecer en forma clara y concisa que har y que no har el sistema. A esto se denomina: Alcance y Limitaciones del Sistema.

Al definir los alcances y limitaciones del sistema, se establecen expectativas ms realistas para los usuarios e interesados de la aplicacin

Recuerde siempre mantener el alcance del sistema dentro de foco. Cualquier nuevo o cambio a requerimiento debe ser cuidadosamente evaluado.


Levantamiento

Ciertamente, lo ms difcil de levantar requerimientos no

es documentarlos sino recopilarlos. En este sentido,

una buena estrategia de clasificacin de fuentes de

requerimientos y mtodos se hace imprescindible.

Una tcnica muy conocida es establecer clases de

usuarios. En ella, los diferentes grupos usuarios y no

usuarios son clasificados en grupos con un mismo

inters o necesidad sobre el sistema.


LevantamientoGrupos de

usuarios

Caractersticas

Personal de Ventas Consta aproximadamente de 5 personas,

todas ubicadas en el mismo edificio. El

sistema lo utilizarn para mantener los

libros contables. Para esto, necesitan tener

la informacin en lnea de cuntos

repuestos han sido vendidos a la fecha,

cuntos devueltos y cuntos facturados.

Personal de bodega Son dos personas, ubicadas en la bodega

central. El sistema lo utilizarn

principalmente para comparar entre el

espacio disponible y el requerido. Para esto

utilizarn el sistema en modo consulta.


Levantamiento

Adems de clasificar usuarios en grupos, es

importante distinguir aquellos que conocen el negocio y disfrutan del apoyo del resto. Este tipo de fuente de requerimientos es lo que

denominamos: usuario experto

Los usuarios expertos son de gran ayuda

porque:

Ayudan a evitar mltiples interpretaciones.

Conocen lo desconocido

Disminuyen la resistencia al cambio


Levantamiento

Otro importante rol a establecer al comienzo y a

travs de todo el proyecto es el usuario lder o quin toma la ltima decisin.

Una situacin tpica en donde la presencia de

un usuario lder es primordial es:

Requerimientos expresados por ejecutivos que estn

en conflicto con aquellos expresados por usuarios

finales


Levantamiento

El levantamiento de requerimientos es,

sin duda, la ms crtica, importante, social

y propensa a errores de todas las

actividades durante el desarrollo de

software

Karl E. Wiegers: Software Requirements


Levantamiento

De acuerdo a Savant Institute, el 56% de los

errores en software ocurren debido a que los

analistas no se comunican en forma adecuada

con sus clientes.

La correccin de este tipo de errores toma

aproximadamente un 82% del tiempo de los

desarrolladores en ser corregida


Levantamiento

Algunas tcnicas utilizadas para el

levantamiento de requerimientos son:

JAD (Joint Application Design (JAD) desarrollado por

IBM en los 70s

Es de tipo Workshop

Potencia el trabajo en equipo- todos los involucrados

participan

Intensas sesiones que duran de 3-5 das.

Agendas de trabajo altamente estructuradas

Ibis (Issue Based information System)

Basado en seguimiento de problemas y puntos de vistas

Permite guardar conocimiento


Levantamiento

Entrevistas

Estructuradas

Contemplan un set pre-definido de preguntas.

Evitan filtraciones u olvidos de puntos importantes

No estructuradas

espontneas

Permiten ms libertad de accin


Levantamiento

Para entender los requerimientos de usuario, una de las

tcnicas ms conocidas es : Casos de Uso.

Los casos de uso fijan la perspectiva del analista desde

del punto de vista de qu el usuario espera logra usando

el sistema en vez de preguntar al usuario que espera

que el sistema haga.

El objetivo de los casos de uso es describir todas las

tareas que debe ejecutar usando el sistema


Levantamiento Los casos de uso pueden ser representados de varias

maneras. La ms conocida y tradicional es aquella provista en notacin UML

Hereda

Empleado

Ventas

Supervisor

Ventas

Ingresando Pedido

Autorizando Pedido

Recibiendo Informe

VentasGerente

Sistema de Ventas


Levantamiento

En los casos de uso de distinguen tres

importantes componentes:

Actores

Principales

Secundarios

Escenarios

Excepciones


Levantamiento

Los actores principales representan a los stakeholder

que interactan directamente con el sistema.

Existen tambin los actores de soporte que son aquellos

que prestan servicios o proveen algn tipo de soporte

y/o informacin al sistema.

Los actores son muy importantes de identificar

claramente pues ellos darn definirn los casos de uso

del sistema y su alcance


Levantamiento

Los escenarios describen situaciones que pueden

presentarse en distintas etapas de la ejecucin de una

tarea.

Los casos de uso estn compuestos de escenarios y

viceversa.

Durante el desarrollo de un caso de uso, se describe el

escenario principal y a partir de ste los secundarios


Levantamiento

Las excepciones son bifurcaciones del escenario

principal. En otras palabras, describen los ..y que tal si de situaciones no esperadas.

Las excepciones nos ayudan a capturar requerimientos

desconocidos al revelar situaciones que ni los mismos usuarios se haban planteado.

Al buscar excepciones, considere todo, incluso lo

impensable.


Levantamiento

Estructura tpica para describir un caso de uso:

Caso de Uso:

Actores:

Pre condicin:

Post condicin:

Escenario Principal

1 accin

2 accin

3 accin

Excepciones

1.1 accin

1.2 accin


Levantamiento

Empricamente se sabe que un caso de uso con ms de 8 acciones est mal enfocado.

Describa casos de uso como quin describe un partido de ftbol.

Las acciones deben mostrar que espera lograr el usuario y cmo ejecutar.

Las validaciones dentro del caso de uso deben hacerse en pro de resguardar los intereses de los stakeholder de ste.


Ejercicio prctico

desarrollo de software - ing de req i

Documents