viernes, 25 de julio de 2008

DISEÑO ORIENTADO A LAS ESTRUCTURAS DE DATOS


RESUMEN

Capítulo 8



La íntima relación entre el software y datos puede ser rastreada hasta los orígenes de la computación. La estructura de la información, llamada estructura de datos, se ha demostrado que tiene un importante impacto en la complejidad y eficiencia de los algoritmos diseñados para procesar la información.

Los datos de entrada, internamente información almacenada (es decir, una base de datos), y los datos de salida, pueden tener cada uno una estructura única. El diseño orientado a la estructura de datos hace uso de estas estructuras como base para el desarrollo del software.

Diseño y estructura de los datos.

La estructura de los datos afecta al diseño, tanto en el aspecto estructural, como procedimental del software. Los datos repetitivos se procesan siempre con software que tiene facilidades de control para la repetición; los datos alternativos (es decir, información que puede o no puede estar presente) requieren software con elementos condicionales de procesamiento; una organización jerárquica de los datos frecuentemente tiene una extraordinaria semejanza con la estructura del programa que utiliza los datos.

El diseño orientado a la estructura de datos transforma una representación de la estructura de datos en una representación del software.

La metodología de desarrollo del sistema de Jackson parte de que la “paralelización de la estructura de datos de entrada y salida (informe) asegurará un diseño de calidad”.

La construcción lógica de programas (CLP), desarrollada por J. D. Warnier, da un método riguroso para el diseño del software. Sobre el esquema de relación entre estructura de datos y estructura procedimental, Warnier desarrolla un conjunto de técnicas que realizan una transformación de la estructura de datos de entrada/salida en una representación procedimental detallada del software.

El Desarrollo de Sistemas Estructurada de Datos (DSED), también llamado metodología de Warnier-Orr, es una extensión de CLP y potencia el análisis, así como las capacidades de diseño. El método DSED proporciona una notación y procedimiento para derivar la estructura de datos, estructura del programa y diseño procedimental detallado de los componentes del programa (Módulos). Además, DSED da una notación que facilita al diseñador de examinar el flujo de datos entre las fuentes y sumideros de información y de los procesos que transforman la información.

Una técnica llamada construcción lógica del software es una síntesis representativa de los métodos de diseño orientados a flujo de datos y a la estructuras de datos. Los creadores del método sostienen que “el diseño lógico puede describirse explícitamente si se ve el software con un sistema de conjuntos de datos y transformaciones de datos”.

Áreas de aplicación.

El diseño orientado a la estructura de datos puede aplicarse con éxito a aplicaciones que tengan una estructura jerárquica, bien definida, de la información.

· Aplicaciones en sistemas de información comerciales. La entrada y salida tiene distinta estructura (por ejemplo, archivos de entrada, informes de salida); el uso de una base de datos jerárquico es frecuente.
· Aplicaciones de sistema. La estructura de datos para los sistemas operativos comprenden muchas tablas, archivos y listas que tienen una estructura bien definida.

El diseño orientado a la estructura de datos puede ser adecuado para aplicaciones del dominio de la ingeniería y de la ciencia, enseñanza asistida por computadora, resolución de problemas combinatorios y muchas otras áreas.
En general, el diseño orientado a la estructura de datos es más difícil de aprender y más complicado de aplicar que las técnicas orientadas al flujo de datos. Sin embargo, la escuela de diseño orientado a la estructura de datos ofrece un enfoque más rico y, potencialmente, más poderoso para el diseño de software.

Técnicas de estructuras de datos frente a las de flujo de datos.

El diseño orientado a la estructura de datos no hace un uso explícito de un diagrama de flujo de datos. Por tanto, las clasificaciones de flujo de transformación y de transacción tienen poca relevancia en el método de diseño orientado a la estructura de datos. Lo más importante es que el objetivo último de los métodos orientados a la estructura de datos es producir una descripción procedimental del software. El concepto de estructura modular de programa no se considera explícitamente. Los módulos se consideran un subproducto del procedimiento y a la idea de independencia de módulos se le da poca importancia.

El diseño orientado a la estructura de datos hace uso de un diagrama jerárquico para representar la estructura de la información. Por lo tanto, durante el análisis de requerimiento del software, el énfasis debe colocarse en estos modos de representación.

Consideraciones sobre el proceso de diseño.

