DISEÑO DE SISTEMAS

GRUPO: 1

Alexander Plata 2014-1473

Garys Javier 2011-2247

Prof: MORILLO GEDHARD CONRADO

ANALISIS Y DISEÑO DE SISTEMAS II

DISEÑO DE SISTEMAS

¿Que es el diseño de sistemas?

Son las tareas que se enfocan en la especificación de una solución computarizada detallada. También se le llama diseño físico.

En los sistemas se diseñan entradas, salidas, archivos, bases de datos y otros componentes de computadora. Los reclutadores de especialistas en cómputo recién egresados de las universidades se refieren a esta definición restrictiva como el “síndrome de no se inventó aquí”.

Estrategias del diseño de sistemas

Estas estrategias Abarca el diseño estructurado moderno, ingeniería de la información, elaboración de prototipos, JAD, RAD y diseño orientado a objetos. La intención es desarrollar únicamente un alto nivel de entendimiento.

Estrategias basadas en modelos

El diseño basado en modelos pone énfasis en el trazado de modelos de sistema pictóricos para documentar los aspectos técnicos o de implantación de un nuevo sistema.

Ejemplo de estrategias basadas en modelos: El diseño estructurado, la ingeniería de la información y el diseño orientado a objetos.

Los modelos de diseño suelen derivarse de modelos lógicos que se desarrollan en una parte previa de la obra, también se convierten en planos para la construcción e implantación del nuevo sistema.

Las estrategias basadas en modelos se mejoran con el uso de herramientas automatizadas, tales como: Visio Professional o Corel Flow para modelos del sistema con software de gráficos de propósito general. Otros diseñadores y organizaciones requieren el uso de herramientas CASE basado en repositorios o herramientas de modelado, como System Architect, Microsoft Visio, Visible Analyst o Rational de IBM. Las herramientas de CASE brindan consistencia e integridad, además de verificación de errores basada en reglas.

Diseño estructurado moderno: es una técnica orientada a procesos para dividir un programa grande en una jerarquía de módulos, lo que da por resultado un programa de computadoras más fácil de implantar y mantener. Sus sinónimos son diseño descendente de programas y programación estructurada.

El diseño estructurado busca dividir un programa en una jerarquía descendente de módulos que tengan las propiedades siguientes:

Deben tener mucha cohesión, es decir, cada módulo debe encargarse de una y sólo una función. Esto hace que los módulos sean reutilizables en programas futuros.

Deben acoplarse, lo cual significa que su dependencia mutua debe ser mínima. Ello minimiza el efecto que los cambios futuros en un módulo tendrán en otros módulos.

Ingeniería de la información: es una técnica de planeación, análisis y diseño de sistemas de información basada en modelos y centrada en datos, si bien es sensible a procesos. La herramienta principal de la IE es un diagrama de modelo de datos.

Imagen del producto final del diseño estructurado:

Elaboración de prototipos: Los analistas trazan imágenes que muestran la distribución o estructura de salidas, entradas y bases de datos, así como el flujo de diálogos y procedimientos. Se trata de un proceso muy tardado, propenso a errores y omisiones considerables y es frecuente a que las especificaciones en papel resulten inadecuadas, incompletas o imprecisas.

Ejemplo de diagrama físico de entidad-relación de la ingeniería de la información:

Ventajas:

Los prototipos alientan y requieren la participación activa del usuario final. La iteración y cambio son consecuencia natural del desarrollo de sistemas, es decir,

los usuarios finales tienden a cambiar de parecer. Se ha afirmado frecuentemente que los usuarios finales no conocen plenamente

sus Los prototipos son modelos activos, no pasivos, que el usuario final puede ver,

tocar, sentir y experimentar. Un prototipo aprobado es un equivalente funcional de una especificación de

diseño en papel, con una salvedad: los errores se pueden detectar con mucha mayor anticipación.

Los prototipos pueden aumentar la creatividad, ya que posibilitan la retroalimentación de los usuarios con mayor prontitud, lo que puede llevar a mejores soluciones.

Los prototipos aceleran varias fases del ciclo de vida, posiblemente bypassing del programador.

Desventajas:

Los prototipos fomentan el regreso al ciclo de vida de “codificar, implantar y reparar” que en otros tiempos predominaba en los sistemas de información.

Los prototipos no niegan la necesidad de las fases del análisis de sistemas. No es posible sustituir por completo las especificaciones en papel con un

