CAPITULO II.doc

53
CAPITULO II FUNDAMENTO TEORICO En el presente capítulo presentamos la base teórica fundamental en el desarrollo del presente proyecto, pero antes de presentar la metodología de aplicación y el empleo de las técnicas en el desarrollo de la misma, iniciaremos con el reconocimiento de algunas términos generales de comprensión como lo es: sistema, sistema de información, enfoque de sistemas, con el fin de familiarizar en una visión orientada a la concepción de los sistemas en la administrativos, y su importancia en el proceso de cambio y adaptación tecnológica y administrativa de acuerdo al cumplimiento a los objetivos planteados. Además de comprender el enfoque aplicado en la elaboración de la misma. 2.1. ENFOQUE DE SISTEMAS. La visión integral considera al mundo desde el punto de vista de las relaciones y las integraciones. Los sistemas están todos integrados y sus propiedades no pueden reducirse a las unidades más pequeñas. En ves de concentrarse en los componentes básicos o en las substancias fundamentales, el enfoque integral hace hincapié en los principios básicos de la organización. 1 Thome y Willard describen el enfoque de sistemas en los siguientes términos: “El enfoque de sistemas es una forma ordenada de evaluar una necesidad humana de índole compleja y 1 Depto. de Informática: ENCUENTRO DE TEORIA DE SISTEMAS, Univ. Técnica Federico Santa Maria, 2001 1

Transcript of CAPITULO II.doc