Cada método de diseño da un conjunto de “reglas” que facilitan al diseñador la transformación de la estructura de datos en una representación del software.

Cada método orientado a la estructura de datos tiene su propio conjunto de reglas. Sin embargo, deben realizarse siempre las siguientes tareas de diseño:



  1. Evaluar las características de la estructura de datos.


  2. Representar los datos en términos de formas elementales, tales como secuencia, selección y repetición.


  3. Transformar la representación de la estructura de datos en una jerarquía de control para el software.


  4. Refinar la jerarquía de software usando los criterios definidos como parte de un método.


  5. Desarrollar finalmente una descripción procedimental del software.


En los métodos orientados a la estructura de datos no está clara la división entre los pasos de diseño arquitectural y procedimental (se ha descrito como parte del proceso del diseño de software). Warnier y Orr van rápidamente hacia la representación procedimental.

DESARROLLO DEL SISTEMA DE JACKSON

Como la mayoría de las metodologías de diseño de software, el Desarrollo de Sistemas de Jackson (DSJ) es realmente una continuación de los pasos técnicos que soportan el análisis y diseño de software.

Para realizar el Desarrollo de Sistema de Jackson (DSJ) el analista y diseñador han de dar los siguientes pasos:

Paso de las acciones y entidades. Se identifican las entidades (agentes, objetos u organizaciones que un sistema necesita para producir o usar la información) y acciones (los sucesos que ocurren en el mundo real que afectan a las entidades).
Pasos de estructuración de las entidades. Las acciones que afectan a cada entidad se ordenan en el tiempo y se representan mediante los diagramas de Jackson.
Paso de modelación inicial. Las entidades y acciones se representan como un modelo del proceso; se definen las conexiones entre el modelo y el mundo real.
Paso funci0nal. Se especifican las funciones que corresponden a las acciones definidas.
Paso de temporización del sistema. Se establecen y especifican las características de planificación del proceso.
Pacto de implementación. Se especifica el hardware y software como un diseño.

CONSTRUCCIÓN LÓGICA DE PROGRAMAS Y SISTEMAS

La construcción Lógica de Programas y más recientemente la Construcción Lógica de Sistema (referidos colectivamente como CLP) se desarrollaron para definir un conjunto de “reglas” y “leyes” que gobiernen la estructura de la información y la organización resultante del software obtenido.

La Construcción Lógica de Programa (CLP) presenta procedimientos para el análisis y diseño. Comenzando con la representación formal de las estructuras de datos, el método conduce a la derivación de procedimientos y culmina con métodos sistemáticos para la generación de pseudocódigo, verificación y optimización.

El diagrama de Warnier.

La notación para la estructura de datos, usados en la Construcción Lógica de Programa (CLP), es el diagrama de Warnier. Como el diagrama de Jackson, la representación de Warnier de los datos describe jerarquías, así como repetición explicita e información condicional.

Una “regla” establecida por Warnier indica que “cualquier conjunto de información debe subdividirse en subconjuntos. El diagrama Warnier realiza esta subdivisión con la especificación adicional del número de ocurrencia de los elementos de datos.

El método de diseño Construcción Lógica de Programa (CLP).

El método de diseño CLP comienza con la especificación de las estructuras de datos de entrada y salida usando los diagramas de Warnier. Como otros métodos de diseño, una minuciosa evaluación de los requerimientos del software es la precursora de la derivación de una representación del software. Warnier toma la visión clásica de que los “programas, como los datos (entrada) y resultados, son archivos de información.


Organización detallada.

La construcción lógica de programas intenta extender la metodología de diseño a un dominio que los otros métodos evitan. Warnier ha desarrollado una técnica, llamada organización detallada, en la que un conjunto de instrucciones detalladas puede desarrollarse sistemáticamente a partir de la organización lógica del programa. Otros métodos establecen una base para la especificación de instrucciones detalladas, pero Warnier ha propuesto un procedimiento paso a paso para derivar tales instrucciones.

Warnier define los siguientes tipos de instrucciones:

Entrada y preparación de a entrada.
Bifurcación y bifurcación preliminares.
Cálculos.
Llamadas a subprogramas (módulos).
Estructuras complejas.