prototipo. Son muchos los problemas de diseño que no se solucionan con los prototipos. Los prototipos suelen llevar al compromiso prematuro con un diseño. Durante la elaboración del prototipo, el alcance y la complejidad del sistema

pueden ampliarse rápidamente más allá de los planes originales. Los prototipos pueden reducir la creatividad en el diseño. Los prototipos suelen tener funcionamiento más lento que sus equivalentes de

lenguajes de tercera generación.

Diseño orientado a objeto: es la estrategia de diseño de advenimiento más reciente.

Las técnicas de OOD se usan para refinar las definiciones de requerimientos de objetos identificadas con anterioridad, durante el análisis, y para definir objetos de diseño específico.

Ejemplo pantalla prototipo:

Desarrollo rápido de aplicaciones

Es la fusión de varias técnicas estructuradas con técnicas de prototipos y de desarrollo conjunto de aplicaciones para agilizar el desarrollo de sistemas. Es una de las estrategias de diseño muy utilizada en la actualidad.

También precisa el uso interactivo de técnicas estructuradas y la elaboración de prototipos para definir los requerimientos de los usuarios y el diseño del sistema final. La aceleración del diseño se logra mediante el énfasis en la participación del usuario en las sesiones de desarrollo conjunto de aplicaciones.

Esta misma, es una técnica que se complementa con otras de análisis y diseño de sistemas al hacer énfasis en el desarrollo participativo de los propietarios, usuarios, diseñadores y constructores del sistema.

Estrategias de diseño de sistemas FAST

Este método integra todas las estrategias más utilizadas.

Las técnicas de análisis de sistemas se aplican en el marco de referencia de:

Los componentes del sistema de información del lector. Las fases del desarrollo de sistemas. Las tareas de ejecución de una fase.

Diseño de sistemas para desarrollo en la organización: la solución de “construcción”

Una propuesta de sistema aprobada luego de la fase de análisis da lugar a la fase de diseño. Esta última tiene dos objetivos. Primero, que el analista busca diseñar un sistema que satisfaga los requerimientos y sea amigable con los usuarios finales. La ingeniería humana desempeña una función clave en el diseño. Segundo, y también muy importante, que el analista intenta presentar especificaciones claras y completas a los técnicos y programadores de computación.

Diseño de la arquitectura de la aplicación

El propósito de la primera tarea de diseño es especificar la arquitectura de aplicaciones. La arquitectura de la aplicación define las tecnologías que se usarán en uno, más o todos los sistemas de información (y que se aplicarán en su construcción) con base en sus datos, procesos, interfaces y componentes de redes. Así pues, diseñar la arquitectura de la aplicación requiere considerar las tecnologías de red y la toma de decisiones sobre cómo se distribuirán los DATOS, PROCESOS e INTERFACES del sistema entre las ubicaciones del negocio. Esa tarea se logra mediante el análisis de los modelos de datos y procesos creados inicialmente durante el análisis de requerimientos. Dados los modelos de datos y de procesos, así como la solución prevista, es necesario tomar decisiones de distribución.

Diseño de las bases de datos del sistema

Es común que la siguiente tarea en el diseño del sistema sea desarrollar las especificaciones de diseño de las bases de datos correspondientes. El diseño de los datos va mucho más allá de la simple distribución de registros. Las bases de datos son un recurso compartido. Es habitual que muchos programadores las utilicen. Programas futuros podrían recurrir a bases de datos de maneras no previstas originalmente. Por ende, el diseñador debe prestar atención especial a diseñar bases de datos que sean adaptables a requerimientos y expansiones futuras.

Diseño de la interfaz del sistema

Una vez diseñada la base de datos y, posiblemente, construido el prototipo, el diseñador de sistemas puede colaborar estrechamente con los usuarios del sistema en el desarrollo de las especificaciones de entradas, salidas y diálogos. Los usuarios finales y administradores tendrán que trabajar con las entradas y salidas, por lo que los diseñadores deben tener cuidado de solicitar sus ideas y sugerencias, particularmente en relación con el formato. Asimismo, deben buscar esas ideas y opiniones acerca de diálogos de fácil aprendizaje y uso para el nuevo sistema.

Especificaciones de diseño del paquete

