UNIVERIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD

ESCUELA DE CIENCIAS BASICAS, TECNOLOGIA EINGENIERIA

DISEÑO DE SISTEMAS

GERMAN RUIZ CAÑIZARES

CODIGO 12980466

GRUPO 301309-30

PASTO, SEPTIEMBRE 05 DE 2019

 INTRODUCCION

El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una
solución. Éste incluye decisiones acerca de la organización del sistema en subsistemas, la
asignación de subsistemas a componentes hardware y software, y decisiones fundamentales
conceptuales y de política que son las que constituyen un marco de trabajo para el diseño
detallado

La organización global del sistema es lo que se denomina la arquitectura del sistema. Existe un
cierto número de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para
ciertas clases de aplicaciones. Una forma de caracterizar una aplicación es por la importancia
relativa de sus modelos de objetos, dinámico y funcional. Las distintas arquitecturas ponen
distintos grados de énfasis en los tres modelos.

El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica

para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global.
La arquitectura del sistema es la organización global del mismo en componentes llamados
subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más
detalladas en una fase posterior del diseño

Objetivo:

Realizar una actualizacion del perfil, como tambien generar mapas mentales de los entornos del
curso de diseño de sistemas y otro de las unidades uno y dos
SEIS ENTORNOS:
Información inicial:

 Carpeta Cómo surfear en el curso

 Agenda del curso Página
 Carpeta Presentación del curso
 Consulta Reglas y condiciones para el desarrollo del curso
 Noticias del Curso
 Foro General

Entorno de conocimiento

 Carpeta Plan de estudios del curso Diseño de sistemas

 Unidad 1 - Conceptos y principios básicos de diseño
 Unidad 2 - Diseño orientado a objetos y componentes.
 Glosario

Entorno de aprendizaje colaborativo

Taller: Paso 1 - Identificación de las partes interesadas y los entornos del curso virtual.

 Unidad 1: Paso 2 - Conceptos y principios básicos de diseño

 Unidad 2: Paso 3 - Diseño orientado a objetos y componentes.
 Unidad 2: Paso 4 - Diseño orientado a objetos y componentes.
 Guía de actividades y rúbrica de evaluación - Paso 4 - Diseño orientado a objetos y
componentes Carpeta

Practica el entorno de aprendizaje

 Guía para el uso de recursos educativos - Sopa de letras

 Recurso educativo Unidad 1 - Sopa de letras - Conceptos y principios básicos del diseño de
sistemas Página
 Recurso educativo Unidad 2 - Sopa de letras - Diseño orientado a objetos y componentes
Página

Monitoreo y evaluación Medio ambiente

 e-portafolio Diario
 Paso 1 - Identificación de los interesados y entornos del curso virtual - Enviar actividad
 Paso 2 - Conceptos y principios básicos de diseño - Presentar actividad Tarea
 Paso 3 - Diseño orientado a objetos y componentes - Enviar actividad Tarea
 Paso 4 - Diseño orientado a objetos y componentes - Enviar actividad Tarea

Entorno de gestión del alumno

Noticias académicas

 Horario Laboratorios
 Programas e inscripciones educativas
 Saber Pro - ICFES
 El sistema de gestión de la investigación - URL SIGI
 Red de estudiantes
 Formato de aplicación único: FUS
 Inscripciones e inscripciones educativas
  Proceso de autenticación de campus virtual
 Servicios estudiantiles
 Servicios de la UNAD
 Sistema de Servicios al Usuario - SAU
 Sistema Nacional de Registro y Control Académico

3 EL ENTORNO DONDE SE CAGAN LAS ACTIVIDADES INDICIDUALES Y DE COLABORACION E SEL

ENTRONO

4 para saber del tutor en ULTIMA S NOTICIAS BIENVENIDA

Diseño de Sistemas: Es el arte de definir la arquitectura de hardware y
software, componentes, módulos y datos de un sistema de cómputo para
satisfacer ciertos requerimientos. El diseño es el proceso creativo de
transformación del problema en una solución; la descripción de una solución
también se denomina diseño. La solución será la que satisface todos los
requerimientos planteados en la especificación de requerimientos. Las
soluciones en muchos casos son ilimitadas. El diseño de sistemas es el arte de
definir la arquitectura de hardware y software, componentes, módulos y
datos de un sistema de cómputo, a efectos de satisfacer ciertos
requerimientos.

Requerimientos comunes

Los sistemas deben cumplir con ciertos requerimientos comunes, de modo

que son una guía para cualquier analista.

Calidad. El nuevo sistema debe ser valioso en cuanto a calidad de

información, redundancia mínima, facilidad operativa, controles suficientes y
eficiencia. Mientras mejor cumpla estos aspectos, más calidad tendrá el
nuevo sistema en sí mismo y más calidad tendrá el servicio que preste a los
usuarios directos e indirectos. Las consideraciones realizadas al analizar los
hechos del sistema actual contribuyen a aplicar este criterio.

Flexibilidad. Los cambios internos y externos de la institución pueden ser

radicales, convirtiendo en obsoleto el sistema actual de un momento para
otro. Pero la mayoría de los cambios son menores, de modo que el nuevo
sistema debe ser lo suficiente- mente flexible para poder adaptarse a ellos.

Adaptación tecnológica. La calidad del nuevo sistema depende de la

tecnología empleada. La disponibilidad de tecnología en hardware y software
puede cambiar radicalmente la forma de encarar el nuevo sistema. Si la
tecnología ideal tiene un precio inalcanzable, habrá que considerar la mejor
tecnología dentro de la capacidad financiera de la institución, que se adecue
a los requerimientos. La carencia de tecnología adecuada puede hacer
imposible un nuevo sistema de calidad.

Realismo. Los requerimientos deben adecuarse a la realidad de la empresa.

No es posible pensar en procesos que exijan lenguajes desconocidos por los
programado- res disponibles; en el manejo de software complejo por
empleados cuyo nivel intelectual es insuficiente; en formas de trabajo que
impongan cambios culturales improbables; etc.

Requerimientos específicos

Estos requerimientos dependen de cada sistema particular, por lo que deben

anotar- se para no olvidarlos al diseñar el nuevo sistema. Para ordenar su
exposición, usa- remos las categorías ya vistas de salidas, procesos, entradas,
archivos y circunstancias.

Salidas. Hemos visto que, al considerar con los usuarios los informes
producidos por el sistema actual, el analista trabajó sobre los impresos o
pantallas, anotando errores, sugerencias y correcciones. Al tratar informes
inexistentes pero necesarios, seguramente bosquejó con el usuario cómo
deberían ser, con anotaciones sobre cómo obtener determinados resultados.
Estos papeles de trabajo sirven de base para establecer los requerimientos
de salida del nuevo sistema. Obviamente los deberá volver a estudiar y pasar
en limpio. Si hace falta aclarar cómo se obtienen ciertos da- tos de estas
salidas, puede incluir notas aclaratorias. Estos prediseños le van a servir para
precisar el diseño definitivo, más exacto, que usarán los programadores. Si
hay que producir archivos requeridos por otras instituciones, deberá
determinar sus datos y formatos, como las declaraciones de retenciones
impositivas a presentar a AFIP y DGR, o las normas de ciertos bancos para
cobranza de facturas.

Procesos. Los requerimientos de procesos en parte se obtienen de lo que

hacen los programas del sistema actual. En el nuevo sistema estos procesos
pueden sufrir fuertes modificaciones para hacerlos más efectivos,
unificándolos, dividiéndolos, asignándolos a programas diferentes. Pueden
necesitarse nuevos procesos para producir nuevas salidas o controlar
aspectos ignorados en el sistema actual. El analista debe establecer
principalmente en qué consistirán los controles y los métodos de cálculos,
con todas las variedades de condiciones a que están sometidos. Si estos
controles y cálculos usan datos auxiliares, como escalas salariales,
impositivas, tarifarias, debe precisar la estructura de estos datos, lo que le
servirá para introducir- los como parte de los nuevos programas o como
tablas externas. Para no demorar su tarea, debe considerar los
requerimientos que no sean de rutina. Estos procesos deberán ser detallados
al especificar los nuevos programas, para que los programa- dores los
desarrollen. Para no olvidarlos, puede usar listas que haya ido
confeccionando en experiencias anteriores.

Entradas. Se refieren a los formularios de papel y las ventanas usados para

capturar o transcribir datos. Similar a lo que sucede con las salidas, los
requerimientos pueden expresarse como bosquejos en limpio, con notas
aclaratorias. Los procesos de validación pueden incluirse aquí o en los
procesos de control. Si la validación se hace por rangos, listas de valores,
dígitos verificadores u otros mecanismos, éstos son un requerimiento. Si los
datos de entrada se ingresan como códigos, los códigos son un
requerimiento.
Archivos. Estos requerimientos son los datos capturados que va a manejar el
nuevo sistema, que se conservarán en tablas. Esos datos están entre los que
posee el sistema actual más los que deban ser incorporados para producir
información ahora in- existente. El analista tiene los primeros en los listados
de las estructuras de las tablas actuales. Los datos nuevos surgen de la nueva
información a producir y conviene listarlos. En cuanto al diseño de los
registros, es una tarea reservada a la etapa de diseño.

Circunstancias. Cuando haya leyes, decretos, resoluciones, contratos, normas

in- ternas, etc., que condicionen el diseño del nuevo sistema, son requisitos
que no deben olvidarse. Para ello, puede usarse directamente esta
documentación; pero pue- de ser más práctico resumir lo esencial, evitando
la búsqueda complicada en los textos originales.

Los directivos pueden querer que el nuevo sistema posea determinadas

características, como el uso de claves de seguridad, o que permita vender a
través de Internet, transformando en usuarios directos a los compradores; o
que automatice la captura de datos de pago mediante códigos de barra; etc.
Estas circunstancias son también requerimientos.

Las sugerencias de los usuarios aceptadas por el analista, forman también

requerimientos para el nuevo sistema.

CARACTERÍSTICAS DISEÑO DE SISTEMAS Eficacia. Facilidad de uso. Ahorro.

Detección de Fallos. Clasificación de información. Identificación de
necesidades del cliente

Los diagramas de casos de uso sirven para especificar la comunicación y el

comportamiento de un sistema mediante su interacción con los usuarios y/u
otros sistemas. O lo que es igual, un diagrama que muestra la relación entre
los actores y los casos de uso en un sistema.

En otras palabras, un caso de uso es una secuencia de interacciones que se

desarrollarán entre un sistema y sus actores en respuesta a un evento que
inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicación y el comportamiento de un
sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que
es igual, un diagrama que muestra la relación entre los actores y los casos de
uso en un sistema. Una relación es una conexión entre los elementos del
modelo, por ejemplo la especialización y la generalización son relaciones. Los
diagramas de casos de uso se utilizan para ilustrar los requerimientos del
sistema al mostrar cómo reacciona a eventos que se producen en su ámbito
o en él mismo.
 BIBLIOGRAFIA

[Link]

[Link]