Conforme la organización lógica de un programa se vuelve más compleja, se requieren técnicas de diseño adicional para representar y finalmente simplificar las condiciones y el correspondiente procesamiento. La construcción lógica de programas (CLP) recomienda el uso del álgebra boolena (en informática y matemática, es una estructura algebraica que vigorizan las operaciones lógicas Y, O y NO, así como el conjunto de operaciones unión, intersección y complemento) y/o diagramas de Karanaugh (sirven principalmente para minimizar expresiones del tipo suma de productos o productos de sumas, obteniendo otra suma d productos o producto de sumas) para ayudar a reducir la complejidad lógica, ayudando así al diseñador en la especificación de la organización detallada.

DESARROLLO DE SISTEMAS ESTRUCTURADOS DE DATOS

El Desarrollo de Sistemas Estructurados de Datos (DSED), extiende los conceptos básicos desarrollados por Warnier a una metodología más comprensiva para el análisis y diseño de sistemas basados en computadoras.

Los diagramas y datos contenidos en estas representaciones, se utilizan como la base de diseño lógico procedimental del software. El diseño físico surge el diseño lógico y se enfoca sobre el “empaquetado” del software, para adquirir mejor el rendimiento deseado, mantenimiento y otras ligaduras de diseño impuestas por el entorno del sistema.

Un método de diseño simplificado.

El proceso de diseño lógico puede dividirse en dos actividades: la derivación de la estructura lógica de la salida (ELS) y la definición resultante de la estructura lógica del proceso Estructura Lógica del Proceso.

En este método los elementos de datos, que son parte de dominio de la información de un problema, se organiza jerárquicamente, de la misma forma que en los métodos de diseño de Jackson y Warnier. Se aplica un proceso de cuatro pasos para derivar la estructura lógica de la salida (ELS):

Se evalúa la declaración del problema o información relativa a los requerimientos, y se listan todos los elementos de datos distintos (llamados átomos), que no pueden ser subdivididos más.
Se especifica la frecuencia de ocurrencia de cada átomo.
Se evalúan los elementos de datos que pueden ser subdivididos (llamados universales).
Se desarrolla una representación diagramática de ELS.

Derivación de la estructura lógica de la salida.

La estructura lógica de salida (ELS) es una representación jerárquica de los elementos de datos que componen la salida de un sistema basado en computadora. El primer paso en la derivación del ELS es aislar todos los átomos (elementos de datos que no pueden ser subdivididos).

Una vez que todos los átomos y su frecuencia han sido definidos, el diseñador comienza un examen de los universales. Los universales son elementos o categorías de datos que están compuestos de otros universales y átomos.

Derivación de la estructura lógica del proceso.



La estructura lógica del proceso (ELP) es una representación procedimental del software requerido para procesar el correspondiente ELS. El método DSED para la derivación de ELP es similar, en muchos aspectos, a la derivación de Warnier de una organización detallada en CLP. Cada elemento de dato universal se convierte en una construcción repetitiva, a la que se añaden las instrucciones de procesamiento. Se siguen los siguientes pasos para derivar el ELP:

Se quitan todos los átomos del diagrama de Warnier-Orr para el ELS.
Se añaden los delimitadores BEGIN y END a todos los universales (repeticiones).
Se definen todas las instrucciones o procesos de inicialización y terminación.
Se especifican todos los cálculos o procesamientos no numéricos.
Se especifican todas las instrucciones y procesor de salida.
Se especifican todas las instrucciones y procesos de entrada.

Se han presentado tres métodos importantes de diseño –Desarrollo de Sistema de Jackson, Construcción Lógica de Programas y Desarrollo de Sistema Estructurado de Datos. Todos son significativamente similares en muchos aspectos, pero cada uno enfoca el proceso de diseño del software desde un punto de vista algo diferente.

Cada uno de los tres métodos de diseño orientado a estructura de datos presentados introduce importantes ideas sobre la naturaleza del buen diseño y especifica métodos para lograrlo. Conforme estos métodos han madurado, su singular enfoque sobre la estructuras de datos se ha ido ensanchando, conforme evolucionó nuestra compresión de lo que “un buen sistema debe parecer”.

viernes, 18 de julio de 2008

Resumen Libro Ingeniería de Softwawre Capítulo 6