Esta tarea final de diseño involucra la integración de todas las especificaciones de las tareas de diseño previas en un conjunto de especificaciones que sirva de guía para las actividades del programador durante la fase de construcción de la metodología de desarrollo de sistemas. Sin embargo, esta tarea es mucho mayor que la de formar un paquete. El qué tan mayor sea depende de dos factores: 1) dónde se marca la línea entre las responsabilidades del diseñador y el programador del sistema, y 2) si el método y solución requiere del diseño de la estructura global del sistema o no. Muchas organizaciones han adoptado estrategias de desarrollo acelerado de sistemas que no requieren el segundo de estos factores. La estructura de programas se encargaba de aspectos de calidad que preocupaban a los desarrolladores de sistemas que usaban lenguajes de programación antiguos y tendían a ser aplicaciones basadas en las mainframe.

Actualización del plan del proyecto

Ahora que nos acercamos al final de la fase de diseño, es necesario que reevaluemos la factibilidad del proyecto y actualicemos así mismo el plan del proyecto. El administrador del proyecto, junto con los PROPIETARIOS DEL SISTEMA y el equipo del proyecto en su totalidad, facilita esta tarea. Los ANALISTAS y PROPIETARIOS DEL SISTEMA son clave en ella. Deben considerar la posibilidad, con base en el trabajo de diseño terminado, de que puedan requerirse ajustes al calendario global del proyecto y a las estimaciones de costos, entre otras.

Diseño de sistemas para integrar software comercial: La solución de “compra”

Cuando se requiere software nuevo, la elección de los productos apropiados suele dificultarse. Las decisiones se complican por factores técnicos, económicos y políticos. Una decisión errónea puede estropear el análisis y el diseño por exitosos que sean. El analista de sistemas participa cada vez más en la compra de paquetes de software (así como de periféricos y computadoras para soporte a las aplicaciones específicas que desarrolla el propio analista).

Los propósitos de las fases de compra y análisis de decisiones son los siguientes:

1. Identificar e investigar productos específicos que puedan soportar la solución recomendada para el sistema de información requerido.

2. Solicitar, evaluar y jerarquizar las propuestas de proveedores.

3. Elegir y recomendar la mejor propuesta de los proveedores

. 4. Firmar el contrato con el vendedor elegido para obtener el producto.

Tareas del diseño para integral software comercial:

Investigación de criterios y opciones técnicas

La primera tarea consiste en investigar las opciones técnicas. En ella, se identifican especificaciones de importancia en relación con el software o el hardware que se elegirá. Esta tarea se enfoca en los requerimientos de software o hardware que se establecen en la fase de análisis de requerimientos. Tales requerimientos detallan la funcionalidad, las características y los parámetros de desempeño críticos del nuevo software/hardware. Muchos analistas consultan revistas y otras publicaciones periódicas apropiadas, además de Internet, como ayuda para identificar las especificaciones y problemas técnicos y de negocios que revisten importancia para la decisión de la elección.

Solicitar propuestas o cotizaciones a los proveedores

La tarea siguiente consiste en solicitar propuestas o cotizaciones a los proveedores. Si la organización tiene un compromiso de compra con una sola fuente (por ejemplo, IBM), la tarea es más bien informal. Basta ponerse en contacto con el proveedor y solicitar cotizaciones de precios y condiciones. Sin embargo, muchas decisiones comprenden numerosas alternativas. En esta situación, el sentido común de negocios indica sacar ventaja de la competencia existente en el mercado. La tarea de solicitud de propuestas requiere preparar uno de dos documentos: una solicitud de cotizaciones (RFQ, por sus siglas en inglés) o una solicitud de propuestas (RFP, por sus siglas en inglés). La solicitud de cotizaciones se usa cuando ya se ha tomado una decisión sobre el producto específico, sin embargo éste se puede adquirir con varios proveedores. Su finalidad principal es obtener datos específicos de configuraciones, precios, convenios de mantenimiento, condiciones relativas a cambios que realicen los compradores, y el servicio. La solicitud de propuestas se utiliza cuando diversos proveedores o productos son posibles candidatos y nos interesa obtener propuestas y cotizaciones competidoras. Las RFP pueden considerarse como un súper conjunto de las RFQ. En ambos tipos de solicitudes se definen criterios de selección que se usan en una validación posterior.

Validación de las afirmaciones y desempeño de los proveedores

Las propuestas o cotizaciones se empiezan a recibir poco después de enviar las RFP o RFQ a los posibles proveedores. La validez de las propuestas no se puede ni se debe dar por sentada, sino que deben validarse las afirmaciones y el desempeño de los proveedores. Esta tarea se realiza de manera independiente para cada propuesta, sin que se comparen entre sí las propuestas. El propósito de esta tarea es validar las solicitudes en relación con las propuestas o cotizaciones que se reciben de los proveedores. Los DISEÑADORES DE SISTEMAS son responsables de llevar a cabo esta actividad. Una vez más, en tal validación el diseñador puede solicitar el apoyo de los administradores de datos, bases de datos, redes y aplicaciones. Esta tarea se genera con la recepción de propuestas o cotizaciones