CAPITULO IIFUNDAMENTO TEORICOEnelpresentecaptulopresentamoslabasetericafundamental eneldesarrollodelpresenteproyecto, pero antes de presentar la metodologa de aplicacin y el empleo de las tcnicas en eldesarrollodela misma,iniciaremos con elreconocimiento dealgunas trminosgeneralesdecomprensin como lo es: sistema, sistema de informacin, enfoque de sistemas, con el fin defamiliarizar en una visin orientada a la concepcin de los sistemas en la administrativos, y suimportancia en el procesodecambio yadaptacintecnolgica yadministrativadeacuerdoalcumplimientoalos objetivos planteados. Adems decomprender el enfoqueaplicadoenlaelaboracin de la misma.2.1. ENFOQUE DE SISTEMAS.!a visin integral considera al mundo desde el punto de vista de las relaciones y lasintegraciones. !os sistemas estn todos integrados y sus propiedades no pueden reducirse a lasunidades ms peque"as. En ves de concentrarse en los componentes bsicos o en las substanciasfundamentales, el enfoque integral #ace #incapi en los principios bsicos de la organizacin.$%#ome y &illard describen el enfoque de sistemas en los siguientes trminos: 'El enfoque desistemas es una forma ordenada de evaluar una necesidad #umana de ndole compleja y consisteen observar la situacin desde todos los ngulos y preguntarse: ()untos elementos distinguibles#ay en este problema aparente*, (+u relaciones de causa y efecto e,isten entre ellos*, (+ufunciones es preciso cumplir en cada caso*, (+u intercambios se requerirn entre los recursosuna vez que se definan*-.or lo tanto el enfoque de sistemas tiene una visinintegral, es una disciplina para vertotalidades, es decir un marco para ver relaciones entre cosas, este pone nfasis en los aspectosgenerales y en las interacciones entre las partes que la integran.$ /epto. de 0nformtica: E1)2E1%34 /E %E430A /E 505%E6A5, 2niv. %cnica 7ederico 5anta 6aria, 899$$2.2.SISTEMA DE INFORMACION.2nsistemadeinformacindentrounaorganizacin, esaquel quepermitequedeterminadainformacin fluya para coordinar sus acciones operativas, para llevar a cabo las funciones de laorganizacindemaneraco#erenteconlosobjetivosdelamisma.Aqu unadefinicin: '2n5istemade0nformacin, esunconjuntodeprocesamientosordenadosque, al serejecutados,proporcionan informacin para apoyar la toma de decisiones y control de la organizacin.84tradefinicineslasiguiente: 2n5istemade0nformacinesunadisposicindepersonas,actividades, datos, redes y tecnologa integrados entre si con el propsito de apoyar y mejorar lasoperaciones cotidianas de una empresa, as como satisfacer las necesidades de informacin parala resolucin de problemas y la toma de decisiones por parte de los directivos de la empresa.: 2.3. TECNICAS DE DESARROLLO DEL PRECENTE PROYECTO!ametodologaaplicadaenesteproyectoes el Anlisis y/ise"ode5istemas con0nterfaz;rafica de 2suario, aplicando un enfoque de sistemas en el desarrollo de la misma, obteniendoun sistema /istribuido.5e inicia realizando una fase de 0nspeccin del Anlisis usando una estructura .0E)E5, siguiendocon la determinacin de 3equisitos del 5istema, 3equerimientos 7uncionales y no 7uncionales.El desarrollo del 5istema de 0nformaciones lo realiza bajo un paradigma moderno como es elEspiral y en un entorno de Anlisis y /ise"o Estructurado 6oderno. 0nicia al 7ase de Anlisis de5istemas, a partir de los /7/, 7sico=Entrada y5alidas del 5istema>..osteriormenteseinicia conla0mplementacindel 5istema ylas pruebas correspondientesmediante las pruebas de )aja 1egra y ?lanca. !as tcnicas de anlisis y dise"o #an tenido un fuerte fundamento terico, estas pueden usarseempleando diversa filosofas de administracin de proyecto. .ara ilustrar las tcnicas y@ometodologas,se #a presentado una pirmide de desarrollo del 5oftAare =figura 8.$>, con unametfora geomtrica principal para organizar las actividades del desarrollo de sistemas, ya quepermite recordar que el cdigo que se construye es simplemente la base de una estructura queest especificada para el alcance de un conjunto de objetivos del negocio.8 5enn B Courdain: A1A!0505 D /05EE4 /E505%E6A5 /E 017436A)041, 6,ico, 6c;raA Fill, $GG8: itten y ?entley y ?arloA: A1A!0505 D /05EE4 /E 505%E6A5, :ra Ed.,Espa"a, 0rAin, $GGH, p.:G8PLANGENERALINSPECCIONDEL SISTEMAREQUISITOSDEL SISTEMALOGICOFISICOMODELO DECONTEXTO Y PROCESOSCREACION DE LA BASE DE DATOSMODELO DE INFORMACIONDICCIONARIO DE DATOSCREACION DE INTERFACES EXTERNASCODIFICACION Y PRUEBASMODELOARQUITECTONICODISEO DE ENTRADASDISEO DE SALIDASRECOLECCIONDE INFORMACION7igura.8.$. .irmide de desarrollo de 5oftAare.I2.4. TECNICAS PARA OBTENCION DE REQUERIMIETOS.Es un aspecto muy importante para determinar los requerimientos de informacin, pues se cuentacon una serie de mtodos los cules tienen ventajas como tambin restricciones. !os cuales nollega a ser completo, por lo cul se propone de tres mtodos los cuales sern ms completos en suaplicacin para nuestro estudio de manera conjunta. %ales son !aRevisin de Documentacin,!as Entrevistas, la Observacin, Puntos de Vista..ara poder comprender mas los requerimientos del sistema y ordenarlos los llevaremos estos a unlenguajeformal porel mtodode/efinicionde3equerimientos4rientadoa.untosde Jista=J43/>.2.4.1. ENTREVISTA.El propsito de la entrevista es la recoleccin de informacin acerca de un proceso en particular,tomando en cuenta los conocimientos de la situacin en estudio por parte de los usuarios.I Elaboracin propia, tomando como base la .irmide propuesta por: /avid A. 3uble: Anlisis y /ise"o .ractico de 5istemas )liente 5ervidor con ;20.:2na entrevista para recoleccin de informacin es una conversacin dirigida con un propsitoespecfico que usa un formato de preguntas y respuestas.K !os objetivos son informacin importante que puede ser recogida de las entrevistas. A partir deestodecidimosaquienentrevistar, ylaformadeencararlaentrevistatomandoencuentalaestructura y el tipo de preguntas elegidas, adems de enterarnos de tanta informacin sea posibledel proceso de administracin y mantenimiento vial, respecto a los datos que se maneja. 8.I.8. REVISIN DE DOCUMENTACIN.!a 3evisin de /ocumentacin es una tcnica para recolectar informacin respecto al registro deinformacin, volLmenes de informacin, atributos de las entidades de datos, organigramas quenos permiten conocer como operan sus procesos y objetivos de la organizacin. )omenzamos a3evisar losdocumentos registrados, losprocesosmasfrecuentes, el tipodeinformacinlosprocedimientos de operacin escrito. %odo ello nos servir para encarar un modelado de datos.2.4.3. OBSERVACIN.Este mtodo consiste en observar los diferentes procesos, identificando falencias en eldesenvolvimiento en las actividades cotidianas en el negocio. !a observacin es muy Ltil cuandoel analista necesita ver de primera mano cmo se manejan los documentos, como se llevan acabolos procesos y si ocurren los pasos especificados. !a observacin es un arte en si misma. )uandotermina el proceso, se cuenta con informacin adicional que no estara disponible por medio deotros mtodos de recopilacin de datos.8.K. FASE DE INSPECCION DEL ANALISIS.%ambinseconoceconel nombrede0nvestigacin.reliminar, Estudio0nicial oestudiodeviabilidad, paraestecasoilustraremos enunaestructura.0E)E5deCames &et#erbe. Estaestructura propone una plantilla que muestra su utilidad en el momento de registrarel anlisis deproblemas y oportunidades, y el registro de los objetivos del nuevo sistema.2.6. INGENIERIA DE REQUERIMIENTOS.2na de las primeras etapas del proceso de desarrollo de 5oftAare es la 0ngeniera de3equerimientos, enesta fase se definenyespecificanlos requerimientos delos clientes yusuarios. !as actividades involucradas en la 0ngeniera de 3equerimientos son: la obtencin, elK Mendall B Mendall: A1A!0505 D /05EE4 /E 505%E6A5, :ra. Ed., 6,ico, .rentice Fall Fispanoamericana 5.A.,$GGN, p.$9GIanlisis, la especificacin, la validacin y la administracin de los requerimientos de softAare.!os requerimientos de softAare se definen como las necesidades de los clientes, los servicios queel usuario desea que proporcione el sistema y las restricciones sobre las que el softAare debeoperar. El resultado del proceso de requerimientos es la base para el dise"o, la implementacin yla evaluacin del softAare. /e esta forma, si no se descubren y especifican todos losrequerimientosdel sistemaendesarrollo, podraconducirnosalaentregadeunproductodesoftAare incompleto, con alto ndice de riesgos y poco funcional.!a determinacin de requerimientos es el estudio de un sistema para conocer como trabaja ydonde es necesario efectuar mejoras.2n requerimiento es una caracterstica que debe incluirse en un nuevo sistema.H 2.7. PROCESO DE LA INGENIERIA DE REQUERIMIENTOSEl procesode0ngeniera de3equerimientos,involucra atodaslas actividadesnecesariasparacrear y mantener el documento de requerimientos del sistema. !as actividades que se definen enel procesode la 0ngeniera de 3equerimientos sonlassiguientes:$. 4btencin de los requerimientos8. Anlisis de requerimientos:. Especificacin de requerimientosI. Jalidacin de documento de especificacinK. Administracin de requerimientos2na manera de desarrollar el proceso de 0ngeniera de 3equerimientos es mediante el paradigmadel espiral, dondelas actividades sonrepetidas #astacuandoseobtengaundocumentoderequerimientos aceptable,como se muestra en la figura 8. 6ientras e,istan problemas en unaversin previa del documento de requerimientos =borrador>, se reingresa a las etapas del espiral,el proceso finaliza cuando se produzca un documento aceptable, de la misma forma, el procesopuede terminar por factores e,ternos como la presin del cliente la falta de recursos. /espusde que el documento sea producido satisfactoriamente, cualquier cambio futuro en losrequerimientos es parte de la administracin de los requerimientos.H Cames A. 5enn: /05EE4 /E 50%E6A5 /E 017436A)041, 8da. Ed., 6e,ico, 6c;raA Fill, $GG8, p.$88K7igura 8.8 El modelo espiral del proceso de 0ngeniera de 3equerimientos.2.8. ACTIVIDADES DEL PROCESO DE INGENIERIA DE REQUERIMIENTOSEl objetivodela0ngeniera de3equerimientos es obtener undocumentoformal dondeseespecifiquenlas caractersticas que debe cumplir el sistema que se va a desarrollar. Estascaractersticas y restricciones son definidas en comLn acuerdo por los usuarios del sistema y elanalista. !aespecificacindelos requerimientos debecumplir conciertas caractersticas decalidad, comolas siguientes: entendibles, necesarios, consistentes, noambiguos, completos,verificables, correctos, reales, rastreables y modificables.En cada una de las actividades del proceso de la 0ngeniera de 3equerimientos se llevan a cabotareas especficas utilizando tcnicas de requerimientos, modelos de especificacin y#erramientas para la administracin del documento de requerimientos.H2.8.1. OBTENCION DE REQUERIMIENTOSEn esta actividad se determina el dominio de la aplicacin, se especifican los servicios que debenproveerel sistema, lafuncionalidadrequeridadel sistema, ylasrestriccionesde#ardAareysoftAare. Es indispensable la participacin de los usuarios y clientes para la identificacin de losrequerimientos del sistema.5e debe obtener como resultado de esta actividad, un documento de definicin de losrequerimientos, donde se definen las necesidades inicialmente encontradas, esto no significa queestos requerimientos sean los definitivos, pueden ser agregados nuevos requerimientos conformese vayan encontrando o incluso los requerimientos establecidos pueden modificarse o eliminarse..ara lograr la obtencin de los requerimientos se definen tareas a seguir y son las siguientes.$. )omprender el problemaqueseestaresolviendo, esnecesarioestudiar el dominiooentorno en el que el sistema va a operar.8. ?uscar y recolectar informacin de manuales de operacin y mantenimiento, de manualesorganizacionales y polticas de operacin.:. /efinir los lmites y restricciones del sistema, para determinar con e,actitud que es lo queel sistema va #acer y tambin especificar lo que no va #acer.I. 0dentificar a las personas o usuarios interesados por el sistema, ya que ellos conocen elmedio ambiente en que operar el sistema y pueden ayudar describiendo sus necesidades.K. 3ecolectar y clasificar requerimientos, de esta manera los desarrolladores pueden iniciardefiniendo un bosquejo del sistema, su funcionamiento bsico y estableciendo el alcancedel sistemaEl desarrollo de estas tareas en la obtencin de requerimientos es realizado secuencialmente, peroesnecesarioquecadatareapuederegresarnos alaanterior, sobretodosi nosedescubrelainformacin necesaria en el primer recorrido del diagrama. !a figura 8.: muestra esta relacin.!a salida de esta actividad nos conduce #acia el anlisis de requerimientos.N7igura 8.: El proceso de obtencin de requerimientos.2.8.2. ANALISIS DE REQUERIMIENTOS!os requerimientos definidos en el documento de definicin son analizados detalladamente por elanalistaynegociadosconel usuarios, paradecidirlosrequerimientosquesernaceptadosydefinirlos de manera conjunta con el fin de #omogenizar su interpretacin. El anlisis del documentodedefinicinderequerimientos =//3> sellevaacabomediantetcnicas de revisin y verificacin de los criterios de calidad de cada requerimiento definido, esteestudio es realizado por el desarrolador y el usuarios.En el anlisis se llevan a cabo las siguientes actividades:$. .riorizar los requerimientos debido a que pueden e,istir requerimientos ms importantesque otros para los clientes y usuarios, por lo que deben ser clasificados e implementadosde acuerdo a su prioridad en el sistema.8. Encontrar dependencias entre requerimientos y etiquetar los requerimientos con unidentificador Lnico, con el fin de poderlos identificar o rastrear en el futuro.O:. 3esolver conflictos entre los requerimientos, se pueden encontrar conflictos entrerequerimientosmediantelarevisindeloscriteriosdecalidadquedebecumplircadarequerimiento del sistema.I. 1egociar confle,ibilidadconlos dems elementos del equipoqueintervienenenelprocesodedesarrollodesoftAare, para#omogenizarsucomprensinydeestaformatanto desarrolladores como usuarios tengan la misma interpretacin al momento de leer eldocumento de requerimientos.Elresultadodelanlisisesel/ocumentode/efinicinde3equerimientos=//3>, dondeseencuentran descritos los requerimientos iniciales del sistema que se va a desarrollar en lenguajenaturalP este documento sirve como seguimiento a las actividades del proceso de la 0ngeniera de3equerimientos, por lo que es necesario de que no e,istan requerimientos en conflictos y estnbien escritos. !a figura 8.I describe este proceso, muestra la interaccin de las tareas realizadas yla salida de esta actividad es la entrada a la actividad de especificacin de los requerimientos.7igura 8.I El proceso de anlisis de requerimientos.G2.8.3. ESPECIFICACIONES DE REQUERIMIENTOSEn esta actividad se obtiene como resultado el documento de especificacin de requerimientos.Este documentocontiene la descripcinprecisa de los requerimientos, incluye modelos derepresentacin que agregan detalles al sistema mostrndolo desde diferentes perspectivas..ara el desarrollo de esta actividad se realizan las siguientes tareas:$. Es!"#$#"%&'(s&!)*!+#!,-(s$*,"#(,%'!s.,($*,"#(,%'!s, ambos requerimientosdeben ser descritos a detalles para su mejor comprensin.8. D!-!&+#,%& !' -#( /! !s-0,/%&a utilizar para la definicin del /ocumento deEspecificacin de 3equerimientos =/E3>. 5e define el esquema del contenido del /E3 enbase al estndar definido por la 0EEE.:. E'!1#& '% 2!&&%+#!,-% /! !s!"#$#"%"#3,, en caso de utilizar alguna para automatizar elproceso.I. 2tilizar modelos y diagramas para e,plicar con mayor detalle y diferentes perspectivas elcomportamiento del sistema.K. 2tilizar cualquier informacin de soporte o gua para etapas posteriores y que amplen lacomprensin del sistema.%odas estas tareas van encaminadas a obtener el /ocumento de Especificacin de3equerimientos, en donde se especifican las funciones, restricciones o caractersticas del sistemaen desarrollo. Es necesario contar con toda la informacin disponible para formar un documentocompleto y que sirva como base de partida #acia las otras etapas del desarrollo del sistema. En lafigura 8.K se muestran las actividades de la especificacin de los requerimientos del sistema.$97igura 8.K !as actividades de la especificacin de requerimientos.2.8.4. VALIDACION DE REQUERIMIENTOS!a validacin permite detectar problemas en el documento de requerimientos, y se lleva a caboverificando cuidadosamente la consistencia y completitud del /E3, antes de que sea usado comobase en etapas posteriores del proceso de desarrollo del sistema. !a validacin es un proceso importante debido a que permite detectar errores en el documento derequerimientos, de forma que puedan ser corregidos a tiempo. Estos errores si no sondescubiertos en esta actividad pueden conducir a errores en el dise"o, ya que producen que serepitael trabajocuandoloserroresseandescubiertosenetapasposterioresdel desarrollodelsistema o en caso drsticos, si llegan a ser detectados cuando el sistema este en servicio.!os criterios que son revisados para validar el documento de especificacin de requerimientosson los siguientes:$. Jerificar validez. !os requerimientos satisfacen a las necesidades de los usuarios y sonnecesarios.$$8. Jerificar consistencia. !os requerimientosen el documento nodebencontradecirse, yaque esto generara conflictos en el momento de implementarse.:. Jerificar integridad, es decir, deben estar todos los requerimientos que describan todas lasfunciones y las restricciones propuestas por el usuario del sistema.I. Jerificar realismo, asegurar que los requerimientos puedan implementarse con latecnologa e,istente, considerando tambin el presupuesto y la calendarizacin deldesarrollo del sistema.K. G!,!&%& "%s(s /! &*!4% para los requerimientos.%odos estos criterios deben ser orientados #acia la aplicacin en el /ocumento de Especificacinde 3equerimientos, a fin de lograr su certificacin y validacin. Esta actividad es importante ydebe tomarse en cuenta en cualquier proceso de desarrollo de softAare porque garantiza que loe,presadoenel documentodetalladalascaractersticasdel sistemaquesevaadesarrollarypuede servir de base para las etapas de dise"o, implementacin y pruebas del softAare. En lafigura 8.H se muestra esta actividad.7igura 8.H !as actividades de la validacin del /E3.$82.8.5. ADMINISTRACION DE REQUERIMIENTOS!aadministracindelos requerimientos describeel procesodecomprender ycontrolar loscambios en los requerimientos del sistema, Esta actividad comienza en cuanto e,iste la primeraversin del documento de requerimientos cuando se planea darle mantenimiento a un sistemae,istente. Especficamente, en esta actividad se requiere lo siguiente:$. A/+#,#s-&%& '(s "%+4#(s /! '(s &!)*!+#!,-(s. Esto implica el anlisis del problema ysu propuesta de cambio, valorar el costo del cambio propuesto y finalmente implementarlos cambios en los documentos que lo requieran.8. Es-%4'!"!& ('6-#"%s /! &%s-&!(. Es necesario conocer el origen de los requerimientos olos efectos que tendrn los cambios en los requerimientos relacionados.:. C(,-&(' /! 7!&s#(,!s /!' /("*+!,-( /! &!)*!+#!,-(s cuando implique algLn cambiopara referencias futuras.2.8. TECNICAS DE ANALISIS DE REQUERIMIENTOS!os requerimientos deben ser analizados detalladamente tanto por el equipo de desarrollo comoporlosusuariospararesolver conflictosdeambigQedadyconsistenciaentrerequerimientos,priorizando los requerimientos que #an de ser inicialmente implementados en el sistema, ademsde negociarlos con fle,ibilidad para #omogenizar su comprensin y de esta forma obtener unalista consistente de requerimientos. .ara realizar el anlisis se cuenta con diversas tcnicas, comolas que se mencionan a continuacin.2.8.1. LA IDENTIFICACION DE LOS REQUERIMIENTOS5e debe identificar a cada requerimiento de manera Lnica, de tal forma que puedan permitir unareferencia cruzada con otros requerimientos, y as utilizarse en las evaluaciones de rastreo. .araidentificar cada requerimiento se pueden usar las letras iniciales del tipo de requerimiento y unnLmero de referencia, por ejemplo si se tratara de un requerimiento funcional puede usarse lasiguiente estructura 37n, donde n es un nLmero entero consecutivo para cada requerimiento yparalos requerimientos nofuncionales 317n. Ejemplos deidentificacinderequerimientosfuncionales y no funcionales:RF2.1 En este subRsistema se podr asignar valores de unidades mtricasRNF45e debe poder #acer usodel 5A6RJdesde toda .)que este conectada a la redinformatica de la institucion.$:2.8.1. LISTAS DE VERFICACION 9C2!":'#s-;.Esta tcnica es muy fcil de utilizar y proporciona una gran utilidad. En general, es una lista depreguntas que el analista debe usar para evaluar cada requerimiento. !os analistas deben verificarymarcar lospuntos deestalistamientras leenel documentoderequerimientos, cuandosedescubran problemas potenciales, debern ser anotados, ya sea en los mrgenes del documento, en una lista de verificacin. !as listas de verificacin son Ltiles porque brindan un recordatoriode lo que se debe buscar y reducen la posibilidad de pasar por alto alguna verificacinimportante. 1o slo son Ltiles para verificar requerimientos, sino tambin se puede aplicar conlos casos de uso. El proceso de verificacin se puede implementar con una #oja de clculo endonde las filas representan, por ejemplo, los distintos requerimientos, y las columnas representanlos puntos a verificar los criterios que deben cumplir, como se ilustra en la tabla 8.$. Entoncessecompletanlas intersecciones quecorrespondanconlos comentarios sobrelos problemaspotenciales.%abla 8.$ !ista de verificacin de calidad en los requerimientos.2.8.2. MATRI< DE DEPENDENCIA ENTRE REQUERIMIENTOS5uponiendo que los requerimientos sean claramente identificados y enumerados, entoncespodemos utilizar una matriz de dependencia de requerimientos, donde se listen en orden todos losrequerimientos identificados, como se muestra en la tabla 8.8.%abla 8.8 6atriz de dependencia entre requerimientos.$I!as celdas de la matriz son marcadas con una S si dos requerimientos tienen dependencia o seescribe enlas celdas si estnintercalados oenconflicto. 2na celda vaca indica que losrequerimientossonindependientes. !osrequerimientosenconflictoointercaladospodrnserdiscutidos con los clientes para despus ser replanteados y de este modo resolver los conflictos ola intercalacin entre estos. !a matriz de dependencia de requerimientos es una tcnica simplepero efectiva para encontrar conflictos e intercalaciones cuando el nLmero de requerimientos esrelativamente peque"o. 5in embargo, cuando el nLmero de requerimiento es mayor, la tcnicaaLn puede ser usada si los requerimientos se agrupan en categoras, de esta forma losrequerimientos pueden ser comparados separadamente en cada categora.2.1=. TIPOS DE REQUERIMIENTOS DE ACUERDO A SUS CARACTERISTICASEsta clasificacin se realiza en funcin de la naturaleza de las caractersticas del sistema que sedesarrolla, generalmente los requerimientos de sistemas de softAare se clasifican en funcionales,no funcionales.2.1=.1. REQUERIMIENTOS FUNCIONALES!osrequerimientos funcionalessondeclaracionesdelosserviciosqueproveerel sistemaycomprenden la interaccin entre el sistema y su ambiente, la reaccin a entradas particulares dedatos y su comportamiento en condiciones especficas. En algunos casos tambin declaran lo queel sistema no debe #acer.2.1=.2. REQUERIMIENTOS NO FUNCIONALES.!os requerimientos no funcionales, son especificaciones de las restricciones de los servicios ofunciones ofrecidas por el sistema, restricciones sobre el sistema que limitan nuestras eleccionesen la solucin a un problema. !os requerimientos no funcionales no se refieren directamente a las funciones especficas queentrega el sistema, sino a sus propiedades emergentes. E,isten muc#as maneras de clasificarlos,5ommerville T8U propone la siguiente clasificacin.$K2.11. ESTANDARES DE DOCUMENTACIONEl/ocumentodeEspecificacindeberestarescritodeunamaneracorrectayformal detalmodo que tenga solouna interpretacin por las personas involucradas. /e esta forma, seanalizaron todas las propuestas para obtener y presentar una manera de organizar el /ocumentode Especificacin de 3equerimientos.2.11.1. EL ESTANDAR IEEE>ANSI 83=?1883E,isten diferentes formas de definir y especificar los requerimientos en un documento formal,por lo que un gran nLmero de diferentes organizaciones se #an preocupado por definir estndarespara los documentos de requerimientos.El ms usual es el propuesto por la 0EEE y la A150conocido como el estndar 0EEE@A150 O:9R$GG:, tambin brevemente llamado como, el estndarO:9R$GG:, que sugiere la siguiente estructura para los documentos de requerimientos: $. 0ntroduccin .ropsito del documento de requerimientos Alcance del producto /efiniciones, acrnimos y abreviaturas$H 3eferencias 3esumen del resto del documento8. /escripcin general .erspectiva del producto 7unciones del producto )aracterstica del usuario 3estricciones generales 5uposiciones y dependencias:. 3equerimientos especficos 3equerimientos funcionales 3equerimientos no funcionales 3equerimientos de interfaz.=!osrequerimientospuedendocumentar lasinterfacese,ternas, describirlafuncionalidad y el desempe"o del sistema, especificar los requerimientoslgicos delas bases dedatos, las restricciones dedise"o, las propiedadesemergentes del sistema y las caractersticas de calidad>.I. ApndicesK. VndicesEl estndarpropuestoesunaguaorecomendacinparalaestructuracindel documentoderequerimientos. 5inembargo, sepuedetransformaryadaptarparadefinirunestndarqueseajuste a las necesidades de una organizacin en particular..ara presentar el documento de requerimientos del 5A6RJ, se propone la siguiente estructuraque es una definicin de los puntos ms importantes de todos los enfoques estudiados y tomandocomo referencia el estndar 0EEE@A150 O:9R$GG:.$. 0ntroduccin .ropsito del documento de Especificacin de 3equerimientos del 5A6RJ Alcance del documento de Especificacin de 3equerimientos del 5A6RJ8. /escripcin ;eneral /escripcin del sistema actual$N .ropsito y alcance del 5A6RJ )onte,to del 5A6RJ 0dentificacin de interesados =staWe#olders>:. /efinicin de los 3equerimientos /efinicin de los 3equerimientos bsicos del 5A6RJ. /efinicin de los 3equerimientos 7uncionales del 5A6RJ usando lenguaje natural /efinicin de los 3equerimientos 1o 7uncionales del 5A6RJ usando lenguaje naturalI. Especificacin de los requerimientos del 5A6RJ Especificacin de 3equerimientos 7uncionales del 5A6RJ usando formas en lenguajenatural estructurado. 6odelos del sistema 6odelo de /atos 6odelos de )omportamiento 6odelos 4rientados a 4bjetosK. )riterios de Jalidacin del /ocumento de Especificacin de 3equerimientos del 5A6RJH. Evolucin del 5A6RJN. ApndicesO. ;losarios2.12. TECNICAS DE ESPECIFICACION DE REQUERIMIENTOSEn esta actividad se obtiene el documento de especificacin de requerimientos que es orientado adiversos tipos de lectores, por lo que es necesario contar con mLltiples niveles de descripcin. Esnecesariocontar conmodelos derepresentacin, mtodos, metodologas y#erramientas queproporcionanlamaneradedescribir losdiferentestiposderequerimientosdel sistemaeneldocumentodeespecificacin. El documentoes redactadoparaqueseainterpretadopor losusuarios ypor los dise"adores del sistema, recordemos que los usuarios sonpersonas sinconocimientos tcnicos de implementacin, por otro lado el equipo de dise"o son e,pertos en elrea, por lo que se requiere de ambas perspectivas del documento.E,isten varias maneras dedescribir los requerimientos de softAare en este caso utilizaremos e !enguaje 1atural.$O2.12.1. LENGUA@E NATURALEl lenguaje natural es utilizado en la mayora de las veces para escribir los requerimientos delsistemaconel finde que los usuarios puedancomprenderlossinnecesidadde conocimientostcnicos de desarrollo y comprobar que sus necesidades estn e,presadas en el documento derequerimientos. .or otro lado, aunque el lenguaje natural sea fle,ible y sencillo puede contenerproblemas de interpretacin. Algunos problemas que se pueden encontrar en la descripcin de losrequerimientos utilizando el lenguaje natural son: C(,A*,"#3, /! R!)*!+#!,-(s. Jarios requerimientos diferentes se e,presan de formaconjunta como un Lnico requerimiento. L%"(+&!,s#3,/!' '!,1*%A!,%-*&%'radicaenqueloslectores yredactores delaespecificacin utilicen la misma palabra para el concepto. L% !s!"#$#"%"#3, /!' '!,1*%A! ,%-*&%' !s /!+%s#%/( $'!B#4'!. 5e puede decir lo mismode formas completamente diferentes. N( !B#s-! *,% $(&+% $0"#' /! +(/*'%C%& '(s &!)*!+#!,-(s.El lenguaje natural esdifcil e,#ibir todos los requerimientos relacionados.2.12.2. LENGUA@E NATURAL ESTRUCTURADOEste lenguaje es una forma restringida del lenguaje natural para e,presar los requerimientos delsistema asegurandoque se imponga unciertogradode uniformidad a la especificacinymanteniendo la e,presividadycomprensindel lenguaje natural. .ara la notacinde estelenguaje es fundamental el uso de plantillas o formas estndar para especificar losrequerimientos. )ada forma debe incluir la siguiente informacin:$. 2na descripcin de la funcin o entidad a especificar.8. 2na descripcin de sus entradas y de donde provienen.:. 2na descripcin de sus salidas y #acia donde van.I. 2na descripcin de que otras entidades se utilizan.K. 5i se utiliza un enfoque funcional, definir una precondicin y poscondicin.H. 2na descripcin de los efectos colaterales =si e,istes> de la operacin.)on esto podemos lograr eliminar algunos problemas y obtener menos variacin enlaespecificacin, sin embargo pueden permanecer algunas ambigQedades en la especificacin. !afigura 8.N muestra un ejemplo de una plantilla para especificar los requerimientos de softAare.$G7igura 8.N .lantilla para especificar requerimientos de softAare en lenguaje natural estructurado.2.13. EL MDTODO VORD.El mtodo J43/ =JieApointR4riented 3equirements /efinition, /efinicin de 3equerimientos4rientado a .untos de Jista>, es sobre todo propuesto para especificar sistemas interactivos, perotambin puede ser usado para especificar otras clases de sistemas T$$U. El mtodo J43/ estbasado en puntos de vista que se enfocan en usuarios involucrados en aspectos organizacionales.Elmodeloorientadoapuntosdevistaesorientadoaservicios. El sistemadaserviciosalospuntos de vista y los puntos de vista pasan informacin de control y parmetros asociados alsistema. !ospuntosdevista proyectanlasclases de usuarios finales de un sistema o deotrointerconectado. !os puntos de vista que estructuran el nLcleo del modelo, son conocidos comopuntos de vista directos. .or el #ec#o de que no todos los requerimientos son derivados de genteosubsistemasqueinteractLanconsistemasespecificados. !ospuntosdevistaquerespectaasistemas e,ternos que tienen influencia en el dominio de la aplicacin tambin son consideradosy son llamados puntos de vista indirectos.892.13.1. PUNTOS DE VISTA DIRECTOS. Estos corresponden directamente a clientes que reciben servicios del sistema y envaninformacin de datos y de control al sistema. .ueden ser cualquier sistema usuario@operador uotro subsistema que interactLa con el sistema analizado.2.13.2. PUNTOS DE VISTA INDIRECTOS.!os puntos de vista indirectos tienen un inters en algunos o todos los servicios del sistema, peronointeractLandirectamente conl, estos puedengenerar requerimientos querestringenlosservicios entregados a puntos de vista directos. !os puntos de vista indirectos tienen unaimportancia en los puntos de vista de la ingeniera =estos se refieren al dise"o e implementacindel sistema>, mediante los puntos de vista organizacional =se refieren a la influencia deorganizacin>, a puntos de vista e,ternos =se refieren a la influencia del sistema en el ambientee,terno>.El mtodo J43/ est basado en tres principales pasos iterativos llamados:$. 0dentificacin y estructuracin de los puntos de vista.8. /ocumentacin de los puntos de vista.:. Anlisis y especificacin de los requerimientos de puntos de vista.En el primer punto se trata de identificar los puntos de vista, y son declaraciones abstractas de lasnecesidadesdelaorganizacin. El segundopasoconsisteendocumentar lospuntosdevistaidentificados en el paso uno. !a documentacin consiste en:$. Etiquetar y describir el punto de vista identificado.8. 3astrear los tipos de puntos de vista como directos o indirectos.:. Atributos que caracterizan a los puntos de vista en el dominio de la aplicacin.I. 3equerimientos de puntos de vista, estos incluyen un conjunto de servicios requeridos,requerimientos de control y requerimientos funcionales.K. Escenarios de eventos que describen la interaccin entre los puntos de vista y el sistemapropuesto.H. Fistorial depuntosdevistaquedescribenlaevolucindelosrequerimientos delospuntos de vista.El tercer paso se refiere con la identificacin de errores y conflictos y su solucin. El resultadofinal es el documento de la especificacin de requerimientos.8$En la figura 8.O se muestra el proceso del modelo iterativo J43/. !os procesos son mostradosen rectngulos con esquinas redondeadas y los productos en rectngulos con esquinas cuadradas.)ada producto puede ser visto como el control para un proceso de revisin.7igura 8.O El proceso del modelo J43/.!a notacin grafica usada para representar los puntos de vista en el J43/ se muestra en la figura8.G. !ospuntosdevistaserepresentanenrectngulos, seidentificancomosemuestraenlaesquina superior izquierda y se etiquetan a partir de la mitad de abajo del rectngulo, el tipo depuntodevistaorastreosemuestraenlaesquinasuperior derec#aysuespecializacinsonrectnguloscontiguosporel ladoderec#o, se"aladoporunaflec#aquepartedeizquierdaaderec#a. )ada punto de vista tiene uno o ms tipos especializados. 2n punto de vistaespecializado comparte ciertos servicios y atributos con los puntos de vista padre, pero puederecibir servicios adicionales o imponer sus propias limitaciones sobre los servicios #eredados..untos de vistas y 3equerimientos abstractos.untos de vistas.untos de vistas documentados3equerimientos negociadosEspecificacin de 3equerimientosEspecificar puntos de vista/ocumentar puntos de vistaAnalizar requerimientosEspecificar requerimientos887igura 8.G El proceso del modelo J43/.2.14. EERRAMIENTA DE SOFTFARE PARA LA ADMINISTRACIN DE LOSREQUERIMIENTOS.)ada vez es ms comLn el uso de las #erramientas de softAare en el desarrollo de sistemas, estas#erramientas pueden integrarse y constituir una #erramienta )A5E compleja que puede abarcartodoel procesodedesarrollodeunsistema. Enesteparteserealiza unarevisindeuna#erramienta de softAare para la administracin de los requerimientos. Aunque todas las#erramientas de administracin de los requerimientos conservan un propsito comLn. En general,una#erramientadesoftAareparalaadministracindelosrequerimientos, seconcentranenadministrar y producir el documento de especificacin de los requerimientos del sistema.2.14.1 VOORT(('.!a #erramienta Jord%ool fue desarrollada por 0an 5ommerville y Matonya en el a"o de $GGH T::U,y se basa en la especificacin de requerimientos orientado a puntos de vista. El modelo adoptadopor J43/%ool es orientado a servicios donde los puntos de vista son anlogos a clientes en unsistemaclienteRservidor.El sistemacaptalosservicioscomopuntosdevistaylospuntosdevistas pasan informacin de control al sistema. !os puntos de vista mapean clases de usuariosfinales de un sistema o las interfaces #acia otros sistemas. !os puntos de vista que constituyen labase del modelo son conocidos como puntos de vista directos. !os puntos de vista que respecta aotros sistemas que tienen influencia en el dominio de la aplicacin tambin son considerados yson llamados puntos de vista indirectos. Ambos puntos de vistas representan a los requerimientosfuncionales y no funcionales respectivamente.T#(E-#)*!-%,,.1,.26 X atributo8:%. P*,-(s /! 7#s-% D#&!"-(s. )orresponden directamente a clientes que reciben servicios del sistema y envan informacindedatosydecontrol al sistema, ypuedeser cualquier sistemausuario@operador uotrosubsistema que interactLa con el sistema analizado.4. Puntos de vista Indirectos. !ospuntosdevistaindirectos tienenuninters enalgunosoentodoslosservicios delsistema, peronointeractLandirectamenteconl. !os puntos devistaindirectos puedengenerar requerimientos que restringen los servicios entregados a puntos de vista directos.El mtodo J43/ est basado en tres pasos iterativos que son:$.L% I/!,-#$#"%"#3, . !s-&*"-*&%"#3, /! '(s *,-(s /! 7#s-% trata de identificar los puntos devista, y son declaraciones abstractas de las necesidades de la organizacin8.L%D("*+!,-%"#3,/!'(s *,-(s /!7#s-%consisteendocumentar los puntos devistaidentificados. !a documentacin consiste en:a> Etiquetar y describir el punto de vista identificado.b> 3astrear los tipos de puntos de vista como directos o indirectos.c> /efinir atributos que caracterizan a los puntos de vista en el dominio de la aplicacin.d> 0dentificar los requerimientos de puntos de vista, estos incluyen un conjunto de serviciosrequeridos, requerimientos de control y requerimientos funcionales.e> /efinir los escenarios de eventos que describen la interaccin entre los puntos de vista yel sistema propuesto.f> Fistorial depuntosdevistaquedescribenlaevolucindelosrequerimientos delospuntos de vista.2.14.1.1. ELANGLISISYESPECIFICACINDELOSREQUERIMIENTOSDEPUNTOS DE VISTA!a#erramienta J43/%ool sebasaenladefinicindelos*,-(s /!7#s-%s /#&!"-(squecorresponden con los requerimientos funcionales y los*,-(s /! 7#s-%s #,/#&!"-(squecorrespondenconlos requerimientos nofuncionales. 6edianteesteesquema, sedefinenlosnodos descendientes. En los puntos de vista directos se establecen dos jerarquas, los puntos de7#s-% /#&!"-(s /!' (!&%/(& y los puntos de 7#s-% /#&!"-(s /!' s#s-!+%. En los puntos de vista deloperador, se consideran los usuarios o sistemas e,ternos que obtienen o proporcionan un servicioal sistema analizado, y para los puntos de vista del sistema se consideran los subsistemas internos8Io componentes del sistema en desarrollo. !a figura 8.$9 ilustra la jerarqua de puntos de vistaabstracta definida en J43/%ool.7igura 8.$9.Cerarqua de .untos de Jista en J43/%ool..ara los puntos de vista indirectos se tienen cuatro jerarquas de nodos, los puntos de vista nofuncionales de la organizacin del negocio, regulacin, ambiente e ingeniera. Estos Lltimos tresse refieren a requerimientos no funcionales propios del sistema de cmputo en donde residir elsistema, y las restricciones de tecnologa.En J43/%ool, para agregar un punto de vista a la jerarqua de clases abstractas, se elige el icono, el cual mostrar una forma donde describir el punto de vista que desee agregar, como seilustra en la figura 8.$$.8K7igura 8.$$. Agregando un punto de vista.J43/%ool proporciona dos maneras de mostrar el esquema de puntos de vista de sus proyectos,una es mediante el esquema jerrquico de clases abstracta =como en la figura 8.$9>, y la otramedianteunesquemadescriptivodelosnodosopuntosdevistasdescendientesenel editorcanvas de la aplicacin =como aparece en la figura 8.$8>. 5e puede alternar de un esquema a otro,mediante el icono. .ara asignar atributos a un punto de vista seleccionado, se utiliza el icono, por ejemplo enlafigura8.$8semuestracomoagregarelatributoNum_EmpalpuntodevistaCoordinador.)adapuntodevistadefinidolecorrespondeunidentificadornumricoquesemuestraenlaesquina superior izquierda, tambin los atributos tienen un identificador que depende delidentificador del punto de vista al que corresponden.8H7igura 8.$8. Agregando atributos a un punto de vista.En este conte,to, cada punto de vista le corresponde uno o ms requerimientos que lo definen, yparaagregarunrequerimientoaunpuntodevista, enJ43/%ool seutilizael icono ..rimeroseleccioneel puntodevista, enseguidael iconoparaagregarunrequerimiento, estaaccindespliegaunaformadondesecolocael identificador oetiquetadel requerimiento, ladescripcin del requerimiento, el origen y la razn de importancia en el sistema. )on la opcinRacionale, puede agregar los siguientes datos: !a prioridad del requerimiento y su justificacin,el tipo de requerimiento y los requerimientos asociados. En la figura H se ilustra la pantalla deJ43/%ool para agregar el requerimientoElegir_Cursoal puntode vistalumno, para elejemplo del 50J.8N7igura 8.$:. Asignar requerimientos a un punto de vistas.4tra de las caractersticas de J43/%ool es que puede describir los conflictos encontrados entrelos requerimientos, mediante el icono de la barra de #erramienta. .ara revisar losrequerimientos asignados a cada punto de vista, el procedimiento es el siguiente. 5e elige un parde requerimientos que se van a analizar, si se encuentran conflictos en la casilla conflict found seescribenrecomendacionespararesolverlosconflictosdelosrequerimientosanalizados. Estasrecomendaciones podrn ser utilizadas ms tarde para negociar con el cliente los requerimientosen conflictos. En la figura 8.$I. se muestra la ventana de la forma para identificacin de conflictoaralosrequerimientosdelejemplo50J,enestecasosonVer_Curso, yElegir_Curso, ambosrequerimientos no presentan conflictos.8O7igura 8.$I. 7orma de identificacin de conflictos.En J43/%ool, la revisin de los requerimientos, puntos de vista y las notas puede llevarse acabode manera automtica, mediante el icono. Esta accin proporciona una forma como la quese ilustra en la figura 8.$K , donde aparecen atributos como el nLmero de la revisin, la fec#a y elttulo que define la revisin, el nombre de las personas que llevan a cabo la revisin, el tipo deelemento que se esta revisando, en este caso puede ser un punto de vista, un requerimiento, unanota, o un escenario de evento. /e acuerdo a la seleccin del elemento a revisar, se activa unalista de preguntas que deben ser contestadas por las personas que realiza la revisin. En caso deque #aya conflictos el revisor puede escribir sus recomendaciones en el rea para aparece paraeste fin.8G7igura 8.$K. 7orma para revisin de los requerimientos.!a desventaja de esta #erramienta es que se encuentra ligada a un anlisis orientado a puntos devista para definir los requerimientos. Esto obliga a utilizar tcnicas de obtencin derequerimientos queestnorientadas aesteparadigma. 1oposeefle,ibilidadparaelegir unenfoque diferente como lo es la orientacin a objetos mediante casos de uso.2.15. PARADIGMAS PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN.2nparadigma omodelodel procesodedesarrollodesoftAare, es una descripcinde lasactividades quesellevanacaboenlaelaboracindeunproductodesoftAare. Al procesocompleto de desarrollo, tambin se le conoce como "#"'( /! 7#/% /!' s($-H%&!, debido a que enl se detalla la vida de un sistema desde su concepcin, implementacin, entrega, utilizacin y#asta sumantenimiento. Enla literatura de0ngeniera de 5oftAare e,iste unavariedaddemodelos o paradigmas de desarrollo. !os modelos ms utilizados se describen a continuacin.:9El .aradigma )ascada, Evolutivo, 0ncremental o 0terativo, Espiral, 6todos 7ormales, ?asado en)omponentes, El 32.,etc. 5iendoel Estrella yel 32.,el nuevoenfoque deAplicacin,mostrando una estructura Evolutiva 0ncremental. 2.15.1 DESARROLLO EN ESPIRALEl modelo en espiral fue propuesto por ?oe#m en el a"o de $GOO. Este modelo representa elproceso de softAare como una espiral, e,amina el progreso de desarrollo de softAare tomando enconsideracin los riesgos involucrados para minimizarlos y controlarlos, de esta forma combinalas actividades del desarrollo con la gestin del riesgo T$U. El espiral se divide en cuatro sectoresque comprenden: la definicin de objetivos, la evaluacin y reduccin de riesgos, el desarrollo yvalidacin, y por Lltimo la planeacin =figura 8.$H>.El modelo fue desarrollado en el .entgono como un mtodo para controlar los costosdesbocadosdearmasmasivasyproyectosdedesarrollodesistemasdedefensa. !aideafuedividir el proyecto en fases ms cortas de anlisis, dise"o, desarrollo y evaluacin. /espus decada fase se evalLa la viabilidad del trabajo terminado junto con una estimacin refinada para lassiguientes fases. Esta tcnica de presupuestacin proporciono revisiones de factibilidad crucialesparaproyectos endondefrecuentemente estaban#aciendoinvestigaciones sobretecnologascompletamente nuevas. 5e toma una decisin en la fase de evaluacin sobre si se debe continuarcon otra iteracin de ajuste. !a idea de la espiral #a cambiado ligeramente para adaptarse a lassensibilidades peculiares de la industria de softAare. :$7igura 8.$H /esarrollo en espiral.El modelo del espiral se ajusta al avance de los proyectos, sinembargo requiere de unaadministracin muy cuidadosa. El ciclo del espiral comienza con los requerimientos y un plan dedesarrollo, agregandounaevaluacinderiesgosyconstruyeprototiposalternativosantesdeescribir el documentodeconceptos deoperacin. El documentodeconceptos deoperacindescribeenunaltonivel comodebetrabajarel sistema, esdecir, especificaunconjuntoderequerimientos completos yconsistentes. El principal productodelaprimeraiteracineselconcepto de operaciones, en la segunda iteracin son los requerimientos, en la tercera iteracin eldise"o y de la cuarta son las pruebas. .ara cada iteracin el anlisis de riesgos pondera diferentesalternativasenbasedelosrequerimientosyrestricciones, el prototipadoverificael gradodefactibilidad antes de elegir alguna alternativa de desarrollo en particular, si se identifican riesgoslos lideres del equipo de desarrollo son los que deciden como eliminarlos o minimizarlos T$U. C%&%"-!&6s-#"%s /!' +(/!'( !s#&%'o 6ejora los )iclos de Jida )lsicos y .rototipos.:8o .ermite acomodar otros modelos.o 0ncorpora objetivos de calidad y gestin de riesgos.o Elimina errores y alternativas no atractivas al comienzo.o .ermite 0teraciones, vueltas atrs y finalizaciones rpidas.o )ada)icloempiezaidentificandolosobjetivosdelaporcincorrespondiente, lasAlternativas y las 3estricciones.)adaciclosecompletaconunarevisinqueincluyetodoel cicloanterioryel planparaelsiguiente./urante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y lasrestricciones, y se analizan e identifican los riesgos. 5i el anlisis de riesgo indica que #ay unaincertidumbreenlos requisitos, sepuedeusar lacreacindeprototipos enel cuadrantedeingeniera para dar asistencia tanto al encargado de desarrollo como al cliente. El cliente evalLa eltrabajo de ingeniera =cuadrante de evaluacin de cliente> y sugiere modificaciones. 5obre la basede los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo.5iendo la ultima iteracin el proceso de ajuste final. 4bteniendo de esta manera un 5istema de0nformacin acorde a las e,igencias del usuario. 2.16. INTERFACES GRGFICAS DE USUARIO 9GUI;.!os interfaces graficasde usuario =;20> permiten el manejo directo de la representacin graficaen la pantalla, proporcionan un panorama ms amigable y cmodo sujeto a las especificacionesdel usuario.!a clave para el ;20 es la retroalimentacin constante sobre el logro de la tarea que proporciona.!a retroalimentacincontinua del objeto manipulado significa que los cambios o reversiones enlasoperacionespueden#acerserpidamentesincaerenmensajesdeerror.-3etroalimentacinpara usuarios-.N