LA PRODUCTIVIDAD Y LA EVOLUCIÓN
Uno de los objetivos principales de información de ingeniería es mejorar la productividad en la construcción de aplicaciones de ordenador. Puede ayudar a mejorar la productividad de varias maneras. Dos de los más importantes son el uso de herramientas automatizadas y de su identificación común de datos y procesos a fin de que estos deben ser diseñados por una sola vez en lugar de por separado para múltiples aplicaciones.

Al principio puede haber una preocupación de que IE se ralentiza el desarrollo del sistema, ya que aboga por que detallado modelado de datos y modelado de procesos se realizan antes de diseño comienza.

IE se basa en un marco diseñado por separado que los sistemas de ajuste. Este marco tiene en algún momento de construir, pero una vez que exista, los sistemas se pueden construir rápidamente en el marco.

En la ingeniería de software un problema en relación con el análisis estructurado y el diseño es que requiere un trabajo importante por hacer antes de que comience la codificación. Algunos ejecutores se sienten incómodos acerca de retrasar el código. Tienen una gran necesidad de construir algo, incluso si aún no está diseñado adecuadamente. Es sólo una leve exageración decir que muchos de esos sistema están diseñados de pruebas. Tan poco se sabe sobre los requisitos de sistema que está a menudo después de que se construya que sale a luz la verdad. Abogado del análisis estructurado y del diseño que hace más trabajo en las partes frontales del ciclo vital y menos trabajo en el extremo trasero, especialmente si se utilizan las idiomas de cuarta generación o los generadores de código.
El IE requiere aún más el trabajo antes de la codificación porque el sistema debe caber en las infraestructuras de otros sistemas. Sin embargo, uno los modelos de datos y los modelos de proceso existe en una enciclopedia del IE, diseño individual del systtem y la construcción puede proceder rápidamente si se utilizan las herramientas convenientemente automatizadas.

I.S. Productividad. Muchos estudios se han hecho de los efects de las herramientas de la productividad de I.S., y éstos demuestran mejoras importantes en algunas organizaciones pero mejoras bajas en otra usando las mismas herramientas. Para alcanzar alta productividad, es necesario no sólo seleccionar las mejores herramientas pero también adaptar la organización y métodos de I.S. para aprovechar completo de estas herramientas.
Los procesadores de textos de los abogados dan lugar a menudo a lejos más texto que es creado; el diagramming filetea a menudo resultado en lejos más diagramas que son creados.

Un efecto más valuoso de instrumentos de Caso buenos es el retiro de errores e inconsistencies en la etapa de diseño. Los diseños son de calidad más alta, conduciendo a menos problemas y menos tiempo tomado en el retiro de errores del código.
Los generadores de código permiten a ejecutores producir un programa de trabajo rápidamente. Sin embargo, si el generador no se liga a un diccionario, a un modelo de datos, o a herramientas de diseño, los programas generados pueden ser fragmentos incompatibles, enfermedad diseñada y que no liga juntos. Para alcanzar alta productividad, las herramientas para el diseño necesitan ser juntadas firmemente al generador de código. Las herramientas de diseño deben emplear un modelo de datos y deben permitir al diseño ser representado en un de gran alcance, visual, fácil-a-modifique la forma de las cuales cifran se genera adentro directamente. Los programas deben ser rápidamente ejecutables de modo que el diseñador pueda observar lo que él hace, ajusta o agrega al diseño, vuelve a efectuar los programas, realza el diseño, y así sucesivamente, hasta que se cree un sistema comprensivo. El principio qué usted ve es lo que usted consigue debe aplicarse a la combinación de herramienta de diseño y de generador de código visuales. La necesidad de la codificación manual se debe quitar al máximo.
El generador primero produce el código estructurado que se relaciona con las pantallas del diseño. Este código se puede utilizar para la creación de un prototipo y el depuración. El código estructurado no da perfomance óptimo de la máquina, así pues, para los usos resistentes, el código se puede alimentar en un optimizador que cree código con funcionamiento óptimo de la máquina. Este código nunca será tocado por los programadores de mantenimiento.

