¿QUÉ ES EL DISEÑO DE SISTEMAS?

La definición de diseño de sistemas se ofreció ya en el capítulo 3 de este libro.

El diseño de sistemas es la evaluación de las distintas soluciones alternativas y la especificación de una solución detallada de tipo informático. También se conoce por diseño físico.

En esta definición, el término clave es diseño. Mientras que el análisis de sistemas concentra principalmente su interés en los aspectos lógicos, independientes de la implantación, de un sistema (las necesidades), el diseño de sistemas trata los aspectos físicos o dependientes de la implantación del sistema (las especificaciones técnicas de dicho sistema).

El diseño de Sistemas está conducido por diversos especialistas en el diseño de sistemas, incluidos los analistas de sistemas. De aquí que, en el modelo en pirámide, adoptemos en este punto la perspectiva del diseñador de sistemas con respecto a las Personas, los Datos, las Actividades y las Redes. ¿Y qué sucede con el bloque elemental Tecnología? A menudo, esta tecnología ya está implantada o ha sido especificada por una arquitectura tecnológica predefinida (en la planificación de sistemas). En otras situaciones, es el analista quien debe elegir o complementar la tecnología. En todo caso, el diseño de sistemas se basa en los conocimientos adquiridos en las etapas de planificación y análisis de sistemas.

Casi todos nosotros tenemos una visión muy limitada de la definición de los procesos de diseño. Nos imaginamos a nosotros mismos trazando esquemas de los sistemas informáticos para su programación o desarrollo bien por nosotros o bien por nuestros propios programadores. Así, diseñamos las entradas, las salidas, los archivos, las bases de datos y los restantes componentes informáticos. Los encargados de la selección de personal informático para las empresas llaman a esta limitada visión «síndrome del no-inventado-aquí». En realidad, muchas empresas adquieren más software del que escriben sus especialistas internos. No es de extrañar. ¿Por qué razón habría que volver a inventar la rueda? Muchos sistemas son lo suficientemente genéricos como para que los proveedores informáticos puedan escribir paquetes de software adecuados (aunque nunca o rara vez perfectos) susceptibles de ser comprados y posiblemente modificados por las empresas para satisfacer las necesidades de sus usuarios finales.

Por consiguiente, debemos ampliar nuestra definición de proceso de diseño para incluir en ella la evaluación y la selección de soluciones alternativas y la adquisición o compra de software y hardware informático, además del contexto más tradicional de diseño e integración física de componentes de tipo informático. La figura 1 ilustra estas tres fases del diseño de sistemas, que se analizarán en profundidad a lo largo de este capítulo. Para transmitir la sensación de que se hace uso de una auténtica metodología de desarrollo de sistemas, cada fase se describe en función de: (1) el propósito de la fase; (2) las actividades que habrían de realizarse; (3) los papeles desempeñados por las diversas personas que participan en cada actividad; (4) las entradas y las salidas de cada actividad, y (5) las técnicas y métodos que pueden utilizarse para completar cada actividad.

LA FASE DE SELECCIÓN DEL DISEÑO DE SISTEMAS

Una vez obtenidas las necesidades de la empresa con respecto a la elaboración de un sistema de información mejorado, podemos finalmente planear el modo en que funcionará dicho sistema (incluidas sus alternativas de tipo informático). Nunca debería seguirse sin más la primera corazonada que se tenga. Durante la fase de selección, es imperativo identificar y analizar las diversas opciones posibles, y sólo entonces proponer las soluciones más viables sobre la base del análisis realizado.

Bloques elementales en la fase de selección

En la fase de selección, existen dos objetivos fundamentales:

1. Identificar e investigar sobre soluciones alternativas tanto manuales como de tipo informático que puedan servir de apoyo a la obtención del sistema de información objeto.

2. Evaluar la viabilidad de las soluciones alternativas y recomendar la mejor de estas soluciones desde un punto de vista global.

Los bloques elementales de los sistemas de información nos proporcionan un marco de trabajo para acometer la fase de selección. Las soluciones alternativas que han de considerarse deberían ser aquellas que sirvieran para satisfacer las necesidades de empresa con respecto al sistema de información. Recuérdese que en la fase de definición se establecen las necesidades de Personas, Datos, Actividades y Redes del sistema objeto. La fase de selección supone el primer punto del proceso de desarrollo de sistemas donde concentraremos nuestra atención en cómo funcionaría el nuevo sistema. Por tanto, hablaremos del modo en que podría usarse la Tecnología para apoyar la construcción del sistema objeto.

Actividades, papeles y técnicas de la fase de selección

La figura 2 ilustra las actividades típicas de la fase de selección. La presente sección detallará cada una de las actividades de la fase de selección, los papeles desempeñados en ellas por los usuarios y oíros participantes y algunas técnicas de uso común para la selección del objetivo de

diseño

Actividad 1: Especificar soluciones alternativas

Según muestra la figura 2, la fase de selección se inicia a partir de la aprobación para proseguir con el provecto obtenida de la fase de definición. Esta afirmación es coherente con nuestro método de control progresivo del desarrollo de sistemas.

Una vez dadas las necesidades de empresa establecidas en la fase de definición, debemos identificar las soluciones candidatas alternativas. Algunas de estas soluciones candidatas serán encauzadas a través de las ideas y opiniones de diseño expuestas por los propietarios y usuarios del sistema. Otras pueden provenir de diversas fuentes y ser aportadas por analistas de sistemas, diseñadores de sistemas, consultores técnicos y otros profesionales de los sistemas de información. Algunas de las opciones técnicas pueden estar limitadas por una arquitectura tecnológica aprobadapredefinida y suministrada por los directivos responsables del sistema

La cantidad de información que describe las características de cada una de las soluciones candidatas puede ser abundantísima. Una herramienta útil para la localización, organización y comunicación de las características de las soluciones candidatas es una matriz. La figura 3 ilustra una matriz de soluciones candidatas parcialmente completa. Este método permite cotejar una a una las diferentes características de las diversas soluciones candidatas.

Actividad 2: Analizar la viabilidad de las soluciones alternativas

Una vez identificadas las soluciones de diseño candidatas alternativas, ha de analizarse la via-bilidad de cada una de ellas. El análisis de viabilidad no debería limitarse a una evaluación de costes y beneficios. La mayoría de los analistas realiza una valoración de sus soluciones según cuatro conjuntos de criterios:

1. Viabilidad técnica. ¿Es práctica la solución desde un punto de vista técnico? ¿Tiene el personal de la empresa los conocimientos técnicos suficientes para diseñar y poner en marcha esta solución?

2. Viabilidad operativa. ¿Satisfará la solución las necesidades de los usuarios? ¿En qué medida? ¿Hasta qué punto obligará la solución a introducir cambios en el entorno de trabajo? ¿Qué opinan! os usuarios de dicha solución?

3. Viabilidad económica. ¿Resulta eficaz la solución en términos de coste? 4. Viabilidad de calendario. ¿Puede la solución diseñarse e implantarse en un período de

tiempo aceptable? Los analistas de sistemas deben trabajar muy en contacto con los

propietarios y los usuarios de los sistemas cuando realizan una evaluación de soluciones candidatas. Lasactitudes y opiniones de los propietarios y los usuarios del sistema son particularmente importantes a la hora de medir la viabilidad operativa de las soluciones candidatas. El análisis de viabilidad resultante refleja a menudo la participación de una serie de personas más. Para ayudar a la determinación de la viabilidad técnica de las soluciones candidatas, a menudo se buscan las opiniones técnicas de los directores de sistemas y del personal técnico. Además, la información sobre costes y beneficios puede ser suministrada por muchas y variadas fuentes. Una vez más, es posible utilizar una matriz como medio de comunicación del amplio volumen de información referido a las soluciones candidatas. La matriz que muestra la figura 4 permite cotejar los resultados de los análisis de viabilidad asociados a las diversas so-kiones candidatas. Mientras se construye la matriz de viabilidad, el analista y los usuarios han de procurar no hacer comparaciones entre las soluciones candidatas. El análisis de viabilidad se lleva a cabo de forma individual para cada solución candidata, sin tener en cuenta viabilidad de otras posibles soluciones. Esta forma de actuar pretende evitar que el analista y los usuarios adopten decisiones prematuras sobre cuál de las candidatas es la mejor solución.

La capacidad para llevar a cabo una evaluación de viabilidad es un requisito técnico ex-tremadamente importante. En la Parte quinta, Módulo C, Análisis de viabilidad, se ofrece un tratamiento más en detalle de las técnicas y los métodos de evaluación de viabilidad.

Actividad 3: Recomendar una solución para el sistema

Una vez terminado el análisis de viabilidad para cada solución candidata, puede seleccionarse cuál de estas soluciones será la recomendada. En primer lugar, se suelen eliminar de toda consideración las soluciones candidatas no viables. En busca de la solución más viable entre las restantes, se identificará y recomendará aquella candidata que ofrezca la mejor combinación de viabilidades técnica, operativa, económica y de calendario.

Como de costumbre, puede usarse una herramienta matricial para apoyar la toma de decisión. La matriz utilizada puede simplemente contener un baremo (por ejemplo, un valor del 85% en una escala del 1 al 100%) o un orden de clasificación (primero, segundo, tercero, etc.) de viabilidad para cada solución candidata. La figura 5 muestra un ejemplo de una matriz de baremo. Es labor del analista y los usuarios determinar el peso que debería utilizarse para fijar los criterios de viabilidad. Una vez definidos éstos, la matriz ofrece la posibilidad de cotejar los valores de las distintas soluciones candidatas para facilitar la identificación de la elección mejor desde un punto de vista general.

El producto clave resultante de la fase de selección es una propuesta de sistema formal, ya sea verbal o escrita. Esta propuesta es enviada a los propietarios del sistema, quienes se encargan por lo general de tomar la decisión final. La propuesta contendrá los planes, estimaciones de tamaño, soluciones candidatas v análisis de viabilidad del provecto. Sobre la base del resultado de esta propuesta, se fijarán los requisitos de cambios al diseño propuesto para los componentes del nuevo sistema que hayan de «comprarse» o «elaborarse».