N Mendall B Mendall: A1A!0505 D /05EE4 /E 505%E6A5, :ra. Ed., 6e,ico, .rentice Fall Fispanoamericana 5.A. $GGN, p.HKN::2.17. ANALISIS Y DISEIO DE SISTEMAS.%anto el Anlisis como el /ise"o son actividades complementarias, veamos algunas definiciones:Definicinn!lisis"'El anlisis desistemas es el estudiodeunaaplicacindel sistemadeinformacin y de empresa actual y la definicin de las necesidades y las prioridades de usuariopara conseguir una aplicacin nueva o mejorada.-ODefinicinDise#o"Y/ise"oes el procesode aplicar distintas tcnicas yprincipios conelpropsito de definir un dispositivo, proceso, o sistema,con los suficientes detalles como parapermitir su realizacin fsica.YG .or lotantoel Anlisis es el procesodeclasificar einterpretar los #ec#os, diagnosticodeproblemasyempleodelainformacinpararecomendar mejorasal sistema, mientrasqueel/ise"o es el proceso de planificar, reemplazar o complementar unsistema organizacionale,istente, pero antes de llevar a cabo esta planeacin es necesario comprender, en su totalidad, elviejo sistema, nos indica como transformar la necesidad producto del anlisis en formas que lossatisfaga, desarrollando modelos a partir de un conjunto de principios y@o #eursticas que guan laforma en la que se desarrolla el modelo, un conjunto de criterios que permiten discernir sobrecalidad y un proceso de iteracin que conduce finalmente a una representacin del dise"o final.7inalmenteel AnlisisespecificaQUE es loqueel sistema debe#acer.El /ise"o estableceCOMO alcanzar el objetivo. 7recuentementeanalistaydise"adorsonlamismapersona, sinembargoesnecesarioqueserealice un cambio de enfoque mental al pasar de una etapa a la otra. Al abordar la etapa de dise"o,la persona debe cambiar de un razonamiento de analista a un razonamiento de dise"ador.ZZZ.ZZZ.ZZZZZZ.ZZZZZZZZ..ZZZZZZ.ZZZZZZZZ..ZZZZZZ.ZZZZZZZZ..ZZZZZZ.O itten y ?entley y ?arloA: A1A!0505 D /05EE4 /E 505%E6A5, :ra. Edicion., Espa"a, 0rAin, $GGH, p.8HKG E.5. %aylor: A1 01%E306 3E.43% 41 E1;01EE301; /E50;1, 6assac#ussets 0nstitute of %ec#nology, $GKG:I2.18.DISEIO DE ENTRADAS.!as decisiones de dise"o para el manejo de entradas especifican la forma en que sern aceptadoslos datos para su procesamiento por computadora..!os analistas deciden que los datos sernproporcionados directamente o quizs a travs de una estacin de trabajo. El dise"o de la entradatambin incluye la especificacin de los medios por lo que tanto los usuarios finales como losoperadores darn instrucciones al sistema sobre las acciones que deben emprender.!os analistas de sistemas deciden los siguientes detalles del dise"o de entradas:o +ue datos ingresan al sistema o +ue medios utilizaro !a forma en que se deben disponer o codificar los datoso El dialogo que servir de gua a los usuarios para dar entrada a los datoso Jalidaciones necesarias de datos y transacciones para detectar errores o 6todosparallevar acabolavalidacindelasentradasylospasosaseguircuando se presentan errores !a disposicin de mensajes y comentarios, as como la ubicacin de los datos, encabezados yttulos sobre las pantallas o documentos fuentes, tambin forman parte del dise"o de entradas.2.18. DISEIO DE SALIDAS.El trmino salida, se refiere a los resultados e informacin generados por el sistema. .ara muc#osusuarios finales, la salida es la Lnica razn para el desarrollo del sistema y la base sobre la queellos evaluaran la utilidad de la aplicacin. En la realidad, muc#os usuarios no operan el sistemade informacin y tampoco ingresan datos con l, pero utilizan la salida generada por el sistema.)uando dise"a la salida, los analistas deben realizar lo siguiente:o /eterminar que informacin presentaro /ecidir si la informacin ser presentada en forma visual, verbal o impresa.o /isponer la presentacin de la informacin en un formato aceptable.o /ecidir como distribuir la salida entre los posibles destinatarios.:K!a disposicin de la informacin sobre una pantalla o documento impreso se denominadistribucin..ara llevar a cabo las actividades antes mencionadas, se requieren decisiones especficas talescomoelempleode formatos ya impresoscuandose preparanreportes,cuantaslneas planearsobre una pgina impresa o si se deben emplear graficas y colores.El dise"o de la salida esta especificado en los formularios de distribucin,que son #ojas quedescriben la ubicacin, caractersticas =como longitud y tipo> y formato de los encabezados decolumnas y la paginacin. 2.2=. PRUEBAS DEL SISTEMA./urante la prueba, el sistema se utiliza en forma e,perimental para asegurar el softAare no falle,esdecir,quecorrerdeacuerdoconsusespecificacionesyamaneraenlaquelosusuariosesperan que lo #aga. 5e e,aminan datos especiales de prueba en la entrada del procesamiento ylos resultados para localizar algunos problemas inesperados. .uede permitirse tambin a un grupolimitado de usuarios que utilice el sistema, de manera que los analistas puedan captar si tratan deutilizar, o en forma no planeadas..ara esto las pruebas se basaran en la .rueba de la )aja 1egray !a .rueba de la )aja ?lanca.2.2=.1 PRUEBA DE LA CA@A NEGRA.!as pruebas funcionales o de 'caja negra- son un enfoque para llevar a cabo pruebas donde estasderivandela especificacindel programa o componente.Elsistemaesun'caja negra- cuyocomportamiento solo se puede determinar estudiando las entradas y salidas relacionadas.4tronombre de estas pruebas funcionales debido a que elprobador solo le interesa la funcionalidad yno la implementacin del softAare.El probador introducelas entradas enlos componentes del sistema ye,amina las salidascorrespondientes. 5i las salidas no son las previstas, entonces la prueba #a detectadoe,itosamente un problema con el softAare.El problema clave para el probador de defectos es seleccionar las entradas que tienen una altaprobabilidad de ser miembros de un conjunto de entradas que provocan comportamientoanmalo. En muc#os casos, la seleccin de estos casos de prueba se basa en la e,perienciapreviade los ingenieros de pruebas.$9$9 5ommerville, 0an: 01;E10E30A /E 547%&A3E, Hta. Ed. 6e,ico, .earson Educacin, 8998, p.II::HEs casi imprescindible lograr unacobertura de cajanegradel $99[, pues los usuarios sequejaran con todo derec#o de fallos de este calibre.!as actividades de las pruebas seran:o 0gnora la estructura de controlo /ise"o de pruebaso /atos entrada R\ ?uen caso de pruebao Atencin a la informacin2.2=.2 PRUEBA DE LA CA@A BLANCA.!as pruebas estructurales o de 'caja blanca-, 'caja de cristal- o de 'caja transparente- son unenfoque de prueba donde estas se generan a partir del conocimiento de la estructura eimplementacin del softAare..or logeneral, las pruebas estructurales seaplicana unidades del programa relativamentepeque"as como las rutinas o las operaciones asociadas con un objeto. )omo su nombre indica, elprobador puede analizar el cdigo y utilizar el conocimiento de la estructura de un componentepara derivar los datos de prueba. El anlisis de cdigo se puede utilizar para descubrir cuantoscasos depruebasonnecesarios paragarantizar quetodas las instrucciones del programaocomponente se ejecuten al menos una vez.$$.uede que #abiendo logrado una cobertura de caja negra del $99[, midamos una cobertura desentencias =.ruebas de )aja ?lanca> del $99[. .uede ser que partes del cdigo no #ayan sidoejecutadas jams =la cobertura de sentencias es inferior al $99[>. En estos casos #ay que pasarms pruebas buscando que se ejecuten todas y cada una de las sentencias del programa. En el caso e,tremo de que no #aya forma de ejecutar alguna parte del programa,deberamospreguntarnos si esa parte sirve para algo, o si podemos prescindir de ella. !a cobertura de las pruebas de )aja ?lanca sera:o Ejercitar una vez todos los caminos.o Ejercitar todas las decisiones =J@7>.o Ejercitar todos los bucles =lmites>.$$5ommerville, 0an: 01;E10E30A /E 547%&A3E, Hta. Edicin, 6,ico, .earson Educacin, 8998 p.IIG:NT$U 5#ari !aArence .fleeger, 0ngeniera de 5oftAare, teora y prctica, .rentice Fall, 8998.T8U 5ommerville 0an, 5oftAare Engineering, &iley, $GGO.T$$U Motonya ;erald, 5ommerville 0an, 3equirements Engineering, processes andtec#niques,&iley, 8999.:O