La herramienta del generador del diseñador debe facilitar los prototipos que son construidos y modificados rápidamente. Debe generar datos de prueba y proporcionar las herramientas de prueba. Debe generar código de la base de datos y código de control de trabajo, para poder ejecutar rápidamente el programa cuando se realizan los cambios de diseño. Con creación de un prototipo de gran alcance filetea un ciclo vital iterativo del desarrollo se utiliza. El ejecutor diseña algo en la pantalla de una herramienta del I-caso, genera código, ejecuta el código y lo prueba, después se modifica o agrega al diseño, regenera código, y así sucesivamente. Cuanto más rápido es el ciclo de la diseñar-generar-prueba puede ser, más productivo el ejecutor es probable ser. Las herramientas de diseño de gran alcance con los generadores interpretativos son necesarias que hacen este ciclo tan rápido como sea posible.

EL EFECT DE EQUIPOS GRANDES
La productividad del desarrollo de sistema es afectada fuertemente por el número de gente en el equipo de desarrollo de sistema. Los equipos grandes tienden a dar productividad baja del desarrollo. La razón es que el número de interacciones entre los miembros de equipo aumenta rápidamente mientras que el tamaño del equipo aumenta. Si hay gente de N en el equipo, obrando recíprocamente todo, el número de interacciones personales es N (N-1) /2. Cuando obra recíprocamente la gente, hay miscommunication. La tentativa de disminuir el miscommunication documentando las interacciones es desperdiciadora de tiempo y no trabaja a menudo bien. Los efectos de productividad-reducción son aproximadamente proporcionales al cuadrado del número de miembros de equipo que obran recíprocamente.
Estadísticas para la demostración programada convencional mucha una gran cantidad de líneas de código por persona para el equipo muy pequeño que para los equipos grandes. Los proyectos del desarrollo de aplicaciones con muy una gran cantidad de gente son a menudo desastrosos. Los proyectos de una persona exhiben la productividad más alta.
Cuadro 6.2 estadísticas de las demostraciones para la programación de COBOL. El número medio de línea de código por personas-año varía a partir el 800 a 15.000, dependiendo del tamaño del programa. Esto refleja en gran parte el efecto de equipos grandes: 500 la línea programa es escrita por una persona; 500.000 la línea programas es escrita por los equipos grandes.


Diseño y código reutilizables.Los programadores de hoy reinventan constantemente la rueda. Luchan para crear algo que se ha creado las épocas sin fin antes. Los aumentos de la productividad del alcalde resultarán de emplear diseños, modelos de datos, o código reutilizables. Los componentes reutilizables se deben catalogar en una enciclopedia del caso para poderlos ser seleccionados cuando son necesarios y modificarse como sea necesario. Una empresa grande debe emplear el mismo juego de herramientas del Yo-caso en todas las localizaciones en donde se construyen los sistemas para poder utilizar modelos de datos, diseños, y componets comunes del programa por localizaciones múltiples. Las telecomunicaciones tienen acceso a las enciclopedias de la unidad central facilitan la distribución de usos, diseño de documento, procedimientos de contabilidad, y así sucesivamente.
Un objetivo del IE es identificar concordancia en datos y procesos y por lo tanto reducir al mínimo el trabajo de desarrollo redundante de sistema. El modelado de datos hace claro que los mismos tipos de entidad son aplicaciones en usos numerosos.
Dondequiera que se utilicen puede haber ciertas rutinas que serán invocadas, por ejemplo la computación de cualidades derivadas, aplicando cheques de la integridad, o crear datos sumarios. Una corporación puede tener muchas fábricas que al grado grande tengan los mismos tipos de entidad.
Muchos de los procedimientos de proceso de datos pueden ser iguales a partir de una fábrica a otra. Algunos serán enteramente diferentes. La gerencia puede hacer comparaciones. Cuando se hace la descomposición de proceso y los procesos se trazan contra tipos de entidad, la concordancia entre procesos puede ser descubierta.

