Definiciones de diseo de sistemas Diseo del Sistema El diseo del sistema es la estrategia de alto nivel para resolver problemas

y construir una solucin. ste incluye decisiones acerca de la organizacin del sistema en subsistemas, la asignacin de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de poltica que son las que constituyen un marco de trabajo para el diseo detallado. El diseo de sistemas es la primera fase de diseo en la cual se selecciona la aproximacin bsica para resolver el problema. Durante el diseo del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organizacin global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones ms detalladas en una fase posterior del diseo. El diseo es el proceso de determinar cual de muchas posibles soluciones es la mejor para lograr lo que se necesita hacer, respetando las restricciones tecnolgicas y de presupuesto del proyecto.

Objetivos del diseo de sistema El buen diseo debe motivar la toma de decisiones ayudando a evaluar alternativas. Todo el diseo es acerca de compromisos. Una tcnica de diseo debe permitir que el diseador evale su decisin contra otras posibilidades. Por ejemplo, usando el modelo de anlisis de eventos acoplado con el esquema de diseo de datos, el diseador puede simular el volumen de lecturas y escrituras a la base de datos para cualquier evento de negocios dado. Esto permite que el equipo evale la factibilidad y desempeo proyectado de una disposicin de tabla de base de datos dada y de un esquema de distribucin de datos antes de construirlos. El diseo necesita ser completo, de tal forma que cubra cada uno de los aspectos principales del software que necesita construirse. Esto causara que se tengan varios tipos diferentes de modelos en la documentacin del diseo. Cada modelo est especializado para mostrar un aspecto particular del sistema. Encontrar que los modeladores son particularmente adeptos de la articulacin de esos aspectos para los que est orientada la tcnica de modelado, pero fallan miserablemente cuando se trata de estirar el modelo ms all de su propsito original. Ningn modelo puede mostrar todas las facetas del sistema funcional completo. Ese sera el sistema mismo. El diseo debe ser verificable antes de su construccin. Uno de los propsitos principales del diseo es revisar y discutir la solucin antes de lanzarse a la carga y codificarla. Parte del proceso de verificacin es su rastreabilidad. Con una buena especificacin del diseo se debe ser capaz de demostrar que se satisfarn los requerimientos del proyecto y as mismo se distinguir entre varias versiones del diseo en cualquier momento.

Una buena metodologa de diseo crea productos diferenciados que son mensurables. Una de las tareas ms difciles de cualquier proyecto es estimar cuando se terminar. Para hacer una estimacin el gerente del proyecto debe tomar medidas, la cual involucra el conteo de cosas que necesitan hacerse y la aplicacin de algn tipo de medida sobre ellas para estimar que tanto tiempo se llevara el hacerlas. La medicin viene, por supuesto, de haber contado estas cosas en el pasado y haber medido que tanto tardo el hacerlas anteriormente. Por lo tanto, una metodologa de diseo debe producir componentes discretos lo ms pronto posible. Por ltimo, pero no menos importante, el diseo debe ser fcilmente aprovechado en el producto final. Debe expresar el uso y la estructura del sistema en una forma muy cercana al resultado pretendido. Este punto puede parecer obvio, pero se ha visto proyectos que trataron de usar tcnicas de diseo que fueron completamente inadecuadas para el lenguaje de destino en el que se codifico el sistema. Usted no querra que su arquitecto casero le presentara un plano que fuera tan esotrico que no le diera idea de la forma que tendra la casa en su terreno. El lema de un diseador es: hacer un mapa de la tcnica hacia el destino. Si el sistema va a operar con una base de datos relacional se deben escoger tcnicas que sean particularmente adecuadas para el diseo de bases de datos relacionales. Si el sistema empleara un lenguaje orientado a objetos, entonces se debern usar tcnicas de diseo orientado a objetos para las partes del sistema que requieren objetos para lograr sus tareas. Si el sistema incluir componentes ms tradicionales, tales como funciones estructuradas en las rutinas cliente o por lotes en el servidor, entonces son adecuadas tcnicas de diseo estructurado ms tradicionales para esas partes del sistema.

Caractersticas del diseo de sistema Existen tres decisiones bsicas en el diseo o la configuracin de un cortafuegos; la primera de ellas, la ms importante, hace referencia a la poltica de seguridad de la organizacin propietaria del firewall: evidentemente, la configuracin y el nivel de seguridad potencial ser distinto en una empresa que utilice un cortafuegos para bloquear todo el trfico externo hacia el dominio de su propiedad (excepto, quizs, las consultas a su pgina web) frente a otra donde slo se intente evitar que los usuarios internos pierdan el tiempo en la red, bloqueando por ejemplo todos los servicios de salida al exterior excepto el correo electrnico.

