Proyecto
Upcoming SlideShare
Loading in...5
×
 

Proyecto

on

  • 1,131 views

klcvjisdfhsdjhjsfhjskfd

klcvjisdfhsdjhjsfhjskfd

Statistics

Views

Total Views
1,131
Views on SlideShare
1,131
Embed Views
0

Actions

Likes
1
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Proyecto Proyecto Document Transcript

  • Paginas http://lsi.ugr.es/~mvega/docis/requeintro.pdfEl Desarrollo de Software Basado en Componentes en mi criterio tiene muchas ventajas,una de las principales se basa en la reutilización de componentes, de esta manera, loscomponentes se los diseña con el objetivo de poder ser reutilizados en otros proyectos,favoreciendo a la necesidad de realizar software complejo en cortos periodos de tiempo ya la vez con un menor esfuerzo en la realización del mismo, los costos son mucho menoresque desarrollar un software desde cero, la reutilización de código previamente realizado yprobado nos facilita el trabajo, mejorando la fiabilidad del producto final.Estos componentes de software ya desarrollados, son combinados adecuadamente paraobtener un producto final de buena calidad, pues dado que un componente puede serconstruido y luego mejorado continuamente, la calidad de un software basado encomponentes mejorará con el tiempo, para esto hay que realizar una precisa búsqueda yselección de componentes apropiados que se emplearán en el desarrollo del software.Con esto hay que tener especial cuidado pues si al ensamblar los distintos componentesuno de ellos no es confiable, el software en cuestión tendría fallas. En resumen elDesarrollo de Software Basado en Componentes, como ventajas podría decir que nosahorra tiempo por la reutilización de componentes, esfuerzo, dinero, y ademásobtenemos un software de buena calidad..INTRODUCCIÓNEl proceso de industrialización del software, exige que los ingenieros y técnicos planteennuevas alternativas para incrementar la productividad de los desarrolladores y analistasen el desarrollo de sistemas de software.En este contexto, el estudio evalúa la productividad de un desarrollador realizando unacomparación entre un sistema desarrollado reutilizando software, y otro sin reutilizaciónde software. Para ello, en la evaluación se utiliza el Método Aproximativo de Costo yProductividad (COCOMO)REUTILIZACIÓN DE SOFTWAREMientras que los usuarios demandan mayor complejidad y funcionalidad de los sistemasde software; los desarrolladores por su parte, tienen que manejar la complejidad propiade la lógica de negocios, así como la complejidad de la herramienta de programación, conlos limitados recursos económicos y de tiempo. En este escenario, la reutilización desoftware, se constituye como una de las mejores opciones para disminuir los plazos deentrega.
  • Existen diferentes técnicas de reutilización sistemática de software (4), dentro delesquema de la programación orientada a objetos (POO) uno de ellos es la reutilización decomponentes, a través de la creación de clases abstractas, e interfases.El arquitecto Alexander Christopher, de la Universidad de Oxford, fue quien proporcionóel fundamento teórico que posteriormente consolidó la reutilización de software, pormedio de 2 libros publicados en 1977: "A Pattern Language y A Timeless way of Building".Alexander; se refería a construcciones urbanas, alienándolo en estructuras recurrentes alas que denominó patrones(1).Los continuos avances en la Inform´atica y las Telecomunicaciones estan haciendocambiar la forma enla que se desarrollan actualmente las aplicaciones software. Enparticular, el incesante aumento de la potencia de los ordenadores personales, elabaratamiento de los costes del hardware y las comunicaciones, y la aparici´on de redesde datos de cobertura global han disparado el uso de los sistemas abiertos y distribuidos.Esto ha provocado, entre otras cosas, que los modelos de programaci´on existentes sevean desbordados, siendo incapaces de manejar de forma natural la complejidad de losrequisitos que se les exigen para ese tipo de sistemas. Comienzan a aparecer por tantonuevos paradigmas de programaci´on, como pueden ser la coordinaci´on, laprogramaci´on orientada a componentes, o la movilidad, que persiguen una mejora en losprocesos de construcci´on de aplicaciones software. En ellos se trabaja tanto enextensiones de los modelos existentes como en nuevos modelos, en la estandarizaci´on desus interfaces y servicios, y la pertinaz b´usqueda del cada vez m´as necesario mercadoglobal de componentes software.Estos son parte de los nuevos retos con los que se enfrenta actualmente la ingenier´ıa delsoftware.Uno de los enfoques en los que actualmente se trabaja constituye lo que se conoce comoDesarrollo de Software Basado en Componentes (DSBC), que trata de sentar las bases parael dise˜no y desarrollo de aplicaciones distribuidas basadas en componentes softwarereutilizables. Dicha disciplina cuenta actualmente con un creciente inter´es, tanto desde elpunto de vista acad´emico como desde el industrial, en donde la demanda de estos temases cada d´ıa mayor.La presente lecci´on pretende servir como una breve introducci´on a algunos de losconceptos y m´etodos fundamentales sobre los que se apoya el DSBC. En particular, noscentraremos en las arquitecturas software y los marcos de trabajo, la programaci´onorientada a componentes, y en las plataformas de componentes distribuidas. Asimismo,discutiremos sobre lo que deber´ıa constituir una metodolog´ıa para el DSBC. Porsupuesto, a´un queda mucho trabajo por hacer para poder hablar realmente de unaIngenier´ıa del Software Basada en Componentes, pero sin duda las bases se est´ansentando para hacer de esta disciplina una realidad en un futuro cercano.
  • INTRODUCCION¿Qué son Requerimientos?Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchasdefiniciones que existen para requerimiento, ha continuación se presenta la definición queaparece en el glosario de la IEEE .(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.(2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistemapara satisfacer un contrato, estándar, especificación u otro documento formal. (3) Unarepresentación documentada de una condición o capacidad como en (1) o (2).Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos nofuncionales. Los requerimientos funcionales definen las funciones que el sistema será capaz derealizar. Describen las transformaciones que el sistema realiza sobre las entradas para producirsalidas.Los requerimientos no funcionales tienen que ver con características que de una u otra formapuedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces deusuario, 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. Un conjunto derequerimientos en estado de madurez, deben presentar una serie de características tantoindividualmente como en grupo. A continuación se presentan las más importantes.Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema aconstruir, y además su capacidad, características físicas o factor de calidad no pueden serreemplazados por otras capacidades del producto o del proceso.Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple yclara para aquellos que vayan a consultarlo en un futuro.Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, esdecir, si se proporciona la información suficiente para su comprensión.Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera quepermita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración opruebas.* 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ás importantes o más establesque otros.• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partesdel proceso.• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cadaproyecto.* Ingeniería de Requerimientos vs. Administración de Requerimientos *El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamadoIngeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar unaespecificación de requisitos de software correcta y completa.Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos sebasan muchos participantes del proyecto para:Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan losrequerimientos como una base para la estimación del esfuerzo necesario en un proyecto.Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando seesta tratando de alinearse a cierta norma oficial o estándar.Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos sonla base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema ono.Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la basepara crear la documentación del sistemaDe ahí su importancia y la importancia de que deban de ser definidos y manejados de la formamas adecuada posible.Características de un requerimientoYa que visualizamos la importancia de los requerimientos en un sistema de software entoncesdebemos de definir que características deben de poseer los requerimientos adecuadamenteformulados.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, entonces ¿cómosabemos si cumplimos con él o no?Descritos como una característica del sistema a entregar. Esto es: que es lo que el sistema debe dehacer (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 permiten conocer los elementosnecesarios 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 usuario para resolver unproblema o alcanzar un objetivo.No Funcionales: Condición o capacidad que debe poseer un sistema par satisfacer un contrato, unestándar, una especificación u otro documento formalmente impuesto.Para realizar bien el desarrollo de software es esencial realizar una especificación completa de losrequerimientos de los mismos. Independientemente de lo bien diseñado o codificado que esté, unprograma pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, Elámbito del programa, establecido inicialmente durante la ingeniería del sistema, es refinado endetalle. Se analizan y asignan a los distintos elementos de los programas las solucionesalternativas.Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación derequerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la función ycomportamiento de los programas en detalles concretos, El que desarrolla el software actúa comointerrogador, consultor y el que resuelve los problemas.El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla,pero las apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan loscambios por mala interpretación o falta de información. El dilema con el que se enfrenta uningeniero de software puede ser comprendido repitiendo la sentencia de un cliente anónimo: "Séque crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creísteoír sea lo que yo quise decir".Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos ydetallados, y además contienen múltiples relaciones entre sí. Lo que nos da a concluir, que elconjunto de requerimientos de un sistema computacional es complejo.Obtenemos la posibilidad de especificar sistemas complejos al documentar especificacionessimples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y organizartodo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos.El análisis de requerimientos es la tarea que plantea la asignación de software a nivel de sistema yel diseño de programas. El análisis de requerimientos facilita al ingeniero de sistemas especificarla función y comportamiento de los programas, indicar la interfaz con otros elementos delsistema y establecer las ligaduras de diseño que debe cumplir el programa. El análisis derequerimientos permite al ingeniero refinar la asignación de software y representar el dominio dela información que será tratada por el programa. El análisis de requerimientos de al diseñador larepresentación de la información y las funciones que pueden ser traducidas en datos, arquitecturay 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 problema2.- Evaluación y síntesis3.- Especificación4.- 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 lacomunicación necesaria para el análisis, de forma que se asegure el reconocimiento delproblema.El analista debe establecer contacto con el equipo técnico y de gestión del usuario / cliente y conla empresa que vaya a desarrollar el software. El gestor del programa puede servir comocoordinador para facilitar el establecimiento de los caminos de comunicación. El objetivo delanalista es reconocer los elementos básicos del programa tal como lo percibe el usuario / cliente.La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo delanálisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todaslas funciones del programa, establecer las características de la interfase del sistema y descubrirlas ligaduras del diseño, Cada una de las tareas sirven para descubrir el problema de forma quepueda sintetizarse un enfoque o solución global.Las tareas asociadas con el análisis y especificación existen para dar una representación delprograma que pueda ser revisada y aprobada por el cliente. En un mundo ideal el clientedesarrolla una especificación de requerimientos del software completamente por sí mismo. Estose presenta raramente en el mundo real. En el mejor de los casos, la especificación se desarrollaconjuntamente entre el cliente y el técnico.Una vez que se hayan descrito las funcionalidades básicas, comportamiento, interfase einformación, se especifican los criterios de validación para demostrar una comprensión de unacorrecta implementación de los programas. Estos criterios sirven como base para hacer unaprueba durante el desarrollo de los programas. Para definir las características y atributos delsoftware se escribe una especificación de requerimientos formal. Además, para los casos en losque se desarrolle un prototipo se realiza un manual de usuario preliminar.Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana del procesode desarrollo, Pero de hecho, este borrador del manual de usuario fuerza al analista a tomar elpunto de vista del usuario del software. El manual permite al usuario / cliente revisar el softwaredesde una perspectiva de ingeniería humana y frecuentemente produce el comentario: "La idea escorrecta pero esta no es la forma en que pensé que se podría hacer esto". Es mejor descubrir talescomentarios lo más tempranamente posible en el proceso.Los documentos del análisis de requerimiento (especificación y manual de usuario) sirven comobase para una revisión conducida por el cliente y el técnico. La revisión de los requerimientos casisiempre produce modificaciones en la función, comportamiento, representación de lainformación, ligaduras o criterios de validación. Además, se realiza una nueva apreciación delplan del proyecto de software para determinar si las primeras estimaciones siguen siendo validasdespués del conocimiento adicional obtenido durante el análisis.* Obteniendo de la información *Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo desoftware, este entendimiento es necesario para poder construir software que satisfaga lasnecesidades 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 de primera mano. Esto es, mediante entrevistascon el cliente o recabando documentación que describa la manera que el cliente desea quefuncione el sistema de software.Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambioinvolucra un costo. Por eso es necesario tener archivada una copia de la documentación originaldel cliente, así como cada revisión o cambio que se haga a esta documentación. Como cadanecesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades parasaber cuales de ellas serán satisfechas por el software y cuales por algún otro producto delsistema.* Especificación de Requisitos de Software *(SRS)La especificación de requisitos de software es la actividad en la cual se genera el documento, conel mismo nombre, que contiene una descripción completa de las necesidades y funcionalidadesdel sistema que será desarrollado; describe el alcance del sistema y la forma en como hará susfunciones, definiendo los requerimientos funcionales y los no funcionales.En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos desistemas y cualquier otra información que sirva de soporte y guía para fases posteriores.Es importante destacar que la especificación de requisitos es el resultado final de las actividadesde análisis y evaluación de requerimientos; este documento resultante será utilizado como fuentebásica de comunicación entre 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 conlas necesidades de la empresa. Los analistas y programadores la utilizan para determinar elproducto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y desistemas en base a este documento. Para el administrador del proyecto sirve como referencia ycontrol 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 dela SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para queuna SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; paraque una SRS se considere modificable, cada requerimiento debe ser modificable y asísucesivamente. Las 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 otras cosas, a facilitar la lecturay escritura de la misma. Será un documento familiar para todos los involucrados, además deasegurar que se cubren todos los tópicos importantes.Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propiaplantilla.Clasificación de los requerimientosEl clasificar requerimientos es una forma de organizarlos, hay requerimientos que por suscaracterísticas no pueden ser tratados iguales.La siguiente es una recomendación de como pueden ser clasificados los requerimientos aunquecada proyecto de software pueda usar sus propias clasificaciones.• Requerimientos del "entorno"El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto
  • tipo de requerimientos que se clasifican en esta categoría por que:El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para quefuncione. 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 en el entorno, tales comocongestión en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe deconsiderar dentro de los requerimientos.• Requerimientos "ergonómicos"Él mas conocido de los requerimientos ergonómicos es la interfase con el usuario o GUI (GraphicUser Interface). En otras palabras, los requerimientos ergonómicos son la forma en que el serhumano interactúa con el ser sistema.• Requerimientos de InterfaseLa interfase es como interactúa el sistema con el ser humano o con otros sistemas (el enfoque esprácticamente el opuesto a los requerimientos ergonómicos), La interfase es la especificaciónformal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica elprotocolo, el tipo de información, el medio para comunicarse y el formato de los datos que se vana comunicar.* Actividades de la Ingeniería de Requerimientos *En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas,sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades sonaplicadas de manera continua y en orden variado.Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclode desarrollo, las actividades de la IR varían tanto en número como en nombres. La tabla #1muestra algunos ejemplos de las actividades identificadas para cada proceso.A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto deactividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividadesprincipales que son:• 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, puede ser vista como unproceso de representación. Los requerimientos se representan de forma que conduzcanfinalmente a una correcta implementación del software.Baltzer y Goldman proponen ocho principios para una buena especificación:PRINCIPIO #1. Separar funcionalidad de implementación.Primero, por definició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 formas muy diferentes. Laprimera forma es la de funciones matemáticas: dado algún conjunto de entrada, producir unconjunto particular de salida. La forma general de tales especificaciones es encontrar[un/el/todos] resultado tal que P (entrada), donde P representa un predicado arbitrario. En talesespecificaciones, el resultado a ser obtenido ha sido expresado enteramente en una forma sobre el
  • que (en vez de cómo). En parte, esto es debido a que el resultado es una función matemática de laentrada (la operación tiene puntos de comienzo y parada bien definidos) y no esta afectado por elentorno que le rodea.PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas orientado al proceso.Considerar una situación en la que el entorno sea dinámico y sus cambios afecten alcomportamiento de alguna entidad que interactúe con dicho entorno. Su comportamiento nopuede ser expresado como una función matemática de su entrada. En vez de ello, debe emplearseuna descripción orientada al proceso, en la cual la especificación del que se consigue mediante laespecificación de un modelo del comportamiento deseado en términos de respuestas funcionales,a distintos estímulos del entorno.PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el software es unacomponente.Un sistema esta compuesto de componentes que interactúan. Solo dentro del contexto delsistema completo y de la interacción entre sus partes puede ser definido el comportamiento deuna componente especifica. En general, un sistema puede ser modelado como una colección deobjetos pasivos y activos. Estos objetos están interrelacionados y dichas relaciones entre losobjetos cambian con el tiempo. Estas relaciones dinámicas suministran los estímulos a los cualeslos objetos activos, llamados agentes, responden. Las respuestas pueden causar posteriormentecambios y, por tanto, estímulos adicionales a los cuales los agentes deben responder.PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el sistema opera.Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser especificado.Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un sistemacompuesto de objetos que interactúan, pasivos y activos, de los cuales el sistema especificado esuna agente, Los otros agentes, los cuales son por definición inalterables debido a que son partedel entorno, limitan el ámbito del diseño subsecuente y de la implementación. De hecho, la únicadiferencia entre el sistema y su entorno es que el esfuerzo de diseño e implementaciónsubsecuente opera exclusivamente sobre la especificación del sistema. La especificación delentorno facilita que se especifique la interfaz del sistema de la misma forma que el propiosistema, en vez de introducir otro formalismo.PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo.La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo de diseño oimplementación. Debe describir un sistema tal como es percibido por su comunidad de usuario.Los objetivos que manipula deben corresponderse con objetos reales de dicho dominio; losagentes deben modelar los individuos, organizaciones y equipo de ese dominio; y las acciones queejecutan deben modelar lo que realmente ocurre en el dominio. Además, debe ser posibleincorporar en la especificación las reglas o leyes que gobiernan los objetos del dominio. Algunasde estas leyes proscriben ciertos estados del sistema (tal como "dos objetos no pueden estar en elmismo lugar al mismo tiempo"), y por tanto limitan el comportamiento de los agentes o indicanla necesidad de una posterior elaboración para prevenir que surjan estos estados.PRINCIPIO #6. Una especificación debe ser operacional.La especificación debe ser completa y lo bastante formal para que pueda usarse para determinarsi una implementación propuesta satisface la especificación de pruebas elegidas arbitrariamente.Esto es, dado el resultado de una implementación sobre algún conjunto arbitrario de datoselegibles, debe ser posible usar la especificación para validar estos resultados. Esto implica que laespecificación, aunque no sea una especificación completa del como, pueda actuar como ungenerador de posibles comportamientos, entre los que debe estar la implementación propuesta.Por tanto, en un sentido extenso, la especificación debe ser operacional.
  • PRINCIPIO #7. La especificación del sistema debe ser tolerante con la incompletitud yaumentable.Ninguna especificación puede ser siempre totalmente completa. El entorno en el que existe esdemasiado complejo para ello. Una especificación es siempre un modelo, una abstracción, dealguna situación real (o imaginada). Por tanto, será incompleta. Además, al ser formuladexistirán muchos niveles de detalle. La operacionalidad requerida anteriormente no necesita sercompleta. Las herramientas de análisis empleadas para ayudar a los especificadores y para probarlas especificaciones, deben ser capaces de tratar con la incompletitud. Naturalmente esto debilitael análisis, el cual puede ser ejecutado ampliando el rango de comportamiento aceptables, loscuales satisfacen la especificación, pero tal degradación debe reflejar los restantes niveles deincertidumbre.PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada.Los principios anteriores tratan con la especificación como una entidad estática. Esta surge de ladinámica de la especificación. Debe ser reconocido que aunque el principal propósito de unaespecificación sea servir como base para el diseño e implementación de algún sistema, no es unobjeto estático precompuesto, sino un objeto dinámico que sufre considerables modificaciones.Tales modificaciones se presentan en tres actividades principales: formulación, cuando se estácreando una especificación inicial; desarrollo, cuando la especificación se esta elaborandodurante el proceso iterativo de diseño e implementación; y mantenimiento, cuando laespecificación se cambia para reflejar un entorno modificado y / o requerimientos funcionalesadicionales.• Requerimientos funcionalesEstos son los que describen lo que el sistema debe de hacer. Es importante que se describa él¿Qué? Y no él ¿Cómo?. Estos requerimientos al tiempo que avanza el proyecto de software seconvierten en 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 que deben de tener elsistema. ¿Que tan rápido?, ¿Que tan seguido?, ¿Cuantos recursos?, ¿Cuantas transacciones?Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde eldesempeño de un sistema es tan crítico como su funcionamiento.• 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 tipo de requerimientos es también muyimportante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones críticasque no deben de estar fuera de servicio por periodos prolongados de tiempo.• EntrenamientoEste tipo de requerimientos se enfoca a las personas que van usar el sistema. ¿Que tipo deusuarios son?, ¿Que tipo de operadores?, ¿Que manuales se entregarán y en que idioma?Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de código dentro delsistema, son muy importantes en el proceso de diseño ya que facilitan la introducción yaceptación del sistema en donde será implementado.• Restricciones de diseñoMuchas veces las soluciones de un sistema de software son normadas por leyes o estándares, estetipo de normas caen como "restricciones de diseño".• MaterialesAquí se especifica en que medio se entregara el sistema y como esta empaquetado. Es importantepara definir los costos de industrialización del sistema.
  • * Manejo de requerimientos *De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos involucra:"Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto desoftware. Este acuerdo son los requerimientos del sistema alojados al software." … ". Este acuerdocubre requerimientos técnicos y no técnicos (como fechas de entrega). El acuerdo forma las basespara estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a través de todosu ciclo de vida." … "Bajo las restricciones del proyecto, el grupo de manejo de requerimientostoma las medidas necesarias para que los requerimientos que están bajo su responsabilidad esténdocumentados y controlados"¿De que manera podemos controlar los requerimientos de software si estos siempre evolucionancon el tiempo?. El CMM nos proporciona las guías para lograrlo."Para lograr el control de los requerimientos, el grupo de requerimientos revisa losrequerimientos antes de que estos sean incorporados al proyecto de software y cada vez que losrequerimientos cambian los planes, productos, y actividades son ajustadas para quedar en líneacon los nuevos requerimientos de software".En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientosdébenos de tomar en cuenta dos cosas.• Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos, yno son impuestos por en su totalidad por presiones externas ajenas al proyecto.El requerimiento técnico podrá ser impuesto por el mercado o presiones de la competencia, peroentonces los requerimientos no técnicos (Calidad, Costo y Tiempo de entrega) deberán estarespecificados de común acuerdo con el grupo de requerimientos del proyecto de software.• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si cambia unoforzosamente deberán cambiar los demás. Esto es: más contenido técnico implica o más costo, omenos calidad o más tiempo estimado de entrega. De modo que los cambios técnicos deberán seraprobados por el grupo de requerimientos y este grupo estimará los impactos en tiempo, costo,calidad. El resultado de la estimación es la entrada a los líderes del proyecto para decidir si elcambio se acepta o no.* ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO *Para prosperar en el mercado, cualquier producto debe satisfacer las necesidades de los usuarios,lo cual no resulta posible si no integra y pone al alcance del consumidor de forma comprensiblelos fundamentos de todos los aspectos del desarrollo. Para captar las necesidades específicas delos usuarios es indispensable que los documentos que recogen los requerimientos se redactenutilizando métodos pragmáticos.Se debe utilizar una metodología detallada de definición de los requerimientos de usuario.Organizar entrevistas destinadas a obtener la máxima información posible acerca de losrequerimientos de los usuarios. Traducir las oportunidades / necesidades en requerimientos delproyecto. Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear undocumento de requerimientos generales. Conseguir la participación y confirmación del usuario.Los gerentes y usuarios del sistema también poseen un papel importante en le diseño del sistema;no es solamente el proyecto del analista. Durante el diseño, a algunos se les pide que revisen losborradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura delos procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada.
  • La participación del usuario proporciona al analista una retroalimentación importante conformeavanza en el diseño; además asegura a los usuarios tengan un conocimiento no técnico de lorealizara o no el nuevo sistema.Esta visión general del diseño de sistemas subraya los aspectos de diseño que se verán masadelante en el diseño de la salida de sistema.* REQUERIMIENTOS DEL SISTEMA *Los Sistemas de Información por computadora normalmente están integrados por muchoscomponentes. En la mayor parte de los casos, es difícil para los analistas entender todos estoscomponentes aún mismo tiempo; por lo tanto los investigadores tienen que comenzar conpreguntas de tipo general con relación al propósito del sistema sus entradas y salidas de losprocesos incluidos.En los grandes proyectos de sistema varios analistas llevan a cabo una investigación en formaseccionada que la distribuye entre ellos mismos, de manera que cada uno pueda trabajar enforma independiente.Existen dos estrategias ampliamente utilizadas para determinar los requerimientos deinformación. Se clasifican en dos tipos:1.- Flujo de Datos.2.- Estrategias de Análisis de Decisión para el Conocimiento para los Sistema de Información.* Estrategia del Flujo de Datos *Cuando se siguen un flujo a través de los procesos de negocio, que es el propósito del análisis delflujo de datos, le indica a los analistas una gran cantidad de datos sobre como sé esta llevando acabo los objetivos de la compañía. Al manejar las transacciones y completar las tareas, los datosde entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten.El análisis de flujo de datos que muestra el estudio y el uso de cada actividad, documenta loshallazgos 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 del flujo de datos. Estaestrategia realza el estudio de los objetivos de una operación y de las decisiones que debenrealizarse para cumplir con los objetivos.Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial, laestrategia de análisis de decisión con frecuencia utiliza por parte de alta gerencia para desarrollarla toma de decisiones.La alternativa que selecciona los gerentes responsables en la toma de decisiones, en cuanto a unaestrategia de precios entre un conjunto de alternativas, se maneja de forma diferente a la opciónque toma un supervisor de departamento para aceptar o rechazar pedidos.La decisión de rechazar pedidos generalmente ocurre con más frecuencia, de manera que lascondiciones y acciones normalmente se conocen como un 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 y terminar las tareas.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 usuarios, en esta existenaspectos generales que todos los analistas deben tener 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 la preparación de datos, larealización de los procesos necesarios para poner los datos de transacción en una forma utilizablepara su procesamiento así como la entrada de los datos se logra al instruir a la computadora paraque lea ya sea documentos escritos, impresos ó por personas que los escriben directamente alsistema.Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos,controlar los errores y mantener la sencillez de los pasos necesarios, estos son:• Control de la Calidad de Entrada• Evitar los Retrasos• Evitar los errores en los datos• Evitar los pasos adicionales• Mantener la Sencillez del ProcesoControl de la Calidad de Entrada:Existen varias razones por las cuales un buen diseñador debe controlar la cantidad de datos en laentrada:- Las Operaciones de preparación y entrada dependen de las personas dado que los costos demano de obra son altos y la preparación de ingreso de los datos también lo son.-La fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitanlas computadoras para realizar sus tareas.Evitar los Retrasos:También conocido con el nombre de cuello de botella son siempre uno de los objetivos que elanalista evita al diseñar la entrada, una forma de evitarle 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ás pequeña sea esta menoresserán las oportunidades para cometer errores. Es común encontrar en las operaciones de ventaspor lo menos un 3% de errores en las operaciones de entrada de datos.Evitar los Pasos Adicionales:Algunas veces el volumen de transacciones y la cantidad de datos en preparación es algo que nose puede controlar por ello el analista experimentado, evitara diseños para la entrada que traiganuna mayor cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se alimenta unproceso 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 al mismo tiempoproporcionarán métodos para el control de los errores, la simplicidad funciona y es aceptada porcualquier usuario. Cuesta trabajo que los usuarios acepten sistemas complejos o confusos y queno exista ninguna garantía para el éxito al instalar un sistema complejo y que domine.Captura de Datos para la Entrada:En una transacción existen datos importantes y otros que no, el analista debe saber cualesutilizará y cuales en realidad deben formar la entrada. Existen dos tipos de datos:• datos variables• datos de identificaciónDatos Variables: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 siendo procesado.* Requerimientos De Salida *Niveles de diseñoEl diseño de sistema se representa a través de dos fases: el diseño lógico y el diseño físico.Cuando los analistas formulan un diseño lógico; escriben las especificaciones detalladas delnuevo sistema; esto es, describen sus características: las salidas, entradas, archivos y bases dedatos y procedimientos; todos de manera que cubran los requerimientos del proyecto.El diseño lógico de un sistema de información es como el plano de un ingeniero para armar unautomóvil: muestra las características principales(motor, transmisión y área para los pasajeros)ycomo se relacionan unas con otras(donde se conectan entre sí los componentes del sistema, o porejemplo, cuan separadas están las puertas.Los informes y la producción del analista son los componentes de todo el mecanismo que empleael ingeniero. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje.El diseño lógico también especifica las formas de entrada y las descripciones de las pantallas detodas las transacciones y archivos a fin de mantener los datos de inventario, los detalles de lastransacciones y los datos del proveedor. Las especificaciones de los procedimientos describenmétodos para introducir los datos, corridas de informes copiados de archivos y detección deproblemas.El diseño físico, actividad que sigue el diseño lógico, produce programas de software, archivos yun sistema en marcha, las especificaciones del diseño indican a los programadores que debehacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas porparte de los usuarios, procesan los datos, producen los informes y almacenan 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 para el nuevo sistemadesarrollado durante el análisis. Los datos de los requerimientos, recopilados durante lainvestigación, conforman las actividades y componentes del sistema. Los analistas formulan undiseño lógico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiarcomo resultado de un nuevo diseño.El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de requerimientos.En primer lugar se identifican las características generales, como informes y entradas; en eldiseño de la salida por ejemplo, los analistas deben conocer la longitud de campo de un datoespecífico para establecer cuanto espacio dejar en la información, en la pantalla de desplieguevisual o archivo.A lo largo de los años hemos visto una evolución de ideas y técnicas en el campo del análisis desistemas. La cual cabe en tres períodos amplios según Yourdon:1. El análisis de sistema convencional, anterior a los años 70´s, caracterizado por especificacionestipo novela victoriana que eran difíciles de leer y entender, y casi imposibles de mantener.2. El análisis estructurado clásico, de mediados de los años 70´s, a mediados de los años 80´s.Esto se caracterizó por primeras versiones de modelos gráficos, y énfasis en el modelado de lasimplementaciones actuales de un sistema antes de modelar el nuevo.3. El análisis estructurado moderno, en el cual se introducen mejoras sobre todo para modelarsistemas de tiempo real y relaciones de situaciones complejas. Aumentando por ende lacomunicación entre el analista y el sistema.En la actualidad las técnicas modernas están siendo fusionadas, para así lograr un mejor métodoque pueda hacerle frente a las necesidades de las diferentes fases del ciclo de vida del sistema,incluyendo a la fase de aná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ún Senn "permite al analistaconocer un sistema o proceso (actividad) en una forma lógica y manejable al mismo tiempo queproporciona la base para asegurar que no se omite ningún detalle pertinente". El objetivo quepersigue el análisis estructurado es organizar las tareas asociadas con la determinación derequerimientos para obtener la comprensión completa y exacta de una situación dada. Se puededecir adicionalmente que los componentes del análisis estructurado son los siguientes: símbolosgráficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas.Después de relacionarnos brevemente con la terminología básica, podemos entrar en aspectosrelacionados con los cambios del análisis estructurado.Podemos decir que para finales de los años 60´s e inicios de los 70´s el análisis estructuradosurge de la necesidad de buscar una forma interpretativa más rápida y eficiente, de tal maneraque se pudiesen definir los requerimientos del usuario y las especificaciones funcionales delsistema. Pero esto no se daba porque lo que existía eran grandes volúmenes de información quehabía que leer por completo y que acarreaban 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 especificaciones funcionales en formasencilla y rápida, aumentando por ende el grado de comunicación entre las especificacionesfuncionales y el usuario final (analista, programador, diseñador).Posteriormente, a mediados de los años 70´s estando el análisis estructurado clásico en suapogeo aparecen una serie de dificultades que limitan al analista hacer un buen desempeño desus actividades. Entre estos problemas según Yourdon podemos mencionar:
  • • Distinción difusa y poca, definida entre los modelos lógicos y los modelos fí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álisis estructurado clásico talescomo: diagramas de entidad-relación, diagramas de transición de estados, división de eventos,modelos esenciales y modelos de implantación. Pero a pesar de esto según Yourdon se siguierondando más problemas como los siguientes:• Tras la segunda y tercera correcciones de un diagrama, el analista se volvía cada vez másapuesto y renuente a hacer más cambios.• Debido a la cantidad de trabajo requerido, el analista dejaba a veces de dividir el modelo delsistema en modelos de menor nivel, quedando por ende, funciones primitivas.• A menudo no se incorporaban en el modelo del sistema los cambios en los requerimientos delusuario sino hasta después de la fase de análisis del proyecto.Inclusive las correcciones de los diagramas había que hacerlas en forma manual, para asegurarque fuesen consistentes y estuviesen completas; lo cual era bastante tedioso y dejaba por fueramuchos errores que debían de encontrarse. Pero para mediados de los 80´s aparecieron lasherramientas CASE que trataron de subsanar estos problemas. Las herramientas CASE(Ingeniería de software auxiliada por computadora) se utilizan para dibujar diagramas de flujo dedatos y otros además de llevar a cabo una variedad de labores de revisión de errores.Finalmente, algunos usuarios tenían dificultades al tratar con los modelos gráficos del análisisestructurado y preferían alguna otra forma de modelar los requerimientos y comportamiento delsistema; es por ello que aparecen las herramientas de generación de prototipos (mediados de los80´s) que son considerados como una alternativa al análisis estructurado para tales usuarios.También se utiliza para recordar en forma breve y precisa lo que se ha hecho a lo largo de todo eldesarrollo del sistema, para no perder la secuencia de lo que se está realizando.En la actualidad muchas de estas herramientas se están utilizando para facilitar la fase deanálisis, e inclusive se están elaborando o fusionando lo mejor de cada una de las técnicas queatienden las necesidades de todas las fases del ciclo de vida del sistema; para así obtener un mejoraprovechamiento, entendimiento, y rendimiento al momento que se ponga a correr el sistema.Disminuyendo de esta manera la serie de errores que se cometían anteriormente, con laintroducción de herramientas más especializadas y fáciles de utilizar.Diversos aspectos del análisis estructurado han cambiado gradualmente a lo largo de los últimosaños. Las principales áreas de cambio incluyen lo siguiente 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 se están dando, los siguientescambios o pautas en el ámbito total en lo que se refiere a análisis según Yourdon:• Mayor difusión del análisis de sistemas, sobre todo en los siguientes grupos: los nivelessuperiores de administración en organizaciones gubernamentales y de negocios, los niños, yprofesionales de la computación en los países del tercer mundo.• Impacto sobre la industria de software del tercer mundo.• Proliferación de las herramientas automatizadas, aunque no todos los analistas tienen acceso alas ú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 depender mucho también de quetan rápido pueda ajustarse el mismo a los cambios tecnológicos que se viven hoy en día. Debido aque han estado surgiendo otras 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 los años 60´s la quedieron cabida al surgimiento del análisis estructurado, ya que existía la necesidad de utilizar unanotación gráfica para representar los datos y los procesos que los transforman". Es por ello quesurgen una serie 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 auxiliada por computadora),elaboración de prototipos, símbolos gráficos, diccionarios de datos, descripciones de procesos yprocedimientos, reglas, diagramas de estados, diagramas de entidad-relación, diagramas detransición de eventos, división de eventos, modelos esenciales y modelos de implantación.* Métodos de Análisis Orientados al Flujo de Datos *La información se transforma como un flujo a través de un sistema basado en computadora. Elsistema acepta entrada de distintas formas; aplica un hardware, software y elementos humanospara transformar la entrada en salida; y produce una salida en distintas formas. La entrada puedeser una señal de control transmitida por un transductor, una serie de números escritos por unoperador humano, un paquete de información transmitido por un enlace a red, o un voluminosoarchivo de datos almacenado en memoria secundaria. La transformación puede comprender unasencilla comparación lógica, un complejo algoritmo numérico, o un método de inferencia basadoen regla de un sistema experto. La salida puede encender un sencillo led o producir un informe de200 páginas. En efecto, un modelo de flujo de datos puede aplicarse a cualquier sistema basadoen computadora independientemente del tamaño o complejidad.La función global del sistema se representa como una transformación sencilla de la información,representada en la figura como una burbuja. Una o más entradas. Representadas como flechascon etiqueta, conducen la transformación para producir la información de salida. Puedeobservarse que el modelo puede aplicarse a todo el sistema o solo a un elemento de software. Laclave es representar la información dada y producida por la transformación.* Diagramas de Flujos de Datos *Conforme con la información se mueve a través del software, se modifica mediante una serie detransformaciones. Un diagrama de flujos de datos (DFD), es una técnica grafica que describe elflujo de información y las transformaciones que se aplican a los datos, conforme se mueven de laentrada a la salida. El diagrama es similar en la forma a otros diagramas de flujo de actividades, yha sido incorporado en técnicas de análisis y diseños propuesto por Yourdon y Constantine,DeMarco y Gane y Sarson. También se le conoce como un grafo de flujo de datos o un diagramade burbujas.
  • * Diccionario de Datos *Un análisis del dominio de la información puede ser incompleto si solo se considera el flujo dedatos. Cada flecha de un diagrama de flujo de datos representa uno o más elementos deinformación. Por tanto, el analista debe disponer de algún otro método para representar elcontenido de cada flecha de un DFD.Se ha propuesto el diccionario de datos como una gramática casi formal para describir elcontenido de los elementos de información y ha sido definido da la siguiente forma:El diccionario de datos contiene las definiciones de todos los datos mencionados en el DFD, enuna especificación del proceso y en el propio diccionario de datos. Los datos compuestos (datosque pueden ser además divididos) se definen en términos de sus componentes; los datoselementales (datos que no pueden ser divididos) se definen en términos del significado de cadauno de los valores que puede asumir. Por tanto, el diccionario de datos esta compuesto dedefiniciones de flujo de datos, archivos [datos almacenados] y datos usados en los procesos[transformaciones]...* Descripciones Funcionales *Una vez que ha sido representado el dominio de la información (usando un DFD y un diccionariode datos), el analista describe cada función (transformación) representada, usando el lenguajenatural o alguna otra notación estilizada. Una de tales notaciones se llama ingles estructurado(también llamado lenguaje de diseño del programa o proceso(LDP)). El ingles estructuradoincorpora construcciones procedimentales básicas –secuencia, selección y repetición- junto confrases del lenguaje natural, de forma que pueden desarrollarse descripciones procedimentalesprecisas de las 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 de software comprendeel flujo de datos, el contenido de datos y la estructura de datos. Los métodos de análisisorientados a la estructura de datos representan los requerimientos del software enfocándosehacia la estructura de datos en vez de al flujo de datos. Aunque cada método orientado a laestructura de datos tiene un enfoque y notación distinta, todos tienen algunas características encomún: 1) todos asisten al analista en la identificación de los objetos de información clave(también llamados entidades o ítems) y operaciones (también llamadas acciones o procesos);2)todos suponen que la estructura de la información es jerárquica; 3)todos requiere que laestructura de datos se represente usando la secuencia, selección y repetición; y 4) todos dan unaconjunto de pasos para transformar una estructura de datos jerárquica en una estructura deprograma.Como los métodos orientados al flujo de datos, los métodos de análisis orientados a la estructurade datos proporcionan la base para el diseño de software. Siempre puede extenderse un métodode análisis para que abarque el diseño arquitectural y procedimental del software.