Westpac, uno del banco más grande del hemisferio meridional, basado en Sydney, utilizó la ingeniería de información a través del banco entero, con la ayuda de su gerencia superior, que reconoció que un mejor uso de la informática era crítico para el crecimiento y el éxito del banco.
Westpac, uno del banco más grande del hemisferio meridional, basado en Sydney, utilizó la ingeniería de información a través del banco entero, con la ayuda de su gerencia superior, que reconoció que un mejor uso de la informática era crítico para el crecimiento y el éxito del banco.
Esta reducción del 22:1 en el código generado ahorró mucha hora de desarrollo y es probable reducir el esfuerzo del mantenimiento grandemente. También ayudó a proporcionar la consistencia de la información y de la información, que es valiosa a la gerencia y buena para los clientes. Pongo en contraste esto con el banco que utilizo, que me dice que es imposible computar la vuelta en activos neta porque las computadoras no pueden manejarla. El diseño y el código reutilizables deben ser un objetivo importante del desarrollo de proceso de datos porque pueden reducir dramáticamente esfuerzo del desarrollo y del mantenimiento.
Cuando un generador de código puede generar código directamente forme una representación del diseño que el foco de la reutilidad es la etapa de diseño. Los módulos del diseño pueden ser almacenados en la enciclopedia y ser utilizados cuando están necesitados. El banco de trabajo del diseño hace diseños fáciles modificarse.
El poder hacer ajustes a los diseños, y agregar a ellos según lo necesitado, amplía grandemente el sentido práctico del diseño reutilizable.
Los estándares para el diseño del uso también amplían el sentido práctico del diseño reutilizable. Éstos incluyen los estándares establecidos en la organización de I.S. para el acceso a las redes, acceso a las bases de datos, formatos de documento estándar, diálogos estándar del usuario, IMB' s SAA (arquitectura del uso de sistemas), y así sucesivamente. De uso común de tal estándar a través de una organización de I.S compara a los aumentos en productividad de I.S.
La cuadro 6.1 resume las medidas para maximizar productividad.
- Utilice las herramientas de diseño de gran alcance automatizadas.
- utilice las herramientas de diseño que cogen todos los errores posibles y cogen todas las inconsistencias en el diseño.
- utilice el generador de código integrado con el diseño (las herramientas de un I-caso).
- utilice las herramientas que hacen el ciclo de diseño, generan, prueban, modifican, generan, prueban tan rapid como sea posible.
- Utilice las herramientas de diseño en línea a una enciclopedia comprensiva del IE.
- Diseño dentro de un marco preexistente del plan del IE, de los modelos de datos, y de los modelos de proceso.
- Utilice los modelos de datos correctamente normalizados.
- Genere tanto del diseño de los modelos comerciales y de la regla de negocio como posible.
- Utilice la creación de un prototipo de alta velocidad dentro del marco del IE.
- Genere el documetation automáticamente.

Crecimiento evolutivo de sistemas.
El más impresionantes de sistemas complejos no se crean con un solos diseño y puesta en práctica. Se desarrollan, siendo mejorado en muchos pasos en las diversas horas y lugares.
Un diseñador de sistema mira los trabajos de la naturaleza con temor. Un guepardo que mira para la presa en el amanecer suddnely compite con friega a través en 70 kilómetros por hora con tolerancia asombrosa para matar un antílope del salto. Un colibrí, que dirigen probado una vez era una imposibilidad aerodinámica, revolotea de la flor a la flor y emigra a Suramérica.
El cerebro humano, por completo o los esquemas diabólicos y la poesía maravillosa, ha probado mucho más alla de nuestras técnicas más ambiciosas de la inteligencia artificial. Éstos no son el sistema para el cual Dios escribió especificaciones; son el sistema que se desarrolló sobre millones de años.
El futuro traerá software impresionante y sistemas informáticos corporativos, y éstos también serán crecidos durante muchos años con mucha gente y organizaciones que agregan a ellas. Es difícil o imposible crecer el software que es un lío.
Para alcanzar la evolución de largo plazo del software, necesitamos modelos estructurados de los modelos de los datos y de estructura de procesos. Los diseños demasiados complejos para que una persona sepa todo el detalle se deben representar en una manera ordenada en una enciclopedia de modo que mucha gente en muchos lugares pueda agregar al diseño.El diseño necesita estándares y los componentes y la arquitectura reutilizables que facilita la adición incremental de nuevas funciones. De modo que los ejecutivos puedan controlar el comportamiento de las computadoras que ponen automáticamente órdenes, seleccionan a surtidores, hacen comercios, y así sucesivamente, el comportamiento debe ser expresable en las reglas y los diagramas que los ejecutivos entienden.

ISO 9003

ISO 9003: Sistemas de Calidad - Modelos para Aseguramiento de la Calidad en la Inspección Final y Pruebas. Este es el modelo contractual para los sistemas de calidad que no incluye diseño o producción. ISO 9003 contiene cerca de la mitad de requerimientos de ISO 9001 y modifica algunos requerimientos para adecuarse a la inspección y la aplicación de prueba final. ISO 9003 requiere el desarrollo de un manual de calidad y procedimientos documentados que definan la organización y operación del sistema de calidad. Es responsabilidad de una compañía crear y mantener estos documentos, de modo tal que sean relevantes y apropiados a la operación específica del negocio.