La segunda decisin de diseo a tener en cuenta es el nivel de monitorizacin, redundancia y control deseado en la organizacin; una vez definida la poltica a seguir, hay que definir cmo implementarla en el cortafuego indicando bsicamente qu se va a permitir y qu se va a denegar. Para esto existen dos aproximaciones generales: o bien se adopta una postura restrictiva (denegamos todo lo que explcitamente no se permita) o bien una permisiva (permitimos todo excepto lo explcitamente negado);

evidentemente es la primera la ms recomendable de cara a la seguridad, pero no siempre es aplicable debido a factores no tcnicos sino humanos (esto es, los usuarios y sus protestas por no poder ejecutar tal o cual aplicacin a travs del firewall).

Por ltimo, la tercera decisin a la hora de instalar un sistema de cortafuegos es meramente econmica: en funcin del valor estimado de lo que deseemos proteger, debemos gastar ms o menos dinero, o no gastar nada. Un firewall puede no entraar gastos extras para la organizacin, o suponer un desembolso de varios millones de pesetas: seguramente un departamento o laboratorio con pocos equipos en su interior puede utilizar un PC con Linux, Solaris o Free BSD a modo de cortafuegos, sin gastarse nada en l (excepto unas horas de trabajo y unas tazas de caf), pero esta aproximacin evidentemente no funciona cuando el sistema a proteger es una red de tamao considerable; en este caso se pueden utilizar sistemas propietarios, que suelen ser caros, o aprovechar los routers de salida de la red, algo ms barato pero que requiere ms tiempo de configuracin que los cortafuegos sobre Unix en PC de los que hemos hablado antes. De cualquier forma, no es recomendable a la hora de evaluar el dinero a invertir en el firewall fijarse slo en el coste de su instalacin y puesta a punto, sino tambin en el de su mantenimiento.

Estas decisiones, aunque concernientes al diseo, eran bsicamente polticas; la primera decisin tcnica a la que nos vamos a enfrentar a la hora de instalar un cortafuego es elemental: Dnde lo situamos para que cumpla eficientemente su cometido. Evidentemente, si aprovechamos como cortafuegos un equipo ya existente en la red, por ejemplo un router, no tenemos muchas posibilidades de eleccin: con toda seguridad hemos de dejarlo donde ya est; si por el contrario utilizamos una mquina Unix con un cortafuego implementado en ella, tenemos varias posibilidades para situarla con respecto a la red externa y a la interna. Sin importar donde situemos al sistema hemos de recordar siempre que los equipos que queden fuera del cortafuegos, en la zona de riesgo, sern igual de vulnerables que antes de instalar el firewall; por eso es posible que si por obligacin hemos tenido que instalar un cortafuegos en un punto que no protege completamente nuestra red, pensemos en aadir cortafuegos internos dentro de la misma, aumentando as la seguridad de las partes mas importantes. Una vez que hemos decidido dnde situar nuestros cortafuegos se debe elegir qu elemento o elementos fsicos utilizar como bastin; para tomar esta decisin existen dos principios bsicos: mnima complejidad y mxima seguridad. Cuanto ms simple sea el host bastin, cuanto menos servicios ofrezca, ms fcil ser su mantenimiento y por tanto mayor su seguridad; mantener esta mquina especialmente asegurada es algo vital para que el cortafuegos funcione correctamente, ya que va a soportar por s sola todos los ataques que se efecten contra nuestra red al ser elemento ms accesible de sta. Si la seguridad de la mquina bastin se ve comprometido, la amenaza se traslada inmediatamente a todos los equipos dentro del permetro de seguridad. Suele ser una

buena opcin elegir como mquina bastin un servidor corriendo alguna versin de Unix (desde una SPARC con Solaris a un simple PC con Linux o Free BSD), ya que aparte de la seguridad del sistema operativo tenemos la ventaja de que la mayor parte de aplicaciones de firewalling han sido desarrolladas y comprobadas desde hace aos sobre Unix.

Evidentemente, a la vez que elegimos un bastin para nuestro cortafuegos hemos de decidir qu elemento utilizar como choke; generalmente suele ser un router con capacidad para filtrar paquetes, aunque tambin puede utilizarse un sistema Unix para realizar esta funcin. En el punto se comentan diferentes arquitecturas de cortafuegos con los elementos utilizados en cada una de ellas como chokes y como bastiones. Metodologa estructurada Es un mtodo formal de divisin de un problema de empresa en fragmentos y relaciones manejables, y la ulterior reunin de estos fragmentos y relaciones en una solucin de empresa til para resolver el problema a) Encuesta: Conocido como estudio de factibilidad, tiene como objetivo identificar a los usuarios responsables y crear un campo de actividad inicial del sistema. Actividades - Hacer entrevistas - Prepara esquema que gue el resto del proyecto - Crear un diagrama de contexto inicial b) El anlisis del sistema: Modelar el ambiente del usuario. Actividades - Diagramas de flujos de datos (DFD) - Diagrama de entidad relacin (DER) - Diagrama de transicin de estado (DTE) c) El diseo: Asignar procesos a las especificaciones generadas en el anlisis. Actividades - Mdulos jerarquizados - Creacin de interface - Definir frontera hombre/mquina

- Transformar el DER en una Base de Datos d) Implantacin: Codificar e integrar mdulos Actividades - Programacin estructurada - Diseo descendente TOP DOWN e) Generacin de pruebas de aceptacin: Lograr la aceptacin de parte del usuario Actividades Prueba ficticios) del sistema con datos (reales, histricos o

f) Descripcin del procedimiento: Describe qu partes del sistema se harn manual y cmo interactuar con la parte automatizada. Actividades - Frontera hombre/mquina - Generacin de manuales g) Conversin de base de datos: Convertir base de datos inicial al modelo generado Actividades - Conversin de BD h) Instalacin: Es un proceso gradual donde los usuarios reciben manuales y entrenamiento y se comienza a usar el nuevo sistema. Actividades - Entrenamiento a usuarios - Uso del nuevo sistema Es til escoger este mtodo cuando el usuario tiene poco claro los requerimientos, ya que es un mtodo bastante grfico lo que facilita la comunicacin analista-usuario.

Metodologa clsico Esta metodologa es buena escogerla cuando el problema es perfectamente conocido, si los desarrolladores tienen experiencia en l y adems el usuario describe claramente los requisitos, en caso contrario los tiempos de desarrollo se vern excedidos.

a) Diagnstico: Identificar al problema y ubicarlo en su medio: Actividades - Cul es el problema? - Ubicuidad del problema - Descripcin del problema - Evaluacin del problema b) Factibilidad: Plantear y evaluar alternativas de solucin al problema identificado: Actividades - Anlisis del problema - Planteamiento de alternativas - Evaluacin de cada alternativa - Evaluacin comparativa entre alternativas c) Diseo Lgico: El desarrollo administrativo de la alternativa seleccionada: Actividades - Conocer los elementos de administracin - Anlisis funcional - Diseo de formularios - Sistema de codificacin d) Diseo Fsico: El desarrollo computacional de la alternativa seleccionada: Actividades - Determinar configuracin computacional - Determinar software - Esquema general o global del sistema - Especificacin de programas - Especificacin de archivos e) Construccin: Generar el cdigo para el sistema:

Actividades - Crear programas - Prueba de programas - Documentacin de programas f) Prueba e implementacin: Probar el sistema e implementar Actividades - Ensamblar programas - Probar base de datos - Probar el sistema - Adiestrar al personal - Puesta en marcha g) Operacin: Utilizar en forma normal el sistema Actividades - Operacin del sistema h) Mantencin: Un control permanente sobre el desempeo del sistema Actividades - Mantencin - Proteccin - Auditora computacional

BLIBLIOGRAFIA

www.monografas.com "Modelado y Diseo Orientados a Objetos" James Rumbaugh et al Ed. Prentice Hall 1997 Octavio Mancilla Gonzlez

Repblica Bolivariana de Venezuela Ministerio del Poder Popular Para la Educacin Superior Instituto Universitario de Tecnologa Jacinto Navarro Vallenilla Problemtica Socioeconmica Venezolana Carpano Estado Sucre

Diseo de Sistemas

Prof.: Marln Gimnez

Integrantes: Arroyo Miguel C.I.: 19.331.301 Guillermo Rojas C.I.: 17.955.951 Yusmary Farfn C.I.: 15.513.316

Carpano, Julio de 2009