La ingeniería del diseño hace referencia al arte de aplicar los conocimientos científicos en la ordenación de los elementos básicos, tangibles e intangibles, de un objeto o estructura con el fin de aumentar su belleza o utilidad. El término diseño admite varias significados. Así, el “diseño” puede ser una actividad, la “actividad de diseñar”, puede ser un producto, el “resultado de la actividad de diseñar”, o puede ser un calificativo, y en este sentido es muy común referirse a un objeto como “de diseño”, cuando aporta una geometría, una forma o unas cualidades diferenciadoras que implican un aire de calidad y distinción. El término “diseño” se deriva de “diseñar”, que a su vez tiene su origen en el latín, designare, que en origen significa en trazar y también dibujar, marcar o designar. De hecho, la primera acepción del término diseño, en español, es “traza o delineación de una figura o un edificio”. Pero el término admite también un significado amplio: “ordenación de los elementos básicos, tangibles e intangibles, de un objeto o estructura con el fin de aumentar su belleza o utilidad”.
Se debe notar que, de acuerdo con esta significación, el diseño aborda los “elementos básicos”, esto es, los más relevantes o fundamentales. La ordenación de los detalles correspondería a una parte del “diseño”, que sería el “diseño detallado”. También se debe apuntar que el diseño no conlleva necesariamente unas tareas de “cálculo” o de “dimensionamiento preciso”, tareas que sí formarían parte de un diseño detallado o de las propias de una ingeniería. Para completar la idea, el término “ingeniería” proviene del latín ingenium y se define como: “el arte de aplicar los conocimientos científicos a la invención, utilización o perfeccionamiento de la técnica en todas sus determinaciones”. Por consiguiente se puede decir que la ingeniería del diseño es la representación o modelo del software, que proporciona datos sobre la estructura de los datos, la arquitectura, las interfaces, los procedimientos, etc., normalmente este tipo de ingeniería es utilizada por los ingenieros del software. Esta fase es importante ya que de aquí se extraen o establece la calidad del software y se pueden hacer las mejoras pertinentes, si es necesario, sin invocar a pruebas o al cliente.
El diseño de software se define como el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema, con suficientes detalles que permitan su interpretación y realización física. El diseño del software desde un punto de vista operativo incluye cuatro etapas: (1) El diseño de los datos. Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. (2) El diseño arquitectónico. Define la relación entre cada uno de los elementos estructurales del programa. (3) El diseño de la interfaz. Describe como se comunica el software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. (4) El diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del diseño del software se puede definir en una sola palabra “calidad”, dentro del diseño es donde se fomenta la calidad del proyecto. El diseño es la única manera de materializar con precisión los requerimientos del cliente, siendo un proceso y un modelado a la vez. El proceso de diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del sistema a construir.
A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: (1) El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. (2) Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software. (3) El diseño debe proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación.
Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un buen diseño como son: (1) Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software. (2) El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en elementos que realicen funciones y sub-funciones especificas. (3) Un diseño debe contener abstracciones de datos y procedimientos. (4) Debe producir módulos que presenten características de funcionamiento independiente. (5) Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior. (6) Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software. Estos criterios no se consiguen por casualidad. El proceso de diseño del software exige buena calidad a través de la aplicación de principios fundamentales de diseño, metodología sistemática y una revisión exhaustiva.
Cuando se diseña un sistema computacional se debe tener presente que el proceso de un diseño incluye, concebir y planear algo en la mente, así como hacer un dibujo o modelo o croquis. Para el diseño del producto software debe realizarse los siguientes diseños: (1) Diseño de la salida. En este caso la salida se refiere a los resultados e información generada por el sistema. Para la mayoría de los usuarios la salida es la única razón para el desarrollo de un sistema y la base de evaluación de su utilidad. (2) Diseño de archivos. En este punto se incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia. (3) Diseño de interacciones con la base de datos. La mayoría de los sistemas de información ya sean implantado en sistemas de cómputos grandes o pequeños, utilizan una base de datos que puede abarcar varias aplicaciones, por esta razón estos sistemas utilizan un administrador de base de datos, en este caso el diseñador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema.
Por otra parte, existen cuatro indicios principales que indican que el software cuenta con un mal diseño, los mismos no son independientes y están relacionados unos con otros, estos indicios son: (1) Rigidez. Es la tendencia del software a ser difícil de cambiar, incluso en las cosas más sencillas. Cada cambio produce una cascada de cambios en módulos dependientes. Lo que parecía un cambio de dos días en un módulo resulta ser varias semanas de cambios de módulos a través de la aplicación. El miedo del gestor puede llegar a ser tan agudo que se niegue a realizar modificaciones en la aplicación. (2) Fragilidad. La fragilidad es la tendencia que tiene el software a romperse por muchos sitios cada vez que se cambia algo. Muchas de las roturas ocurren en sitios que no están relacionados conceptualmente con el área que se está cambiando. Cada vez que los gestores autorizan un cambio tienen miedo de que el programa se rompa por algún lugar inesperado. (3) Inmovilidad. La inmovilidad es la resistencia del software a ser reutilizado en otros proyectos o parte de otros proyectos. Pasa muchas veces que un programador descubre que necesita un módulo que es muy parecido a otro que ha desarrollado otro programador. Sin embargo, también pasa muchas veces que el módulo en cuestión depende demasiado de la aplicación en la que está integrado. Después de mucho trabajo los desarrolladores descubren que el trabajo necesario para separar las partes reutilizables de las partes no reutilizables es demasiado alto. Y entonces el software simplemente se reescribe en vez de ser reutilizado. (4) Viscosidad. La viscosidad del diseño es la dificultad de mantener la filosofía del diseño original. Cuando se afronta un cambio los programadores encuentran normalmente más de una manera de realizarlo. Algunas de estas formas preservan la filosofía del diseño y otras no. Estos cuatro síntomas son reveladores de un diseño de arquitectura pobre. Cualquier aplicación que muestra estos síntomas adolece de un diseño pobre.
Finalmente las causas principales para que el diseño se deteriore son las siguientes: (1) Requisitos cambiantes. La causa de la degradación del diseño es muy conocida. Los requisitos han ido cambiando de manera que no estaba previsto en el diseño inicial. A menudo los cambios necesitan hacerse rápidamente y hechos por programadores que no están familiarizados con el diseño original. Entonces, aunque los cambios funcionan, violan el diseño original. Poco a poco los cambios continúan y las violaciones se acumulan hasta que el diseño se rompe. (2) Control de dependencias. Los cambios que introducen nuevas e imprevistas dependencias hacen que un diseño se deteriore. Para anticiparse a la degradación de las dependencias del diseño de la arquitectura, deben ser controladas las dependencias entre módulos de una aplicación. Este control consiste en la creación de "cortafuegos" de dependencias. A través de estos cortafuegos las dependencias no se propagan. El diseño orientado a objetos está repleto de principios y técnicas que permiten construir estos cortafuegos y controlar estas dependencias.
Se debe notar que, de acuerdo con esta significación, el diseño aborda los “elementos básicos”, esto es, los más relevantes o fundamentales. La ordenación de los detalles correspondería a una parte del “diseño”, que sería el “diseño detallado”. También se debe apuntar que el diseño no conlleva necesariamente unas tareas de “cálculo” o de “dimensionamiento preciso”, tareas que sí formarían parte de un diseño detallado o de las propias de una ingeniería. Para completar la idea, el término “ingeniería” proviene del latín ingenium y se define como: “el arte de aplicar los conocimientos científicos a la invención, utilización o perfeccionamiento de la técnica en todas sus determinaciones”. Por consiguiente se puede decir que la ingeniería del diseño es la representación o modelo del software, que proporciona datos sobre la estructura de los datos, la arquitectura, las interfaces, los procedimientos, etc., normalmente este tipo de ingeniería es utilizada por los ingenieros del software. Esta fase es importante ya que de aquí se extraen o establece la calidad del software y se pueden hacer las mejoras pertinentes, si es necesario, sin invocar a pruebas o al cliente.
El diseño de software se define como el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema, con suficientes detalles que permitan su interpretación y realización física. El diseño del software desde un punto de vista operativo incluye cuatro etapas: (1) El diseño de los datos. Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. (2) El diseño arquitectónico. Define la relación entre cada uno de los elementos estructurales del programa. (3) El diseño de la interfaz. Describe como se comunica el software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. (4) El diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del diseño del software se puede definir en una sola palabra “calidad”, dentro del diseño es donde se fomenta la calidad del proyecto. El diseño es la única manera de materializar con precisión los requerimientos del cliente, siendo un proceso y un modelado a la vez. El proceso de diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del sistema a construir.
A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: (1) El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. (2) Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software. (3) El diseño debe proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación.
Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un buen diseño como son: (1) Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software. (2) El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en elementos que realicen funciones y sub-funciones especificas. (3) Un diseño debe contener abstracciones de datos y procedimientos. (4) Debe producir módulos que presenten características de funcionamiento independiente. (5) Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior. (6) Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software. Estos criterios no se consiguen por casualidad. El proceso de diseño del software exige buena calidad a través de la aplicación de principios fundamentales de diseño, metodología sistemática y una revisión exhaustiva.
Cuando se diseña un sistema computacional se debe tener presente que el proceso de un diseño incluye, concebir y planear algo en la mente, así como hacer un dibujo o modelo o croquis. Para el diseño del producto software debe realizarse los siguientes diseños: (1) Diseño de la salida. En este caso la salida se refiere a los resultados e información generada por el sistema. Para la mayoría de los usuarios la salida es la única razón para el desarrollo de un sistema y la base de evaluación de su utilidad. (2) Diseño de archivos. En este punto se incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia. (3) Diseño de interacciones con la base de datos. La mayoría de los sistemas de información ya sean implantado en sistemas de cómputos grandes o pequeños, utilizan una base de datos que puede abarcar varias aplicaciones, por esta razón estos sistemas utilizan un administrador de base de datos, en este caso el diseñador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema.
Por otra parte, existen cuatro indicios principales que indican que el software cuenta con un mal diseño, los mismos no son independientes y están relacionados unos con otros, estos indicios son: (1) Rigidez. Es la tendencia del software a ser difícil de cambiar, incluso en las cosas más sencillas. Cada cambio produce una cascada de cambios en módulos dependientes. Lo que parecía un cambio de dos días en un módulo resulta ser varias semanas de cambios de módulos a través de la aplicación. El miedo del gestor puede llegar a ser tan agudo que se niegue a realizar modificaciones en la aplicación. (2) Fragilidad. La fragilidad es la tendencia que tiene el software a romperse por muchos sitios cada vez que se cambia algo. Muchas de las roturas ocurren en sitios que no están relacionados conceptualmente con el área que se está cambiando. Cada vez que los gestores autorizan un cambio tienen miedo de que el programa se rompa por algún lugar inesperado. (3) Inmovilidad. La inmovilidad es la resistencia del software a ser reutilizado en otros proyectos o parte de otros proyectos. Pasa muchas veces que un programador descubre que necesita un módulo que es muy parecido a otro que ha desarrollado otro programador. Sin embargo, también pasa muchas veces que el módulo en cuestión depende demasiado de la aplicación en la que está integrado. Después de mucho trabajo los desarrolladores descubren que el trabajo necesario para separar las partes reutilizables de las partes no reutilizables es demasiado alto. Y entonces el software simplemente se reescribe en vez de ser reutilizado. (4) Viscosidad. La viscosidad del diseño es la dificultad de mantener la filosofía del diseño original. Cuando se afronta un cambio los programadores encuentran normalmente más de una manera de realizarlo. Algunas de estas formas preservan la filosofía del diseño y otras no. Estos cuatro síntomas son reveladores de un diseño de arquitectura pobre. Cualquier aplicación que muestra estos síntomas adolece de un diseño pobre.
Finalmente las causas principales para que el diseño se deteriore son las siguientes: (1) Requisitos cambiantes. La causa de la degradación del diseño es muy conocida. Los requisitos han ido cambiando de manera que no estaba previsto en el diseño inicial. A menudo los cambios necesitan hacerse rápidamente y hechos por programadores que no están familiarizados con el diseño original. Entonces, aunque los cambios funcionan, violan el diseño original. Poco a poco los cambios continúan y las violaciones se acumulan hasta que el diseño se rompe. (2) Control de dependencias. Los cambios que introducen nuevas e imprevistas dependencias hacen que un diseño se deteriore. Para anticiparse a la degradación de las dependencias del diseño de la arquitectura, deben ser controladas las dependencias entre módulos de una aplicación. Este control consiste en la creación de "cortafuegos" de dependencias. A través de estos cortafuegos las dependencias no se propagan. El diseño orientado a objetos está repleto de principios y técnicas que permiten construir estos cortafuegos y controlar estas dependencias.
Guillermo Choque Aspiazu
http://www.eldiario.net/
Agosto 17 de 2009
No hay comentarios:
Publicar un comentario