Fundamento de análisis de requisitos.



La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de aproximaciones contrastadas.

El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.

El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.

Por ejemplo, un mayorista de recambios de automóviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rápidamente el estado de un componente; (2) dos o tres días de media para actualizar un archivo a base de tarjetas; (3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista determina qué información va a producir el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del inventario.

Una vez evaluados los problemas actuales y la información deseada (entradas y salidas), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en el Plan del Software? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software para posteriores fases de desarrollo. A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones debe realizar el sistema, qué interfaces se definen y qué restricciones son aplicables?

Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.

Ingeniería de sistema de computadora.


HACE casi 500 años, Maquiavelo dijo: “no hay nada más difícil de llevar a cabo, más peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción de un nuevo orden de cosas”. Durante los Últimos 50 años, los sistemas basados en computadora han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avances desde que habló Maquiavelo, sus palabras siguen sonando a verdad. La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información. El proceso de ingeniería de sistemas es denominado ingeniería de procesos de negocio cuando el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniería de producto. Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desarrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de aplicación diferente, ambas intentan poner al software en su contexto.

La palabra sistema es posiblemente el término más usado y abusado del léxico técnico. Hablamos de sistemas políticos y de sistemas educativos, de sistemas de aviación y de sistemas de fabricación, de sistemas bancarios y de sistemas de locomoción. La palabra no nos dice gran cosa. Usamos el adjetivo para describir el sistema y para entender el contexto en que se emplea. El diccionario Webster define sistema como:

1. un conjunto o disposición de cosas relacionadas de manera que forman una unidad o un todo orgánico; 2. Un conjunto de hechos, principios, reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes; 3. Un método o plan de clasificación o disposición; 4.una manera establecida de hacer algo; método; procedimiento ...

Se proporcionan cinco definiciones más en el diccionario, pero no se sugiere un sinónimo preciso. Sistema es una palabra especial. Tomando prestada la definición del diccionario Webster, definimos un sistema basado en computadora como:

Un conjunto o disposición de elementos que están organizados para realizar un objetivo preteñido procesando información. El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:

Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido. Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real.

Personas. Usuarios y operadores del hardware y software.

Documentación. Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema.

Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema.
Los elementos se combinan de varias maneras para transformar la información. Por ejemplo, un departamento de marketing transforma la información bruta de ventas en un perfil del típico comprador del producto; un robot transforma un archivo de órdenes, que contiene instrucciones específicas, en un conjunto de señales de control que provocan alguna acción física específica. Tanto la creación de un sistema de información para asesorar a un departamento de marketing, como el software de control para el robot, requieren de la ingeniería de sistemas. Una característica complicada de los sistemas basados en computadora es que los elementos que componen un sistema pueden también representar un macroelemento de un sistema aún más grande. El macroelemento es un sistema basado en computadora que es parte de un sistema más grande basado en computadora. Por ejemplo, consideremos un «sistema de automatización de una fábrica» que es esencialmente una jerarquía de sistemas. En el nivel inferior de la jerarquía tenemos una máquina de control numérico, robots y dispositivos de entrada de información. Cada uno es un sistema basado en computadora por derecho propio. Los elementos de la máquina de control numérico incluyen hardware electrónico y electromecánico (por ejemplo, procesador y memoria, motores, sensores); software (para comunicaciones, control de la máquina e interpolación); personas (el operador de la máquina); una base de datos (el programa CN almacenado); documentación y procedimientos. Se podría aplicar una descomposición similar a los dispositivos de entrada de información y al robot. Todos son sistemas basados en computadora.

Análisis de requisitos del sistema del software.



El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.

La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.

Inicio del proceso
La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener expectativas radicalmente diferentes): los dos están deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un éxito.
Técnicas para facilitar las especificaciones de una aplicación.
Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este método no funciona muy bien. Abundan los malentendidos, se omite información importante y nunca se establece una buena relación de trabajo.

Diseño de interfaz del Usuario.



El plano de una casa (su diseño arquitectónico) no está completo sin la representación de puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora. Puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora.