documento completo sando

7/31/2019 Documento Completo Sando

1/5

Validacin de Requerimientos a travs de Modelos

Conceptuales

Marcelo Marciszack, Marina Cardenas, Claudia Castro, Ramiro Perez

Dpto. Ingeniera en Sist. de Informacin/ Facultad Regional Crdoba/ Universidad Tecnolgica Nacional

{ marciszack, ing.marinacardenas, ingclaudiacastro, ramipez }@gmail.com

Resumen

El trabajo presentado en este articulo tienecomo objetivo implementar unaherramienta que permita gestionar y validarrequerimientos de software, que ayudar adefinir los lmites del sistema al momento

de formular los requerimientos, controlar yoptimizar los procesos, y proveer al grupode desarrollo una base para la estimacindel tiempo y costo del desarrollo desistemas de software, permitiendo asconocer el estado del proyecto y el impactode los cambios en caso de ser requeridos.

Palabras clave: validacin, requerimientos,modelos, conceptual, especificacin, trazabilidad,

software.

Contexto

El presente proyecto se encuentraconsolidado dentro de la lnea deinvestigacin de Sistemas de Informacinen el Dpto. de Ingeniera en Sistemas deInformacin de la Universidad Tecnolgica

Nacional, Facultad Regional Crdoba.El mismo busca dar solucin a uno de los

principales problemas de la ingeniera ensistemas relacionado a la elicitacin y

especificacin de requerimientos, quevincula las distintas etapas del proceso dedesarrollo de software manteniendo latrazabilidad de estos requerimientos hasta lavalidacin e implementacin de losmismos.

Objetivos Generales

Los objetivos Generales del proyecto deinvestigacin son los siguientes: Definir propuesta metodolgica para la

especificacin de requerimientos desoftware.

Establecer marco terico metodolgicode tcnicas para verificar y validarespecificaciones de requerimientos desoftware.

Construir e implementar unaherramienta de software para la gestinde requerimientos, haciendo especialnfasis en la validacin de los mismos.

Objetivos Especficos

Validacin de modelos conceptuales enla especificacin de Requerimientos.

Posibilitar en todo momento latrazabilidad de requerimientos desde sucaptura, modelado y seguimiento.

Validacin de RequerimientosFuncionales.

Introduccin

La actividad de anlisis, diseo y

construccin de sistemas de informacininvolucra bsicamente a tres tipos deactores: los desarrolladores, que codificanlos programas en un lenguaje de

programacin determinado, los analistas,que especifican la funcionalidad que debetener el sistema resultante y los usuarios,que poseen requerimientos acerca de lo quedebera hacer el sistema para satisfacer sus

WICC 2012 537

2012 XIV Workshop de Investigadores en Ciencias de la Computacin


2/5

necesidades de informacin para la toma dedecisiones.

El anlisis de requisitos es la fase msimportante en el desarrollo de un proyectosoftware, ya que de un correcto anlisisdepender la correcta implementacin de la

aplicacin [1].El documento de especificacin derequisitos de software supone una especiede contrato entre usuario y desarrolladoresen el que unos indican sus necesidades,mientras que los otros se limitan aimplementar lo que se indica en eldocumento.

La tarea del anlisis de requisitos es unproceso de descubrimiento, refinamiento,modelado y especificacin y, por tanto, eldesarrollador y el cliente tienen un papel

activo en la obtencin de estas necesidades[2]. Las ltimas tecnologas utilizadas parala obtencin de requisitos permiten unamejor comprensin de los documentos deespecificaciones, que hasta ahora erandemasiado tcnicos para la correctacomprensin por parte del usuario.

Estas tcnicas modernas son los casos deuso, que forman parte del UML (LenguajeUnificado de Modelado) [3]. sta es la

principal herramienta utilizada para eldiseo completo de proyectos softwareorientado a objetos. Los casos de usomodelan el sistema desde el punto de vistadel usuario, permitindole as lacomprensin completa del futuro sistema.

Finalmente, se debe indicar que esta fasees posiblemente la ms costosa(temporalmente) en el desarrollo de un

producto software. Esto se debe a que, engeneral, el cliente no sabe realmente lo quequiere y requiere la ayuda de los analistas

para concretar las funciones que realmente

se han de implementar. Por tanto, de lacalidad del documento de ERS(Especificacin de Requerimientos deSoftware) depender el desarrollo y calidaddel producto final. La existencia de unestndar, como es el presentado en este

proyecto, para la ERS [4] permite lacoherencia en la especificacin derequisitos y ayuda a no dejar cabos sueltos.

Los principales objetivos que seidentifican en la especificacin derequisitos software son:

1. Ayudar a los clientes a describirclaramente lo que se desea obtenermediante un determinado software: El

cliente debe participar activamente en laespecificacin de requisitos, ya que stetiene una visin mucho ms detallada de los

procesos que se llevan a cabo.2. Ayudar a los desarrolladores a

entender qu quiere exactamente el cliente:En muchas ocasiones el cliente no sabeexactamente qu es lo que quiere. La ERS

permite al cliente definir todos losrequisitos que desea y al mismo tiempo losdesarrolladores tienen una base fija en laque trabajar. Si no se realiza una buena

especificacin de requisitos, los costes dedesarrollo pueden incrementarseconsiderablemente, ya que se deben hacercambios durante la creacin de laaplicacin.

3. Servir de base para desarrollos deestndares de ERS particulares para cadaorganizacin: Cada entidad puededesarrollar sus propios estndares paradefinir sus necesidades. Una buenaespecificacin de requisitos software ofreceuna serie de ventajas entre las que destacanel contrato entre cliente y desarrolladores(como ya se ha indicado con anterioridad),la reduccin del esfuerzo en el desarrollo,una buena base para la estimacin de costesy planificacin, un punto de referencia para

procesos de verificacin y validacin, y unabase para la identificacin de posiblesmejoras en los procesos analizados.

Las caractersticas deseables para unabuena especificacin de requisitos softwareque se indican en el IEEE son las

siguientes: Correcta No ambigua Completa Verificable Consistente Clasificada Modificable Explorable

WICC 2012 538



3/5

Utilizable durante las tareas demantenimiento y uso

Durante el proceso de validacin derequerimientos, se deben llevar a caboverificaciones sobre requerimientos en el

documento de requerimientos [5].Estas verificaciones comprenden:

1. Verificaciones de validez.2. Verificaciones de consistencia.3. Verificaciones de integridad.4. Verificaciones de realismo.5. Verificabilidad.

Pueden utilizarse varias tcnicas devalidacin de requerimientos, sin embargonuestro trabajo se centrar en la

construccin de modelos conceptualesbasados en los requerimientos para poderrealizar su validacin [6], [7], [8].

Entre algunas de las tcnicas devalidacin de requerimientos existentes se

pueden mencionar las siguientes:1. Revisiones de requerimientos.2. Construccin de prototipos3. Generacin de casos de prueba.4. Anlisis de consistencia automticoLa validacin de requerimientos es

importante debido a que los errores en eldocumento de requerimientos puedenconducir a importantes costos al repetir eltrabajo cuando son descubiertos durante eldesarrollo o despus de que el sistema esten uso. El costo de arreglar un problema enlos requerimientos haciendo un cambio enel sistema es mucho mayor que reparar loserrores de diseo o los de codificacin.

Principios generales a utilizar en lavalidacin:

1. Especificacin de los requisitos.

Una especificacin documentada de losrequisitos del software proporciona la base

para la validacin y la verificacin. Elproceso de validacin del software nopuede completarse sin un establecimientode las especificaciones de los requisitos.

2. Prevencin de defectos.

Las necesidades del aseguramiento de lacalidad del software fijan su atencin en la

prevencin de defectos en el proceso dedesarrollo del software y no en probar lacalidad del cdigo del software despus quese escribe. La prueba del software est muy

limitada en su capacidad de detectar todoslos defectos latentes en el cdigo delsoftware. La complejidad de la mayora delsoftware impide que sea probadoexhaustivamente. La prueba del software esuna actividad necesaria.

3. Tiempo y esfuerzo.

La validacin del software requieretiempo y esfuerzo. La preparacin para lavalidacin debe comenzar con anticipacin;es decir, durante la planificacin del diseoy desarrollo y el diseo de la entrada de

datos. La conclusin final que muestra queel software se encuentra validado debe estar

basada en la evidencia recolectada a partirde los esfuerzos planificados dirigidos a lolargo del ciclo de vida del software.

4. Ciclo de vida del software.

La validacin del software tiene lugardentro del ambiente del ciclo de vidaestablecido del software. El ciclo de vidadel software contiene las tareas deingeniera de software y la documentacinnecesaria para soportar la validacin delsoftware. Adems, el ciclo de vida delsoftware contiene las tareas especficas deverificacin y validacin que sonapropiadas para el uso previsto delsoftware. En la presente nota tcnica norecomendamos un modelo particular deciclo de vida (modelo lineal secuencial,modelo de construccin de prototipos,modelo de desarrollo rpido deaplicaciones, entre otros), sloestablecemos que se deben seleccionar los

modelos ms apropiados a utilizar en elproyecto de desarrollo del software. Variosmodelos del ciclo de vida del software sondefinidos en la ingeniera del software.

El ciclo de vida puede ser seguidocompletamente o tener variaciones en sudesarrollo, debido a las propiascaractersticas y naturaleza del software que

WICC 2012 539



4/5

se desea desarrollar y su dominio deimplementacin.

5. Planificacin.

El proceso de validacin del software sedefine y controla a travs de un plan. El

plan de validacin del software define lo

que ser logrado a travs del proceso devalidacin del software.6. Procedimientos.

El proceso de validacin del software serealiza a travs del uso de procedimientosdocumentados. Estos procedimientosestablecen "cmo", "quin" y "cundo" sellevar a cabo la validacin del software.Los procedimientos deben identificar lasacciones especficas o la sucesin deacciones que deben tomarse para completarlas actividades individuales de validacin.

7. Validacin del software despus de uncambio.

Debido a la complejidad del software, uncambio aparentemente pequeo puede tenerun impacto significativo en todo el sistema.Cuando se hace cualquier cambio alsoftware (incluyendo pequeos cambios), elestado de validacin del software necesitaser restablecido. Siempre que el softwaresea cambiado, un anlisis de validacindebe dirigirse no solamente para lavalidacin del cambio individual, sinotambin para determinar la magnitud eimpacto de ese cambio en la totalidad delsoftware.

8. Alcance de la validacin.El alcance de la validacin debe estar

basado en la complejidad del software y enlos riegos de seguridad; no en el tamao dela organizacin o la restriccin de losrecursos. La seleccin de las actividades ytareas a llevar a cabo durante la validacindeben corresponderse con la complejidad

del diseo del software y el riesgo asociadocon la utilizacin del software para el usoprevisto. La documentacin de la validacindebe ser suficiente para demostrar quetodos los planes y procedimientos devalidacin del software se han completadocon xito.

9. Independencia de la validacin.

Las actividades de validacin deben serconducidas cumpliendo el precepto bsicode gestin de la calidad sobre la"independencia de la revisin". La auto-validacin es sumamente difcil.

Cuando sea posible, siempre es mejor

llevar a cabo el proceso de validacin demanera independiente, sobre todo para lasaplicaciones que poseen un alto riesgo.Algunas organizaciones optan por lacontratacin de una tercera parteindependiente, pero esta solucin nosiempre es factible. Otro enfoque es asignarla validacin a miembros del personal de la