de los posibles proveedores. Las salidas clave de la tarea son las propuestas validadas de proveedores y otras cuyas afirmaciones no se validaron.

Evaluar y jerarquizar las propuestas de los proveedores

Ahora es posible evaluar y jerarquizar las propuestas validadas. En realidad, se trata de dos pasos que constituyen otro análisis de costo-beneficio como el realizado durante el desarrollo de sistemas. Los criterios de evaluación y calificación deben establecerse antes de que ocurra la evaluación, de modo que no se incluya un sesgo de los criterios y calificaciones para favorecer inconscientemente una propuesta dada. El patrocinador ejecutivo debe facilitar, en teoría, esta actividad. El diseñador puede hacer que participen varios expertos en la evaluación y jerarquización de las propuestas, una vez más con la posible inclusión de los administradores de datos, bases de datos, redes y aplicaciones. Las entradas de esta tarea incluyen las propuestas validadas y criterios de evaluación usados para jerarquizar las propuestas. El producto clave de esta tarea consiste en las recomendaciones de hardware o software.

Otorgamiento del contrato y junta informativa a proveedores

Una vez jerarquizadas las propuestas de los proveedores, la actividad siguiente suele incluir la presentación de recomendaciones a los administradores para su aprobación final. De nuevo, revisten importancia las habilidades de comunicación, en particular las de venta, si el analista pretende convencer a los administradores de que usen sus recomendaciones. Una vez que se cuente con la aprobación de las recomendaciones hechas a los administradores, lo siguiente es redactar el contrato y otorgarlo al proveedor elegido. Esta actividad también suele incluir una sesión de informativa a los proveedores que no fueron seleccionados, en la que deberá tenerse cuidado de no romper las relaciones que se tienen con ellos. El propósito de esta actividad es negociar un contrato con el proveedor que presentó la propuesta ganadora e informar a los proveedores cuyas propuestas no se eligieron. En teoría, el patrocinador ejecutivo que debe aprobar las recomendaciones y la cancelación del proyecto también ha de facilitar esta actividad. Sin embargo, es el DISEÑADOR DEL SISTEMA quien tiene que elaborar y defender la recomendación, así como otorgar el contrato. En dicha actividad, el diseñador puede solicitar el apoyo de un abogado de la organización para redactar el contrato. Las habilidades de redacción de informes y de presentación son importantes en esta tarea.

Impacto de la decisión de compra en las fases restantes del ciclo de vida de sistemas

No basta simplemente con comprar o construir (desarrollar) sistemas que satisfagan los requerimientos del sistema deseado. El análisis debe integrar o comunicar el nuevo sistema con los numerosos sistemas existentes que son esenciales para la empresa. Muchos de estos sistemas incluyen el uso de tecnologías, técnicas y estructuras de archivos con diferencias impresionantes entre ellos.

El analista debe considerar la forma en que el sistema deseado encaja en el conjunto de sistemas del que forma parte. Los requerimientos de integración especificados son vitales para garantizar que el nuevo sistema funcione en armonía con los demás.

Una vez terminada la fase de análisis de decisiones (relativas a software y servicios) y su evaluación intensiva del producto comercial, se tienen conocimientos acerca de sus características (o deficiencias). Es durante la fase de análisis de decisiones para la integración que es preciso hacer revisiones para reflejar estos nuevos conocimientos en los modelos de datos y procesos que comprende la definición de requerimientos del negocio. Cuando se recibe el software y los servicios del proveedor o proveedores, hay que ponerlos en práctica. Durante esta implantación, pueden surgir problemas de integración que también deben reflejarse en la definición de requerimientos del negocio. Estas capacidades y problemas de integración se incluyen en los requerimientos de diseño e integración.

Por último, una vez que se cuenta con los requerimientos de diseño e integración, hay que completar la fase de diseño. Esto requiere de muchas de las mismas tareas que son tema de páginas anteriores de este capítulo. La diferencia principal radica en que no se está “desarrollando” simplemente un sistema completo. En su lugar, podrían estarse diseñando especificaciones técnicas para el desarrollo de un pequeño subconjunto de programas, utilerías de software y otros componentes que son necesarios para que los procesos del negocio y el productor de software comercial se integren y funcionen apropiadamente.