2. requerimientos del software

40,897 views

Published on

  • Be the first to comment

2. requerimientos del software

  1. 1. REQUERIMIENTOS DEL SOFTWAREINDICEINTRODUCCIONREQUERIMIENTOS DEL SOFTWARECARACTERÍSTICAS DE LOS REQUERIMIENTOSDIFICULTADES PARA DEFINIR LOS REQUERIMIENTOSCARACTERÍSTICAS DE UN REQUERIMIENTOFUNDAMENTOS DEL ANÁLISIS DE REQUERIMIENTOSTAREAS DEL ANÁLISISESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS)CLASIFICACIÓN DE LOS REQUERIMIENTOSACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOSPRINCIPIOS DE ESPECIFICACIÓNMANEJO DE REQUERIMIENTOSORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIOREQUERIMIENTOS DEL SISTEMAESTRATEGIA DEL FLUJO DE DATOSESTRATEGIA DEL ANÁLISIS DE DECISIONESETAPAS EN LA ESTRATEGIA DEL ANÁLISIS DEL FLUJO DE DATOSUTILIZACIÓN DE LOS DATOS DE REQUERIMIENTOSDOCUMENTOS DE REQUERIMIENTOS DEL SOFTWAREMÉTODOS DE ANÁLISIS ORIENTADOS AL FLUJO DE DATOSDIAGRAMAS DE FLUJOS DE DATOSDICCIONARIO DE DATOSDESCRIPCIONES FUNCIONALESMÉTODOS ORIENTADOS A LA ESTRUCTURA DE DATOSBIBLIOGRAFÍAESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWAREINTRODUCCION¿Qué son Requerimientos?Normalmente, un tema de la Ingeniería de Software tiene diferentes
  2. 2. significados. De las muchas definiciones que existen para requerimiento, hacontinuación se presenta la definición que aparece en el glosario de la IEEE:(1) Una condición o necesidad de un usuario para resolver un problema oalcanzar un objetivo.(2) Una condición o capacidad que debe estar presente en un sistema ocomponentes de sistema para satisfacer un contrato, estándar,especificación u otro documento formal.(3) Una representación documentada de una condición o capacidad comoen (1) o (2).Los requerimientos puedes dividirse en requerimientos funcionales yrequerimientos no funcionales.Los requerimientos funcionales definen las funciones que el sistema serácapaz de realizar. Describen las transformaciones que el sistema realiza sobrelas entradas para producir salidas.Los requerimientos no funcionales tienen que ver con características que deuna u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,etc.Características de los requerimientosLas características de un requerimiento son sus propiedades principales. Unconjunto de requerimientos en estado de madurez, deben presentar una seriede características tanto individualmente como en grupo. A continuación sepresentan las más importantes.Necesario: Un requerimiento es necesario si su omisión provoca una
  3. 3. deficiencia en el sistema a construir, y además su capacidad, característicasfísicas o factor de calidad no pueden ser reemplazados por otras capacidadesdel producto o del proceso.Conciso: Un requerimiento es conciso si es fácil de leer y entender. Suredacción debe ser simple y clara para aquellos que vayan a consultarlo en unfuturo.Completo: Un requerimiento está completo si no necesita ampliar detalles ensu redacción, es decir, si se proporciona la información suficiente para sucomprensión.Consistente: Un requerimiento es consistente si no es contradictorio con otrorequerimiento.No ambiguo: Un requerimiento no es ambiguo cuando tiene una solainterpretación.Verificable: Un requerimiento es verificable cuando puede ser cuantificado demanera que permita hacer uso de los siguientes métodos de verificación:inspección, análisis, demostración o pruebas.* Dificultades para definir los requerimientos *• Los requerimientos no son obvios y vienen de muchas fuentes.• Son difíciles de expresar en palabras (el lenguaje es ambiguo).• Existen muchos tipos de requerimientos y diferentes niveles de detalle.• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.• Nunca son iguales. Algunos son más difíciles, más riesgosos, másimportantes o más estables que otros.• Los requerimientos están relacionados unos con otros, y a su vez serelacionan con otras partes del proceso.• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionalesespecíficas.• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.• Son difíciles de cuantificar, ya que cada conjunto de requerimientos esparticular para cada proyecto.
  4. 4. * Ingeniería de Requerimientos vs. Administración de Requerimientos *El proceso de recopilar, analizar y verificar las necesidades del cliente paraun sistema es llamado Ingeniería de Requerimientos. La meta de laingeniería de requerimientos (IR) es entregar una especificación de requisitosde software correcta y completa.Los requerimientos son la Pieza fundamental en un proyecto de desarrollo desoftware, es ellos se basan muchos participantes del proyecto para:Planear el proyecto y los recursos que se usarán en él. Los líderes de proyectousan los requerimientos como una base para la estimación del esfuerzonecesario en un proyecto.Especificar el tipo de verificaciones que se habrán de realizar al sistema. Porejemplo: cuando se está tratando de alinearse a cierta norma oficial o estándar.Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Losrequerimientos son la base sobre la cual se decide si un caso de prueba fueejecutado exitosamente por el sistema o no.Son el fundamento del ciclo de vida del proyecto. Los requerimientosdocumentados son la base para crear la documentación del sistemaDe ahí su importancia y la importancia de que deban de ser definidos ymanejados de la forma mas adecuada posible.Características de un requerimientoYa que visualizamos la importancia de los requerimientos en un sistema desoftware entonces debemos de definir que características deben de poseer losrequerimientos adecuadamente formulados.Los requerimientos deben ser:Especificados por escrito. Como todo contrato o acuerdo entre dos partesPosibles de probar o verificar. Si un requerimiento no se puede comprobar,
  5. 5. entonces ¿cómo sabemos si cumplimos con él o no?Descritos como una característica del sistema a entregar. Esto es: que es loque el sistema debe de hacer (y no como debe de hacerlo)Lo más abstracto y conciso posible. Para evitar malas interpretaciones.* Fundamentos del Análisis de Requerimientos *Definición: Es el conjunto de técnicas y procedimientos que nos permitenconocer los elementos necesarios para definir un proyecto de software.Es la etapa más crucial del desarrollo de un proyecto de software.La IEEE los divide en funcionales y no funcionales:Funcionales: Condición o capacidad de un sistema requerida por el usuariopara resolver un problema o alcanzar un objetivo.No Funcionales: Condición o capacidad que debe poseer un sistema parasatisfacer un contrato, un estándar, una especificación u otro documentoformalmente impuesto.Para realizar bien el desarrollo de software es esencial realizar unaespecificación completa de los requerimientos de los mismos.Independientemente de lo bien diseñado o codificado que esté, un programapobremente especificado decepcionará al usuario y hará fracasar el desarrollo.La tarea de análisis de los requerimientos es un proceso dedescubrimiento y refinamiento, El ámbito del programa, establecidoinicialmente durante la ingeniería del sistema, es refinado en detalle. Seanalizan y asignan a los distintos elementos de los programas las solucionesalternativas.
  6. 6. Tanto el que desarrolla el software como el cliente tienen un papel activoen la especificación de requerimientos. El cliente intenta reformular suconcepto, algo nebuloso, de la función y comportamiento de los programas endetalles concretos, El que desarrolla el software actúa como interrogador,consultor y el que resuelve los problemas.El análisis y especificación de requerimientos puede parecer una tarearelativamente sencilla, pero las apariencias engañan. Puesto que el contenidode comunicación es muy alto, abundan los cambios por mala interpretacióno falta de información. El dilema con el que se enfrenta un ingeniero desoftware puede ser comprendido repitiendo la sentencia de un cliente anónimo:"Sé que crees que comprendes lo que piensas que he dicho, pero noestoy seguro de que lo que creíste oír sea lo que yo quise decir".Los requerimientos de un sistema de software, cuando se ven en su conjuntoson extensos y detallados, y además contienen múltiples relaciones entre sí. Loque nos da a concluir, que el conjunto de requerimientos de un sistemacomputacional es complejo.Obtenemos la posibilidad de especificar sistemas complejos al documentarespecificaciones simples y concisas para el sistema. Esto se logra mediante alclasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otraspalabras al analizar sus requerimientos.El análisis de requerimientos es la tarea que plantea la asignación de softwarea nivel de sistema y el diseño de programas. El análisis de requerimientosfacilita al ingeniero de sistemas especificar: la función y comportamiento de los programas, indicar la interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe cumplir el programa.El análisis de requerimientos permite al ingeniero:
  7. 7. refinar la asignación de software y representar el dominio de la información que será tratada por el programa.El análisis de requerimientos da al diseñador: la representación de la información y las funciones que pueden ser traducidas en datos, arquitectura y diseño procedimental.Finalmente, la especificación de requerimientos suministra al técnico y alcliente: los medios para valorar la calidad de los programas, una vez que se haya construido. * Tareas del Análisis * El análisis de requerimientos puede dividirse en cuatro áreas: 1.- Reconocimiento del problema 2.- Evaluación y síntesis 3.- Especificación 4.- Revisión. Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los programas que se usó para generar las estimaciones de la planificación. A continuación, debe establecerse la comunicación necesaria para el análisis, de forma que se asegure el reconocimiento del problema. El analista debe establecer contacto con el equipo técnico y de gestión del
  8. 8. usuario / cliente y con la empresa que vaya a desarrollar el software. Elgestor del programa puede servir como coordinador para facilitar elestablecimiento de los caminos de comunicación. El objetivo del analista esreconocer los elementos básicos del programa tal como lo percibe elusuario / cliente.La evaluación del problema y la síntesis de la solución es la siguienteárea principal de trabajo del análisis. El analista debe evaluar el flujo yestructura de la información, refinar en detalle todas las funciones delprograma, establecer las características de la interfase del sistema ydescubrir las ligaduras del diseño, Cada una de las tareas sirven paradescubrir el problema de forma que pueda sintetizarse un enfoque osolución global.Las tareas asociadas con el análisis y especificación existen para dar unarepresentación del programa que pueda ser revisada y aprobada por elcliente. En un mundo ideal el cliente desarrolla una especificación derequerimientos del software completamente por sí mismo. Esto se presentararamente en el mundo real. En el mejor de los casos, la especificación sedesarrolla conjuntamente entre el cliente y el técnico.Una vez que se hayan descrito las funcionalidades básicas,comportamiento, interfase e información, se especifican los criterios devalidación para demostrar una comprensión de una correctaimplementación de los programas. Estos criterios sirven como base parahacer una prueba durante el desarrollo de los programas. Para definir lascaracterísticas y atributos del software se escribe una especificación derequerimientos formal. Además, para los casos en los que se desarrolleun prototipo se realiza un manual de usuario preliminar.Puede parecer innecesario realizar un manual de usuario en una etapa tantemprana del proceso de desarrollo, Pero de hecho, este borrador delmanual de usuario fuerza al analista a tomar el punto de vista del usuario
  9. 9. del software. El manual permite al usuario / cliente revisar el softwaredesde una perspectiva de ingeniería humana y frecuentemente produce elcomentario: "La idea es correcta pero esta no es la forma en que penséque se podría hacer esto". Es mejor descubrir tales comentarios lo mástempranamente posible en el proceso.Los documentos del análisis de requerimiento (especificación y manual deusuario) sirven como base para una revisión conducida por el cliente y eltécnico. La revisión de los requerimientos casi siempre producemodificaciones en la función, comportamiento, representación de lainformación, ligaduras o criterios de validación. Además, se realiza unanueva apreciación del plan del proyecto de software para determinar si lasprimeras estimaciones siguen siendo validas después del conocimientoadicional obtenido durante el análisis.* Obteniendo de la información *Los requerimientos son el punto de acuerdo entre el cliente y el proyecto dedesarrollo de software, este entendimiento es necesario para poderconstruir software que satisfaga las necesidades de nuestro cliente.Si los requerimientos se enfocan a describir las necesidades del cliente,entonces es lógico que para recabarlos haya que obtener la información deprimera mano. Esto es, mediante entrevistas con el cliente o recabandodocumentación que describa la manera que el cliente desea que funcioneel sistema de software.Las necesidades y / o requerimientos del cliente evolucionan con el tiempoy cada cambio involucra un costo. Por eso es necesario tener archivadauna copia de la documentación original del cliente, así como cada revisióno cambio que se haga a esta documentación. Como cada necesidad delcliente es tratada de diferente forma, es necesario clasificar estas
  10. 10. necesidades para saber cuáles de ellas serán satisfechas por el software ycuales por algún otro producto del sistema.* Especificación de Requisitos de Software *(SRS)La especificación de requisitos de software es la actividad en la cual segenera el documento, con el mismo nombre, que contiene una descripcióncompleta de las necesidades y funcionalidades del sistema que serádesarrollado; describe el alcance del sistema y la forma en cómo hará susfunciones, definiendo los requerimientos funcionales y los no funcionales.En la SRS se definen todos los requerimientos de hardware y software,diagramas, modelos de sistemas y cualquier otra información que sirva desoporte y guía para fases posteriores.Es importante destacar que la especificación de requisitos es el resultadofinal de las actividades de análisis y evaluación de requerimientos; estedocumento resultante será utilizado como fuente básica de comunicaciónentre los clientes, usuarios finales, analistas de sistema, personal depruebas, y todo aquel involucrado en la implementación del sistema.Los clientes y usuarios utilizan la SRS para comparar si lo que se estáproponiendo, coincide con las necesidades de la empresa. Los analistas yprogramadores la utilizan para determinar el producto que debedesarrollarse. El personal de pruebas elaborará las pruebas funcionales yde sistemas en base a este documento. Para el administrador del proyectosirve como referencia y control de la evolución del sistema.La SRS posee las mismas características de los requerimientos: completa,consistente, verificable, no ambigua, factible, modificable, rastreable,precisa, entre otras. Para que cada característica de la SRS seaconsiderada, cada uno de los requerimientos debe cumplirlas; por ejemplo,para que una SRS se considere verificable, cada requerimiento definido enella debe ser verificable; para que una SRS se considere modificable, cadarequerimiento debe ser modificable y así sucesivamente. Las
  11. 11. características de la SRS son verificadas en la actividad de Validación,descrita en el punto.La estandarización de la SRS es fundamental pues ayudará, entre otrascosas, a facilitar la lectura y escritura de la misma. Será un documentofamiliar para todos los involucrados, además de asegurar que se cubrentodos los tópicos importantes.Existen plantillas creadas para la SRS, sin embargo, cada uno tiene lapotestad de crear su propia plantilla.Clasificación de los requerimientosEl clasificar requerimientos es una forma de organizarlos, hayrequerimientos que por sus características no pueden ser tratados iguales.La siguiente es una recomendación de como pueden ser clasificados losrequerimientos aunque cada proyecto de software pueda usar sus propiasclasificaciones.• Requerimientos del "entorno"El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar elentorno, existen cierto tipo de requerimientos que se clasifican en estacategoría porque:El sistema usa el entorno y lo necesita como una fuente de los serviciosnecesarios para que funcione. Ejemplos del entorno podemos mencionar:sistemas operativos, sistema de archivos, bases de datos.El sistema debe de ser robusto y tolerar los errores que puedan ocurrir enel entorno, tales como congestión en los dispositivos y errores de entradade datos, por lo tanto el entorno se debe de considerar dentro de losrequerimientos.
  12. 12. • Requerimientos ergonómicos"Él más conocido de los requerimientos ergonómicos es la interfase con elusuario o GUI (Graphic User Interface). En otras palabras, losrequerimientos ergonómicos son la forma en que el ser humano interactúacon el ser sistema.• Requerimientos de InterfaseLa interfase es como interactúa el sistema con el ser humano o con otrossistemas (el enfoque es prácticamente el opuesto a los requerimientosergonómicos), La interfase es la especificación formal de los datos que elsistema recibe o manda al exterior. Usualmente se especifica el protocolo,el tipo de información, el medio para comunicarse y el formato de los datosque se van a comunicar.* Actividades de la Ingeniería de Requerimientos *En el proceso de IR son esenciales diversas actividades. En estedocumento serán presentadas, sin embargo, en un proceso de ingenieríade requerimientos efectivo, estas actividades son aplicadas de maneracontinua y en orden variado.Dependiendo del tamaño del proyecto y del modelo de proceso de softwareutilizado para el ciclo de desarrollo, las actividades de la IR varían tanto ennúmero como en nombres. La tabla #1 muestra algunos ejemplos de lasactividades identificadas para cada proceso.A pesar de las diferentes interpretaciones que cada desarrollador tengasobre el conjunto de actividades mostradas en la tabla anterior, podemosidentificar y extraer cinco actividades principales que son:
  13. 13. • Análisis del Problema• Evaluación y Negociación• Especificación• Validación• Evolución* Principios de Especificación *La especificación, independientemente del modo en que se realice, puedeser vista como un proceso de representación. Los requerimientos serepresentan de forma que conduzcan finalmente a una correctaimplementación del software.Baltzer y Goldman proponen ocho principios para una buenaespecificación:PRINCIPIO #1. Separar funcionalidad de implementación.Una especificación es una descripción de lo que se desea, en vez de cómose realiza (implementa). Las especificaciones pueden adoptar dos formasmuy diferentes. La primera forma es la de funciones matemáticas: dadoalgún conjunto de entrada, producir un conjunto particular de salida. Laforma general de tales especificaciones es encontrar [un/el/todos] resultadotal que P (entrada), donde P representa un predicado arbitrario. En talesespecificaciones, el resultado a ser obtenido ha sido expresadoenteramente en una forma sobre el que (en vez de cómo). En parte, estoes debido a que el resultado es una función matemática de la entrada (la
  14. 14. operación tiene puntos de comienzo y parada bien definidos) y no estáafectado por el entorno que le rodea.PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemasorientado al proceso.Considerar una situación en la que el entorno sea dinámico y sus cambiosafecten al comportamiento de alguna entidad que interactúe con dichoentorno. Su comportamiento no puede ser expresado como una funciónmatemática de su entrada. En vez de ello, debe emplearse una descripciónorientada al proceso, en la cual la especificación del que se consiguemediante la especificación de un modelo del comportamiento deseado entérminos de respuestas funcionales, a distintos estímulos del entorno.PRINCIPIO #3. Una especificación debe abarcar el sistema del cual elsoftware es una componente.Un sistema está compuesto de componentes que interactúan. Solo dentrodel contexto del sistema completo y de la interacción entre sus partespuede ser definido el comportamiento de una componente específica. Engeneral, un sistema puede ser modelado como una colección de objetospasivos y activos. Estos objetos están interrelacionados y dichas relacionesentre los objetos cambian con el tiempo. Estas relaciones dinámicassuministran los estímulos a los cuales los objetos activos, llamadosagentes, responden. Las respuestas pueden causar posteriormentecambios y, por tanto, estímulos adicionales a los cuales los agentes debenresponder.PRINCIPIO #4. Una especificación debe abarcar el entorno en el que elsistema opera.
  15. 15. Similarmente, el entorno en el que opera el sistema y con el que interactúadebe ser especificado.Afortunadamente, esto tan solo necesita reconocer que el propio entornoes un sistema compuesto de objetos que interactúan, pasivos y activos, delos cuales el sistema especificado es una agente, Los otros agentes, loscuales son por definición inalterables debido a que son parte del entorno,limitan el ámbito del diseño subsecuente y de la implementación. De hecho,la única diferencia entre el sistema y su entorno es que el esfuerzo dediseño e implementación subsecuente opera exclusivamente sobre laespecificación del sistema. La especificación del entorno facilita que seespecifique la interfaz del sistema de la misma forma que el propio sistema,en vez de introducir otro formalismo.PRINCIPIO #5. Una especificación de sistema debe ser un modelocognitivo.La especificación de un sistema debe ser un modelo cognitivo, en vez deun modelo de diseño o implementación. Debe describir un sistema tal comoes percibido por su comunidad de usuario. Los objetivos que manipuladeben corresponderse con objetos reales de dicho dominio; los agentesdeben modelar los individuos, organizaciones y equipo de ese dominio; ylas acciones que ejecutan deben modelar lo que realmente ocurre en eldominio. Además, debe ser posible incorporar en la especificación lasreglas o leyes que gobiernan los objetos del dominio. Algunas de estasleyes proscriben ciertos estados del sistema (tal como "dos objetos nopueden estar en el mismo lugar al mismo tiempo"), y por tanto limitan elcomportamiento de los agentes o indican la necesidad de una posteriorelaboración para prevenir que surjan estos estados.PRINCIPIO #6. Una especificación debe ser operacional.
  16. 16. La especificación debe ser completa y lo bastante formal para que puedausarse para determinar si una implementación propuesta satisface laespecificación de pruebas elegidas arbitrariamente. Esto es, dado elresultado de una implementación sobre algún conjunto arbitrario de datoselegibles, debe ser posible usar la especificación para validar estosresultados. Esto implica que la especificación, aunque no sea unaespecificación completa del como, pueda actuar como un generador deposibles comportamientos, entre los que debe estar la implementaciónpropuesta. Por tanto, en un sentido extenso, la especificación debe seroperacional.PRINCIPIO #7. La especificación del sistema debe ser tolerante con laincompletitud y aumentable.Ninguna especificación puede ser siempre totalmente completa. El entornoen el que existe es demasiado complejo para ello. Una especificación essiempre un modelo, una abstracción, de alguna situación real (oimaginada). Por tanto, será incompleta. Además, al ser formulad existiránmuchos niveles de detalle. La operacionalidad requerida anteriormente nonecesita ser completa. Las herramientas de análisis empleadas paraayudar a los especificadores y para probar las especificaciones, deben sercapaces de tratar con la incompletitud. Naturalmente esto debilita elanálisis, el cual puede ser ejecutado ampliando el rango decomportamiento aceptables, los cuales satisfacen la especificación, pero taldegradación debe reflejar los restantes niveles de incertidumbre.PRINCIPIO #8. Una especificación debe ser localizada y débilmenteacoplada.Los principios anteriores tratan con la especificación como una entidadestática. Esta surge de la dinámica de la especificación. Debe serreconocido que aunque el principal propósito de una especificación seaservir como base para el diseño e implementación de algún sistema, no esun objeto estático precompuesto, sino un objeto dinámico que sufreconsiderables modificaciones. Tales modificaciones se presentan en tresactividades principales: formulación, cuando se está creando una
  17. 17. especificación inicial; desarrollo, cuando la especificación se estaelaborando durante el proceso iterativo de diseño e implementación; ymantenimiento, cuando la especificación se cambia para reflejar un entornomodificado y / o requerimientos funcionales adicionales.• Requerimientos funcionalesEstos son los que describen lo que el sistema debe de hacer. Esimportante que se describa él ¿Qué? Y no él ¿Cómo?. Estosrequerimientos al tiempo que avanza el proyecto de software se conviertenen los algoritmos, la lógica y gran parte del código del sistema.• Requerimientos de desempeñoEstos requerimientos nos informan las características de desempeño quedeben de tener el sistema. ¿Qué tan rápido?, ¿Que tan seguido?,¿Cuántos recursos?, ¿Cuantas transacciones?Este tipo de requerimientos es de especial importancia en los sistemas detiempo real en donde el desempeño de un sistema es tan crítico como sufuncionamiento.• Disponibilidad (en un determinado periodo de tiempo)Este tipo de requerimientos se refiere a la durabilidad, degradación,potabilidad, flexibilidad, contabilidad y capacidad de actualización. Este tipode requerimientos es también muy importante en sistemas de tiempo realpuesto que estos sistemas manejan aplicaciones críticas que no deben deestar fuera de servicio por periodos prolongados de tiempo.
  18. 18. • EntrenamientoEste tipo de requerimientos se enfoca a las personas que van usar elsistema. ¿Qué tipo de usuarios son?, ¿Que tipo de operadores?, ¿Quemanuales se entregarán y en que idioma?Este tipo de requerimientos, aunque muchas veces no termina en unpedazo de código dentro del sistema, son muy importantes en el procesode diseño ya que facilitan la introducción y aceptación del sistema endonde será implementado.• Restricciones de diseñoMuchas veces las soluciones de un sistema de software son normadas porleyes o estándares, este tipo de normas caen como "restricciones dediseño".• MaterialesAquí se especifica en que medio se entregara el sistema y como estaempaquetado. Es importante para definir los costos de industrialización delsistema.* Manejo de requerimientos *De acuerdo con el "Capability Maturity Model" (CMM), el manejo derequerimientos involucra:"Establecer y mantener un acuerdo con el cliente sobre los requerimientos
  19. 19. del proyecto de software. Este acuerdo son los requerimientos del sistemaalojados al software." … ". Este acuerdo cubre requerimientos técnicos y notécnicos (como fechas de entrega). El acuerdo forma las bases paraestimar, planear, ejecutar y monitorear el proyecto de desarrollo desoftware a través de todo su ciclo de vida." … "Bajo las restricciones delproyecto, el grupo de manejo de requerimientos toma las medidasnecesarias para que los requerimientos que están bajo su responsabilidadestén documentados y controlados"¿De que manera podemos controlar los requerimientos de software si estossiempre evolucionan con el tiempo?. El CMM nos proporciona las guíaspara lograrlo."Para lograr el control de los requerimientos, el grupo de requerimientosrevisa los requerimientos antes de que estos sean incorporados al proyectode software y cada vez que los requerimientos cambian los planes,productos, y actividades son ajustadas para quedar en línea con los nuevosrequerimientos de software".En otras palabras, para obtener el nivel que requiere el CMM en manejo derequerimientos débenos de tomar en cuenta dos cosas.• Que los requerimientos deben de ser revisados (y aprobados) por elgrupo de requerimientos, y no son impuestos por en su totalidad porpresiones externas ajenas al proyecto.El requerimiento técnico podrá ser impuesto por el mercado o presiones dela competencia, pero entonces los requerimientos no técnicos (Calidad,Costo y Tiempo de entrega) deberán estar especificados de comúnacuerdo con el grupo de requerimientos del proyecto de software.• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, sicambia uno forzosamente deberán cambiar los demás. Esto es: máscontenido técnico implica o más costo, o menos calidad o más tiempo
  20. 20. estimado de entrega. De modo que los cambios técnicos deberán seraprobados por el grupo de requerimientos y este grupo estimará losimpactos en tiempo, costo, calidad. El resultado de la estimación es laentrada a los líderes del proyecto para decidir si el cambio se acepta o no.* ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO *Para prosperar en el mercado, cualquier producto debe satisfacer lasnecesidades de los usuarios, lo cual no resulta posible si no integra y poneal alcance del consumidor de forma comprensible los fundamentos detodos los aspectos del desarrollo. Para captar las necesidades específicasde los usuarios es indispensable que los documentos que recogen losrequerimientos se redacten utilizando métodos pragmáticos.Se debe utilizar una metodología detallada de definición de losrequerimientos de usuario. Organizar entrevistas destinadas a obtener lamáxima información posible acerca de los requerimientos de los usuarios.Traducir las oportunidades / necesidades en requerimientos del proyecto.Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crearun documento de requerimientos generales. Conseguir la participación yconfirmación del usuario.Los gerentes y usuarios del sistema también poseen un papel importanteen le diseño del sistema; no es solamente el proyecto del analista. Duranteel diseño, a algunos se les pide que revisen los borradores de los informes,que examinen los formatos de entrada y que ayuden en la escritura de losprocedimientos para decirles a otras personas como utilizar el sistema enforma apropiada.La participación del usuario proporciona al analista una retroalimentaciónimportante conforme avanza en el diseño; además asegura a los usuariostengan un conocimiento no técnico de lo realizara o no el nuevo sistema.
  21. 21. Esta visión general del diseño de sistemas subraya los aspectos de diseñoque se verán mas adelante en el diseño de la salida de sistema.* REQUERIMIENTOS DEL SISTEMA *Los Sistemas de Información por computadora normalmente estánintegrados por muchos componentes. En la mayor parte de los casos, esdifícil para los analistas entender todos estos componentes aún mismotiempo; por lo tanto los investigadores tienen que comenzar con preguntasde tipo general con relación al propósito del sistema sus entradas y salidasde los procesos incluidos.En los grandes proyectos de sistema varios analistas llevan a cabo unainvestigación en forma seccionada que la distribuye entre ellos mismos, demanera que cada uno pueda trabajar en forma independiente.Existen dos estrategias ampliamente utilizadas para determinar losrequerimientos de información. Se clasifican en dos tipos:1.- Flujo de Datos.2.- Estrategias de Análisis de Decisión para el Conocimiento para losSistema de Información.* Estrategia del Flujo de Datos *Cuando se siguen un flujo a través de los procesos de negocio, que es elpropósito del análisis del flujo de datos, le indica a los analistas una grancantidad de datos sobre como sé esta llevando a cabo los objetivos de lacompañía. Al manejar las transacciones y completar las tareas, los datos
  22. 22. de entrada se procesan, almacenan, consultan, utiliza, modifica y seemiten.El análisis de flujo de datos que muestra el estudio y el uso de cadaactividad, documenta los hallazgos en los diagramas de flujo de datos.* Estrategia del Análisis de Decisiones *La estrategia del análisis de decisiones es un complemento del análisis delflujo de datos. Esta estrategia realza el estudio de los objetivos de unaoperación y de las decisiones que deben realizarse para cumplir con losobjetivos.Las decisiones se presentan tanto en los niveles operativos como en los dealto nivel gerencial, la estrategia de análisis de decisión con frecuenciautiliza por parte de alta gerencia para desarrollar la toma de decisiones.La alternativa que selecciona los gerentes responsables en la toma dedecisiones, en cuanto a una estrategia de precios entre un conjunto dealternativas, se maneja de forma diferente a la opción que toma unsupervisor de departamento para aceptar o rechazar pedidos.La decisión de rechazar pedidos generalmente ocurre con más frecuencia,de manera que las condiciones y acciones normalmente se conocen comoun aspecto importante.* Etapas en la Estrategia del Análisis del Flujo de Datos *1. - Estudiar las operaciones y procesos en marcha.2. - Identificar cómo se procesan los datos al manejar transacciones yterminar las tareas.
  23. 23. 3. - Seguir el flujo de datos:* Proceso* Almacenamiento* Recuperación* Salida4. - Añadir gradualmente detalles a los niveles inferiores.Etapas en la Estrategia del Análisis de Decisión1. -Estudiar los objetivos y decisiones necesarias.2. - Desarrollar un modelo del proceso de decisión.3. - Probar el modelo con datos de prueba.4. - Identificar los requerimientos del proceso para los datos.* Requerimientos De Entrada *Es el enlace que une al sistema de información con el mundo y sus
  24. 24. usuarios, en esta existen aspectos generales que todos los analistas debentener en cuenta estos son:• Objetivos del Diseño de Entrada.• Captura de Datos para la Entrada.Objetivo del Diseño de EntradaConsiste en el desarrollo de especificaciones y procedimientos para lapreparación de datos, la realización de los procesos necesarios para ponerlos datos de transacción en una forma utilizable para su procesamiento asícomo la entrada de los datos se logra al instruir a la computadora para quelea ya sea documentos escritos, impresos ó por personas que los escribendirectamente al sistema.Existen cinco objetivos que controlan la cantidad de entrada requerida, aenviar los retrasos, controlar los errores y mantener la sencillez de lospasos necesarios, estos son:• Control de la Calidad de Entrada• Evitar los Retrasos• Evitar los errores en los datos• Evitar los pasos adicionales
  25. 25. • Mantener la Sencillez del ProcesoControl de la Calidad de Entrada:Existen varias razones por las cuales un buen diseñador debe controlar lacantidad de datos en la entrada:- Las Operaciones de preparación y entrada dependen de las personasdado que los costos de mano de obra son altos y la preparación de ingresode los datos también lo son.-La fase de entrada puede ser un proceso lento que toma mucho mástiempo que el que necesitan las computadoras para realizar sus tareas.Evitar los Retrasos:También conocido con el nombre de cuello de botella son siempre uno delos objetivos que el analista evita al diseñar la entrada, una forma deevitarle es utilizar los documentos de retorno.Evitar los errores en los datos:La tasa de errores depende de la cantidad de datos, ya que entre máspequeña sea esta menores serán las oportunidades para cometer errores.Es común encontrar en las operaciones de ventas por lo menos un 3% deerrores en las operaciones de entrada de datos.
  26. 26. Evitar los Pasos Adicionales:Algunas veces el volumen de transacciones y la cantidad de datos enpreparación es algo que no se puede controlar por ello el analistaexperimentado, evitara diseños para la entrada que traigan una mayorcantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando sealimenta un proceso muchas veces al transcurso de un día.Mantener la sencillez del Proceso:El sistema mejor diseñado se ajusta a las personas que lo utilizarán y almismo tiempo proporcionarán métodos para el control de los errores, lasimplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajoque los usuarios acepten sistemas complejos o confusos y que no existaninguna garantía para el éxito al instalar un sistema complejo y quedomine.Captura de Datos para la Entrada:En una transacción existen datos importantes y otros que no, el analistadebe saber cuáles utilizará y cuales en realidad deben formar la entrada.Existen dos tipos de datos:• Datos variables• Datos de identificaciónDatos Variables:
  27. 27. Son aquellos que cambian para cada transacción o toman de decisión.Datos de Identificación:Estos son los que identifican en forma única el artículo que esta siendoprocesado.* Requerimientos De Salida *Niveles de diseñoEl diseño de sistema se representa a través de dos fases: el diseño lógico yel diseño físico.Cuando los analistas formulan un diseño lógico; escriben lasespecificaciones detalladas del nuevo sistema; esto es, describen suscaracterísticas: las salidas, entradas, archivos y bases de datos yprocedimientos; todos de manera que cubran los requerimientos delproyecto.El diseño lógico de un sistema de información es como el plano de uningeniero para armar un automóvil: muestra las característicasprincipales(motor, transmisión y área para los pasajeros)y como serelacionan unas con otras(donde se conectan entre sí los componentes delsistema, o por ejemplo, cuan separadas están las puertas.Los informes y la producción del analista son los componentes de todo elmecanismo que emplea el ingeniero. Los datos y procedimientos se ligan yentonces se produce un sistema que trabaje.El diseño lógico también especifica las formas de entrada y lasdescripciones de las pantallas de todas las transacciones y archivos a finde mantener los datos de inventario, los detalles de las transacciones y los
  28. 28. datos del proveedor. Las especificaciones de los procedimientos describenmétodos para introducir los datos, corridas de informes copiados dearchivos y detección de problemas.El diseño físico, actividad que sigue el diseño lógico, produce programas desoftware, archivos y un sistema en marcha, las especificaciones del diseñoindican a los programadores que debe hacer el sistema. Losprogramadores a su vez escriben los programas que aceptan entradas porparte de los usuarios, procesan los datos, producen los informes yalmacenan estos datos en los archivos.Utilización de los Datos de Requerimientos:El alcance del diseño de sistemas se guía por el marco de referencia parael nuevo sistema desarrollado durante el análisis. Los datos de losrequerimientos, recopilados durante la investigación, conforman lasactividades y componentes del sistema. Los analistas formulan un diseñológico que apoya los procesos y decisiones, los contenidos del sistemapueden cambiar como resultado de un nuevo diseño.El diseño lógico va de arriba hacia abajo, como lo hizo la determinación derequerimientos.En primer lugar se identifican las características generales, como informesy entradas; en el diseño de la salida por ejemplo, los analistas debenconocer la longitud de campo de un dato específico para establecer cuantoespacio dejar en la información, en la pantalla de despliegue visual oarchivo.A lo largo de los años hemos visto una evolución de ideas y técnicas en elcampo del análisis de sistemas. La cual cabe en tres períodos ampliossegún Yourdon:1. El análisis de sistema convencional, anterior a los años 70´s,
  29. 29. caracterizado por especificaciones tipo novela victoriana que eran difícilesde leer y entender, y casi imposibles de mantener.2. El análisis estructurado clásico, de mediados de los años 70´s, amediados de los años 80´s. Esto se caracterizó por primeras versiones demodelos gráficos, y énfasis en el modelado de las implementacionesactuales de un sistema antes de modelar el nuevo.3. El análisis estructurado moderno, en el cual se introducen mejoras sobretodo para modelar sistemas de tiempo real y relaciones de situacionescomplejas. Aumentando por ende la comunicación entre el analista y elsistema.En la actualidad las técnicas modernas están siendo fusionadas, para asílograr un mejor método que pueda hacerle frente a las necesidades de lasdiferentes fases del ciclo de vida del sistema, incluyendo a la fase deanálisis. Obteniendo de está manera mejores resultados que puedainterpretar el analista en forma rápida y precisa.En primera instancia debemos decir que el análisis estructurado segúnSenn "permite al analista conocer un sistema o proceso (actividad) en unaforma lógica y manejable al mismo tiempo que proporciona la base paraasegurar que no se omite ningún detalle pertinente". El objetivo quepersigue el análisis estructurado es organizar las tareas asociadas con ladeterminación de requerimientos para obtener la comprensión completa yexacta de una situación dada. Se puede decir adicionalmente que loscomponentes del análisis estructurado son los siguientes: símbolosgráficos, diccionarios de datos, descripciones de procesos yprocedimientos, reglas.Después de relacionarnos brevemente con la terminología básica,podemos entrar en aspectos relacionados con los cambios del análisisestructurado.
  30. 30. Podemos decir que para finales de los años 60´s e inicios de los 70´s elanálisis estructurado surge de la necesidad de buscar una formainterpretativa más rápida y eficiente, de tal manera que se pudiesen definirlos requerimientos del usuario y las especificaciones funcionales delsistema. Pero esto no se daba porque lo que existía eran grandesvolúmenes de información que había que leer por completo y queacarreaban una serie de problemas de: monolitismo, redundancia,ambigüedad e imposibilidad de mantener. Es por ello que surge una ampliavariedad de diagramas que permiten representar las especificacionesfuncionales en forma sencilla y rápida, aumentando por ende el grado decomunicación entre las especificaciones funcionales y el usuario final(analista, programador, diseñador).Posteriormente, a mediados de los años 70´s estando el análisisestructurado clásico en su apogeo aparecen una serie de dificultades quelimitan al analista hacer un buen desempeño de sus actividades. Entreestos problemas según Yourdon podemos mencionar:• Distinción difusa y poca, definida entre los modelos lógicos y los modelosfísicos.• Limitación para modelar sistemas en tiempo real.• El modelo de datos se hacía de una manera primitiva.Estas y otras razones dieron nacimiento a ciertas mejoras en el análisisestructurado clásico tales como: diagramas de entidad-relación, diagramasde transición de estados, división de eventos, modelos esenciales ymodelos de implantación. Pero a pesar de esto según Yourdon se siguierondando más problemas como los siguientes:
  31. 31. • Tras la segunda y tercera correcciones de un diagrama, el analista sevolvía cada vez más apuesto y renuente a hacer más cambios.• Debido a la cantidad de trabajo requerido, el analista dejaba a veces dedividir el modelo del sistema en modelos de menor nivel, quedando porende, funciones primitivas.• A menudo no se incorporaban en el modelo del sistema los cambios enlos requerimientos del usuario sino hasta después de la fase de análisis delproyecto.Inclusive las correcciones de los diagramas había que hacerlas en formamanual, para asegurar que fuesen consistentes y estuviesen completas; locual era bastante tedioso y dejaba por fuera muchos errores que debían deencontrarse. Pero para mediados de los 80´s aparecieron las herramientasCASE que trataron de subsanar estos problemas. Las herramientas CASE(Ingeniería de software auxiliada por computadora) se utilizan para dibujardiagramas de flujo de datos y otros además de llevar a cabo una variedadde labores de revisión de errores.Finalmente, algunos usuarios tenían dificultades al tratar con los modelosgráficos del análisis estructurado y preferían alguna otra forma de modelarlos requerimientos y comportamiento del sistema; es por ello que aparecenlas herramientas de generación de prototipos (mediados de los 80´s) queson considerados como una alternativa al análisis estructurado para talesusuarios. También se utiliza para recordar en forma breve y precisa lo quese ha hecho a lo largo de todo el desarrollo del sistema, para no perder lasecuencia de lo que se está realizando.En la actualidad muchas de estas herramientas se están utilizando parafacilitar la fase de análisis, e inclusive se están elaborando o fusionando lomejor de cada una de las técnicas que atienden las necesidades de todaslas fases del ciclo de vida del sistema; para así obtener un mejor
  32. 32. aprovechamiento, entendimiento, y rendimiento al momento que se pongaa correr el sistema. Disminuyendo de esta manera la serie de errores quese cometían anteriormente, con la introducción de herramientas másespecializadas y fáciles de utilizar.Diversos aspectos del análisis estructurado han cambiado gradualmente alo largo de los últimos años. Las principales áreas de cambio incluyen losiguiente según Yourdon:• Cambios de terminología.• Partición de acontecimientos.• La desenfatización del modelado físico actual.• Herramientas de modelado en tiempo real.• Integración más cercana del modelado de procesos y datos.En un futuro no muy lejano se piensa que se darán, si es que ya no seestán dando, los siguientes cambios o pautas en el ámbito total en lo quese refiere a análisis según Yourdon:• Mayor difusión del análisis de sistemas, sobre todo en los siguientesgrupos: los niveles superiores de administración en organizacionesgubernamentales y de negocios, los niños, y profesionales de lacomputación en los países del tercer mundo.• Impacto sobre la industria de software del tercer mundo.
  33. 33. • Proliferación de las herramientas automatizadas, aunque no todos losanalistas tienen acceso a las últimas herramientas de análisis.• Impacto de los desastres de mantenimiento.• Integración del análisis estructurado con la inteligencia artificial.Podemos adicionar que el futuro del análisis estructurado va a dependermucho también de que tan rápido pueda ajustarse el mismo a los cambiostecnológicos que se viven hoy en día. Debido a que han estado surgiendootras técnicas en otras áreas como lo es la orientada a objetos, la cualprevé un buen futuro y muchas mejoras para los sistemas actuales.* DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE*Fue la aparición del diseño y la programación estructurada alrededor de losaños 60´s la que dieron cabida al surgimiento del análisis estructurado, yaque existía la necesidad de utilizar una notación gráfica para representarlos datos y los procesos que los transforman". Es por ello que surgen unaserie de temas afines tales como: herramientas automatizadas (CASE),prototipos, diagramas de entidad-relación etc.Índice de Términos relacionados: CASE (Ingeniería de Software auxiliadapor computadora), elaboración de prototipos, símbolos gráficos,diccionarios de datos, descripciones de procesos y procedimientos, reglas,diagramas de estados, diagramas de entidad-relación, diagramas detransición de eventos, división de eventos, modelos esenciales y modelosde implantación.
  34. 34. * Métodos de Análisis Orientados al Flujo de Datos *La información se transforma como un flujo a través de un sistema basadoen computadora. El sistema acepta entrada de distintas formas; aplica unhardware, software y elementos humanos para transformar la entrada ensalida; y produce una salida en distintas formas. La entrada puede ser unaseñal de control transmitida por un transductor, una serie de númerosescritos por un operador humano, un paquete de información transmitidopor un enlace a red, o un voluminoso archivo de datos almacenado enmemoria secundaria. La transformación puede comprender una sencillacomparación lógica, un complejo algoritmo numérico, o un método deinferencia basado en regla de un sistema experto. La salida puedeencender un sencillo led o producir un informe de 200 páginas. En efecto,un modelo de flujo de datos puede aplicarse a cualquier sistema basado encomputadora independientemente del tamaño o complejidad.La función global del sistema se representa como una transformaciónsencilla de la información, representada en la figura como una burbuja. Unao más entradas. Representadas como flechas con etiqueta, conducen latransformación para producir la información de salida. Puede observarseque el modelo puede aplicarse a todo el sistema o solo a un elemento desoftware. La clave es representar la información dada y producida por latransformación.* Diagramas de Flujos de Datos *Conforme con la información se mueve a través del software, se modificamediante una serie de transformaciones. Un diagrama de flujos de datos
  35. 35. (DFD), es una técnica grafica que describe el flujo de información y lastransformaciones que se aplican a los datos, conforme se mueven de laentrada a la salida. El diagrama es similar en la forma a otros diagramas deflujo de actividades, y ha sido incorporado en técnicas de análisis y diseñospropuesto por Yourdon y Constantine, DeMarco y Gane y Sarson. Tambiénse le conoce como un grafo de flujo de datos o un diagrama de burbujas.* Diccionario de Datos *Un análisis del dominio de la información puede ser incompleto si solo seconsidera el flujo de datos. Cada flecha de un diagrama de flujo de datosrepresenta uno o más elementos de información. Por tanto, el analista debedisponer de algún otro método para representar el contenido de cadaflecha de un DFD.Se ha propuesto el diccionario de datos como una gramática casi formalpara describir el contenido de los elementos de información y ha sidodefinido da la siguiente forma:El diccionario de datos contiene las definiciones de todos los datosmencionados en el DFD, en una especificación del proceso y en el propiodiccionario de datos. Los datos compuestos (datos que pueden ser ademásdivididos) se definen en términos de sus componentes; los datoselementales (datos que no pueden ser divididos) se definen en términos delsignificado de cada uno de los valores que puede asumir. Por tanto, eldiccionario de datos esta compuesto de definiciones de flujo de datos,archivos [datos almacenados] y datos usados en los procesos[transformaciones]...* Descripciones Funcionales *
  36. 36. Una vez que ha sido representado el dominio de la información (usando unDFD y un diccionario de datos), el analista describe cada función(transformación) representada, usando el lenguaje natural o alguna otranotación estilizada. Una de tales notaciones se llama ingles estructurado(también llamado lenguaje de diseño del programa o proceso (LDP)). Elinglés estructurado incorpora construcciones procedimentales básicas –secuencia, selección y repetición- junto con frases del lenguaje natural, deforma que pueden desarrollarse descripciones procedimentales precisas delas funciones representadas dentro de un DFD.* Métodos Orientados a la Estructura de Datos *Hemos ya observado que el dominio de la información para un problema desoftware comprende el flujo de datos, el contenido de datos y la estructurade datos. Los métodos de análisis orientados a la estructura de datosrepresentan los requerimientos del software enfocándose hacia laestructura de datos en vez de al flujo de datos. Aunque cada métodoorientado a la estructura de datos tiene un enfoque y notación distinta,todos tienen algunas características en común: 1) todos asisten al analistaen la identificación de los objetos de información clave (también llamadosentidades o ítems) y operaciones (también llamadas acciones o procesos);2)todos suponen que la estructura de la información es jerárquica; 3)todosrequiere que la estructura de datos se represente usando la secuencia,selección y repetición; y 4) todos dan una conjunto de pasos paratransformar una estructura de datos jerárquica en una estructura deprograma.Como los métodos orientados al flujo de datos, los métodos de análisisorientados a la estructura de datos proporcionan la base para el diseño desoftware. Siempre puede extenderse un método de análisis para queabarque el diseño arquitectural y procedimental del software.
  37. 37. BIBLIOGRAFÍASenn, James A. "Análisis y Diseño de Sistemas de Información". SegundaEdición. McGraw Hill. 1992.JAMES A SENN, Análisis y Diseño de Sistema de Información, Mc Graw Hill,Enero 1990JAMES A. SENN, Análisis y Diseño de Sistemas de Información, SegundaEdición, Mc Graw Hill, Abril 2000.IEEE Task Force on Requirements Engineering. Software EngineeringResources by Roger S. Pressman & AssociatesEdward - Yourdon (1993) - Análisis Estructurado Moderno, Prentice HallHispanoamericana, S. A., pp. 136-147, 500-511.Roger - S. P. (1993) - Ingeniería del Software, Mc. Graw-Hill, pp. 217-218, 247.Pressman, R.S., "Ingeniería del Software. Un enfoque práctico.", McGraw-Hill.Larman, C. "UML y patrones: Introducción al análisis y diseño orientado aobjetos". Prentice halll

×