propia organizacin que no estninvolucrados en el desarrollo del software oen su aplicacin, pero que tienen suficienteconocimiento para evaluar el proyecto y

conducir el proceso de validacin. En estoscasos las organizaciones ms pequeasnecesitan ser creativas en la disposicin yasignacin de las tareas para mantener entodo momento la independencia.

10. Flexibilidad y responsabilidad.

La aplicacin especfica de estosprincipios de validacin del software puedeser muy diferente de una aplicacin a otra.El fabricante o desarrollador del softwaretiene flexibilidad a la hora de escoger comoaplicar estos principios de validacin, peroes el responsable de demostrar que elsoftware se ha validado. Las etapas del

proceso de validacin descritas aqu puedenser simplificadas dependiendo de lanaturaleza del software y de su uso previsto.

Resultados Esperados

Las principales funcionalidades queproveer la herramienta se describen acontinuacin:

Administracin de los atributos deun requerimiento.

Diseo del Modelo Conceptual. Gestin de cambios en los

requerimientos y medicin delimpacto de los mismos.

Modelado de diagramas UML. Clasificacin los requerimientos.

WICC 2012 540



5/5

Priorizacin de los requerimientos. Trazabilidad de los requerimientos. Validacin del Modelo Conceptual. Visualizacin de requerimientos. Generacin de reportes y

exportacin de los modelos a

distintos formatos como XML,PDF, UML, etc.

Gestin de la configuracin de losrequerimientos.

Cabe destacar que haremos especial nfasisen la validacin de los requerimientos, perotambin abarcaremos los dems aspectos dela gestin de los mismos para lograr unaherramienta integral que permita hacer elseguimiento continuo de su evolucin.

Formacin de Recursos Humanos

Este proyecto prev la formacin derecursos humanos que formen parte delmismo, y que al participar del proyectocontribuyan en su formacin.El mismo cuenta con tres becarios deinvestigacin, que formarn parte del

presente proyecto, y que sern de ayuda enla recoleccin, manipulacin y tabulacinde la informacin de entrenamiento del

sistema.Actualmente participan 3 tesistas de lamaestra de Ingeniera en Sistemas deInformacin y un doctorando de Ingenierade Software que desarrollan sus trabajos deen el mbito del proyecto, lo cual permitiruna contribucin a su formacin acadmica.

Al mismo tiempo se prev vinculacionescon otras redes de investigacin; al igualque la realizacin de un acuerdo detransferencia de resultados con algn

organismo que desee considerar losresultados producidos por el sistema que sedesarrollar.

Bibliografa

[1] I. Sommerville. Software Enginnering,Computing Departament, LancasterUniversity, John Willey & Sons Ltd., 2005.

[2] A. Davis Software requeriments Object,functions and states; Pretince Hall

international Inc. 1993.

[3] J. Rumbaugh, I. Jacobson, G.BoochThe Unified Modelling LanguageReference AddissonWesley 1999.

[4] ANSI/IEEE Standard 830-1984:Standard for software RequerimentsSpecifications, The institute of Electricaland Electronic Engeniers, New York, 1984.

[5] M. Jackson Software Requeriments &Specifications. Addisson Wesley.1995.

[6] G. Kotonya, I. Sommervivielle.Requeriments Engineering, Process andTecniques. John Wiley & sons. 1998.

[7] Emilio Insfrn, Isabel Daz y BurbanoMargarita. Modelado de Requisitos para laObtencin de esquemas conceptuales.Disponible en :http://www.dsic.upv.es/~einsfran/papers/39-ideas2002.pdf

[8] C. Leonardi, J.C.S. Leite, GustavoRossi. Una estrategia de ModeladoConceptual de Objetos , basada en Modelosde requisitos en lenguaje natural .Tesis deMaestra Universidad Nacional de la Plata.

WICC 2012 541


documento completo sando

Documents