Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Desarrollo estructurado

1,845 views

Published on

  • Be the first to comment

  • Be the first to like this

Desarrollo estructurado

  1. 1. Universidad Fermín Toro Vice-rectorado Académico Facultad de Ingeniería Escuela de Computación DISEÑO ESTRUCTURADO (UNIDAD II) Autor: Wilcar A. Rojas C.I: 13.313.297CABUDARE, NOVIEMBRE 2012
  2. 2. Desarrollo Estructurado El desarrollo estructurado comenzó con la programación. A mediados de los60 el enfoque estructurado se extiende a la fase de diseño que se conoce comodiseño estructurado, el cual se basa en definir una abstracción más amplia usandolos módulos de programa como componentes básicos de construcción. A mediadosde los 70, se empezaron a surgir las técnicas estructuradas, donde se empezó aconstruir programas de una forma artesanal con métodos de ingeniería. Eldesarrollo estructurado permitió facilitar la comprensión de programas, normaspara la aplicación de estructuras de datos y de control. En el diseño estructurado se caracteriza por lo siguiente: Mayor nivel de abstracción (independencia del lenguaje programación). Elemento básico de diseño: módulo. Modularidad que permite medir la calidad de programas. Representa los procesos, flujos y estructuras de datos, de una manera jerárquica y descendente. Ven el sistema como entradas-proceso-salidas. Se concentran en la parte del proceso. Se lee de porciones, independientes de las especificaciones.Aunque este desarrollo permite diseñar un buen proceso y estructura de unprograma, tiene inconvenientes como: Leer todas las especificaciones para entender el problema. Se repetía la misma información en partes diferentes del documento. El enfoque de requisitos se interpretaba diferente por cada usuario. Cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas. Este enfoque se conoce como análisis estructurado o análisis descendente otop - down. Desde su aparición se han hecho mejoras como dar menorimportancia a la construcción de los modelos físicos actuales y a los modeloslógicos actuales, diferenciar más los modelos físicos y lógicos. Ampliar las técnicas
  3. 3. de análisis estructurado, para modelar sistemas en tiempo real y enfocarse en elmodelo de datos. En el desarrollo estructurado los programas están divididos en distintosbloques, estos bloques tienen funciones que se van confeccionado en forma dearriba-abajo, empezando desde las generales hasta las particulares, hasta llegar adetallar cada uno de los procedimientos y su interacción. Este desarrollo se enfocaal diseño del programa y la compresión se hace mas fácil. Se ha hecho evidenteque este enfoque aun está un poco arraigado ya que se tiende a no pasar de unproceso o iteración a otra, sin culminar con la anterior, ademas que el ciclo de vidadebe recorrerse completo y al manejarse de esta manera, trae comoconsecuencias información redundante, costos y desperdicio de tiempo. Desarrollo Orientado a Objetos El desarrollo del paradigma de Orientado a Objetos (OO) trata los procesosy datos de forma conjunta. Este comienza a mediados de los 80 con los lenguajesde programación Orienta a Objetos en los que se daba énfasis a la abstracción dedatos para los que se adjuntaba un conjunto de operaciones. Por otra parte losconceptos de técnicas estructuradas han servido de base para muchas de lasmetodológicas OO. La orientación a objetos empieza con los lenguajes de programaciónorientados a objetos; en estos lenguajes los problemas del mundo real serepresentan como un conjunto de objetos para los que se adjuntan un conjunto deoperaciones. Ej. C++, Java, entre otros. En la metodología orientada a objetos el sistema se organiza como unacolección de objetos que interactúan entre sí y que contienen tanto estructuras dedatos como un comportamiento. Esto se opone a la programación convencional, enla cual las estructuras de datos y el comportamiento solamente están relacionadasde forma débil, ya que estos se enfocan principalmente a las funciones.
  4. 4. Los principios del modelo OO son: Abstracción: Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulación: En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus características esenciales. Modularidad: Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes. Jerarquía o herencia: Es el orden de las abstracciones organizado por niveles. Tipificación: Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia: Es la propiedad que distingue un objeto que está activo de uno que no lo está. Persistencia: Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado). Booch (1986) dice que “si un modelo que se dice OO no contiene alguno delos primeros cuatro elementos, entonces no es Orientado a Objetos”. El desarrollo orientado a objetos comprende dividir un programa en clases,donde estas clases estarán estructuradas por propiedades, atributos, variables,pretendiendo simular y describir de manera conceptual a un objeto, y loimportante de este desarrollo es que al usar el principio de encapsulamientoproporciona la ventaja de que se evite interferencias extrañas entre distintaspartes del programa y podemos cambiar la implementación concreta de un objetosin afectar al resto del sistema. Actualmente este desarrollo es el que esta
  5. 5. aflorando más en los aspectos de desarrollo de software ya que permite crear unmodelo parecido a la realidad y ver las cosas como un objeto, es decir, realmentecomo son y como se comportan. Características deseables de una metodología Existencia de reglas predefinidas, fases y subfases, tareas, productos intermedios, técnicas y herramientas tales que se amolden a cualquier desarrollo. Cobertura total del ciclo de desarrollo. Verificaciones intermedias. Planificación y control. Comunicación efectiva. Utilización sobre un abanico amplio de proyectos. Fácil formación. Herramientas case. La metodología debe contener actividades que mejoren el proceso de desarrollo. Soporte al mantenimiento. Por ejemplo. Reingeniería. Soporte de la reutilización de software, no solo reutilización de código. Actualmente, se huye de métodos muy burocráticos o monolíticos. Se dice entonces que una metodología es la que permita definir las etapas,las salidas, entradas de un proyecto. Mantener un programa no es fácil pero sepuede lograr, por lo tanto, las metodologías deben permitir una robusta formacióndel proyecto que permita utilizar mecanismos de mejora y que se usen los recursosdisponibles con su mayor rendimiento y eficacia.
  6. 6. Metodologías Vs. Ciclo de vida Una metodología es un conjunto integrado de técnicas y métodos quepermite abordar de forma homogénea y abierta cada una de las actividades delciclo de vida de un proyecto de desarrollo. Una definición estándar de metodologíapuede ser el conjunto de métodos que se utilizan en una determinada actividadcon el fin de formalizarla y optimizarla. Determina los pasos a seguir y cómorealizarlos para finalizar una tarea. Si esto se aplica a la Ingeniería de software, podemos destacar que unametodología: Optimiza el proceso y el producto software. Es una guía en la planificación y en el desarrollo del software. Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un proyecto.
  7. 7. Una metodología define una estrategia global para enfrentarse con elproyecto. Entre los elementos que forman parte de una metodología se puedendestacar: Fases: tareas a realizar en cada fase. Productos: E/S de cada fase, documentos. Procedimientos y herramientas: apoyo a la realización de cada tarea. Criterios de evaluación: del proceso y del producto. Saber si se han logrado los objetivos. El ciclo de vida es el conjunto de fases por las que pasa el sistema que seestá desarrollando desde que nace la idea inicial hasta que el software es retiradoo remplazado.Entre las funciones que debe tener un ciclo de vida se pueden destacar: Determinar el orden de las fases del proceso de software. Establecer los criterios de transición para pasar de una fase a la siguiente. Definir las entradas y salidas de cada fase. Describir los estados por los que pasa el producto. Describir las actividades a realizar para transformar el producto. Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar, entre otros.Las etapas de un ciclo de vida de un software son: Inicio: éste es el nacimiento de la idea. Aquí definimos los objetivos del proyecto y los recursos necesarios para su ejecución. Hacia dónde queremos ir, y no cómo queremos ir. Las características implícitas o explícitas de cada proyecto hacen necesaria una etapa previa destinada a obtener el objetivo por el cual se escribirán miles o cientos de miles de líneas de código. Un alto porcentaje del éxito de nuestro proyecto se definirá en estas etapas que, al igual que la etapa de debugging, muchos líderes de proyecto subestiman.
  8. 8. Planificación: idearemos un planeamiento detallado que guíe la gestióndel proyecto, temporal y económicamente.Implementación: acordaremos el conjunto de actividades que componenla realización del producto.Puesta en producción: nuestro proyecto entra en la etapa de definición,allí donde se lo presentamos al cliente o usuario final, sabiendo quefunciona correctamente y responde a los requerimientos solicitados en sumomento. Esta etapa es muy importante no sólo por representar laaceptación o no del proyecto por parte del cliente o usuario final sino porlas múltiples dificultades que suele presentar en la práctica, alargándoseexcesivamente y provocando costos no previstos.Control en producción: control del producto, analizando cómo el procesodifiere o no de los requerimientos originales e iniciando las accionescorrectivas si fuesen necesarias. Cuando decimos que hay que corregir elproducto, hacemos referencia a pequeñas desviaciones de losrequerimientos originales que puedan llegar a surgir en el ambienteproductivo. Si nuestro programa no realiza la tarea para lo cual fue creada,esta etapa no es la adecuada para el rediseño. Incluimos también en estaetapa el liderazgo, documentación y capacitación, proporcionando directivasa los recursos humanos, para que hagan su trabajo en forma correcta yefectiva. Objetivos de cada etapa:Expresión de necesidades: Esta etapa tiene como objetivo el armado deun documento en el cual se reflejan los requerimientos y funcionalidadesque ofrecerá al usuario el sistema a implementar (qué, y no cómo, se va aimplementar).Especificaciones: Formalizamos los requerimientos; el documentoobtenido en la etapa anterior se tomará como punto de partida para estaetapa.
  9. 9. Análisis: Determinamos los elementos que intervienen en el sistema adesarrollar, su estructura, relaciones, evolución temporal, funcionalidades,tendremos una descripción clara de qué producto vamos a construir, quéfuncionalidades aportará y qué comportamiento tendrá.Diseño: Ya sabemos qué hacer, ahora tenemos que determinar cómodebemos hacerlo (¿cómo debe ser construido el sistema en cuestión?);definimos en detalle entidades y relaciones de las bases de datos,seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Basesde Datos, entre otros).Implementación: Empezamos a codificar algoritmos y estructuras dedatos, definidos en las etapas anteriores, en el correspondiente lenguaje deprogramación o para un determinado sistema gestor de bases de datos. Enmuchos proyectos se pasa directamente a esta etapa; son proyectos muyarriesgados que adoptan un modelo de ciclo de vida de code & fix (codificary corregir) donde se eliminan las etapas de especificaciones, análisis ydiseño con la consiguiente pérdida de control sobre la gestión del proyecto.Debugging (Depuración): El objetivo de esta etapa es garantizar quenuestro programa no contiene errores de diseño o codificación. En estaetapa no deseamos saber si nuestro programa realiza lo que solicitó elusuario, esa tarea le corresponde a la etapa de implementación. En éstadeseamos encontrar la mayor cantidad de errores. Todas los programascontienen errores: encontrarlos es cuestión de tiempo. Lo ideal es encontrarla mayoría, si no todos, en esta etapa. También se pueden agregar pruebasde rendimiento.Validación: Esta etapa tiene como objetivo la verificación de que elsistema desarrollado cumple con los requerimientos expresados inicialmentepor el cliente y que han dado lugar al presente proyecto. En muchosproyectos las etapas de validación y debugging se realizan en paralelo porla estrecha relación que llevan. Sin embargo, tenemos que evitar laconfusión: podemos realizarlos en paralelo, pero no como una única etapa.
  10. 10. Evolución: En la mayoría de los proyectos se considera esta etapa como Mantenimiento y evolución, y se le asigna, no sólo el agregado de nuevas funcionalidades (evolución); sino la corrección de errores que surgen (mantenimiento). En la práctica esta denominación no es del todo errónea, ya que es posible que aun luego de una etapa de debugging y validación exhaustiva, se filtren errores. Una metodología puede seguir uno o varios modelos de ciclo de vida,adaptándose a cada uno de ellos, dependiendo de las necesidades dadas en unmomento determinado, es decir, el ciclo de vida indica lo que hay que obtener a lolargo del desarrollo del proyecto pero no da las indicaciones de como obtenerlo. Lametodología indica los diferentes pasos y fases para obtener los distintosproductos parciales y finales. En sí para el desarrollo de software, se necesitaaplicar una metodología o varias metodologías, dentro de un ciclo de vida, demanera que sepamos qué hacer y como hacerlo para conseguir lo que se quiere ycumplir con las metas planteadas. Modelos de procesos en el desarrollo de softwareUn modelo de proceso para el desarrollo de software es una representaciónsimplificada de pasos, representada desde una perspectiva específica. Por sunaturaleza los modelos son simplificados, por lo tanto un modelo de procesos delsoftware es una abstracción de un proceso real.
  11. 11. Estos modelos tienen como propósito la producción eficaz y eficiente de unproducto software que reúna los requisitos del cliente. Este proceso esintensamente intelectual, afectado por la creatividad y juicio de las personasinvolucradas. La mayoría de los modelos de procesos de desarrollo del softwareson dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en elproceso de desarrollo. Como todo proceso, están constituidos de pasos o fases quecontienen a su vez actividades, estos modelos de desarrollo de software se basanen un ciclo de vida para desarrollar el mismo, como lo son: La necesidad de solucionar un problema (surgimiento de necesidades) Inicio del proceso (desarrollo), dentro de esta fase se encuentra la definición del proyecto, el análisis del contexto, definición de requerimientos, diseño del sistema, construcción del sistema, pruebas e implantación. Operación y mantenimiento, donde realiza ajustes y se buscan fallas. Renovación o extinción. Los procesos de software son complejos debido a que un producto desoftware es intangible y por lo general muy abstracto, esto dificulta la definicióndel producto y sus requisitos, sobre todo cuando no se tiene precedentes enproductos software similares. En general este producto está compuesto por
  12. 12. hardware y software. En cuanto al hardware, su producción se realizasistemáticamente y la base de conocimiento para el desarrollo de dicha actividadestá claramente definida. Respecto del software, su construcción y resultados hansido históricamente cuestionados debido a los problemas asociados Los modelos de procesos permiten al analista de sistemas desarrollar unplan de requisitos del software, permiten establecer un trabajo en forma ordenada,además que existen muchos modelos que se adaptan a las exigencias delproyecto, solo debemos saber cual nos conviene, pero lo mas importante, es queestos modelos nos llevan a presentar los proyectos al cliente de manera que éstevea su diseño y sus funciones y que la mayoría de ellos están orientados almantenimiento. Clasificación de las Metodologías según el modelo de proceso Modelos Convencionales o Prescriptivos de Procesos Los modelos convencionales o modelos prescriptivos de procesos permitenllenar el marco de trabajo con un conjunto de tareas orientadas al desarrollo de unsoftware. Se les llama "prescriptivos" porque prescriben un conjunto de elementos delproceso, tales como: Actividades del Marco de Trabajo. Acciones de la Ingeniería del software. Tareas. Productos de trabajo. Aseguramiento de la calidad. Mecanismos de control del cambio para cada proyecto. Estos modelos son útiles si queremos describir un conjunto único deactividades dentro de un marco de trabajo para un proceso de software. cadaactividad debe contener un conjunto de acciones de ingeniería del software, ydefinir cada acción en cuanto a un conjunto de tareas que identifique el trabajo (y
  13. 13. los productos del trabajo) que deben completarse para alcanzar las metas dedesarrollo. Sin importar el modelo del proceso que se desee usar, los ingenieros desoftware eligen una manera tradicional para realizar el marco de trabajo genéricopara el proceso, ya que estos modelos se caracterizan por ser en esencia rígidos,estrictos y los más utilizados. En las metodologías convencionales, el ciclo de vida de un proyecto, puededefinirse como un ciclo de vida lineal, ya que imponen una disciplina de trabajosobre el proceso de desarrollo del software, con el fin de conseguir un softwaremás eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajoa realizar y una vez que está todo detallado, comienza el ciclo de desarrollo delproducto software. Se centran especialmente en el control del proceso, medianteuna rigurosa definición de roles, actividades, artefactos, herramientas y notacionespara el modelado y documentación detallada. Además, las metodologíastradicionales no se adaptan adecuadamente a los cambios, por lo que no sonmétodos adecuados cuando se trabaja en un entorno, donde los requisitos nopueden predecirse o bien pueden variar. Los modelos prescriptivos de proceso definen un conjunto distinto deactividades, acciones, tareas fundamentos y productos de trabajo que es requierenpara desarrollar software de alta calidad. Los ingenieros de software y susgerentes deben adaptar un modelo prescripto de proceso a sus necesidades ydespués lo siguen. Además, la gente que ha solicitado el software tiene un papelpor desempeñar se ejecuta el modelo de software. ¿Por qué es importante?Porque proporciona estabilidad, control y organización a una actividad que si no secontrola puede volverse caótica. ¿Cuáles son los pasos? El proceso conduce a un
  14. 14. equipo de software a través de un conjunto de actividades del marco de trabajoque se organizan en un flujo de proceso. ¿Cuál es un obtenido? Desde punto devista de un ingeniero de software, los productos de trabajo son los programas,documentos y datos que se producen como consecuencia de las actividades ytareas que define el proceso. Modelo en Cascada El modelo en cascada, algunas veces llamado el ciclo de vida clásico,sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que seinicia con la especificación de requerimientos del cliente y que continúa con laplaneación, el modelado, la construcción y el despliegue para culminar en elsoporte del software terminado. Este modelo es aplicable en donde existen ocasiones en que los requisitosde un problema se entienden de una manera razonable y deben estar biendefinidos, también cuando el trabajo fluye desde la comunicación a través deldespliegue de una manera casi lineal, esta situación se encuentra a veces cuandoes necesario hacer adaptaciones o mejorías bien definidas a un sistema existente.El modelo en cascada es el paradigma más antiguo para la ingeniería del software.Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso hanocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia.
  15. 15. Entre los problemas que algunas veces se encuentran al aplicar el modelo encascada están:1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone elmodelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de maneraindirecta. Como resultado, los cambios confunden mientras el equipo de proyectoactúa.2. Con frecuencia es difícil para el cliente establecer todos los requisitos de maneraexplícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporarla incertidumbre natural presente en el inicio de muchos proyectos.3. El cliente debe tener paciencia. Una versión que funcione de los programasestará disponible cuando el proyecto esté muy avanzado. Un error grave serádesastroso si no se detecta antes de la revisión del programa.En un análisis interesante de proyectos reales, Bradac(1994) concluyó que lanaturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en loscuales algunos miembros del equipo del proyecto deben esperar a otros paraterminar tareas dependientes. De hecho, el tiempo de espera puede superar el quese aplica en el trabajo productivo. El estado de bloqueo tiende a ser más común alprincipio y al final del proceso secuencial.En la actualidad, el trabajo del software está acelerado y sujeto a una cadenainfinita de cambios (de características, funciones y contenido de la información).Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sinembargo, puede servir como un modelo de proceso útil en situaciones donde losrequerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, deuna manera lineal.Las principales etapas de este modelo según Sommerville (2005) son: Análisis y definición de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se define una especificación del sistema. Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en sistemas hardware o software.
  16. 16. Establece una arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones. Implementación y prueba de unidades. Durante esta etapa, el diseño del software se lleva a cabo como un conjunto o unidades de programas. Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Funcionamiento y mantenimiento. El sistema se instala y se pone en funcionamiento práctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida. Modelo de Procesos Incrementables El modelo incremental combina elementos del modelo en cascada aplicadoen forma iterativa. El modelo incremental aplica secuencias lineales de maneraescalonada conforme avanza el tiempo en el calendario. Cada secuencia linealproduce "incrementos" del software. Por ejemplo, el software procesador de texto,desarrollado con el paradigma incremental en su primer incremento, podría realizar
  17. 17. funciones básicas de administración de archivos, edición y producción dedocumentos; en el segundo incremento, ediciones más sofisticadas, y tendríafunciones más complejas de producción de documentos; en el tercer incremento,funciones de corrección ortográfica y gramatical; y en el cuarto, capacidadesavanzadas de configuración de página. Se debe tener en cuenta que el flujo delproceso de cualquier incremento puede incorporar el paradigma de construcciónde prototipos que se expone más adelante. A menudo, al utilizar un modelo incremental el primer incremento es unproducto esencial. Es decir, se incorporan los requisitos básicos, pero muchascaracterísticas suplementarias (algunas conocidas, otras no) no se incorporan. Elproducto esencial queda en manos del cliente (o se somete a una evaluacióndetallada). Como resultado de la evaluación se desarrolla un plan para elincremento siguiente. El plan afronta la modificación del producto esencial con elfin de satisfacer de mejor manera las necesidades del cliente y la entrega decaracterísticas y funcionalidades adicionales. Este proceso se repite después de laentrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual que la construcción de prototiposy otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de laconstrucción de prototipos, el modelo incremental se enfoca en la entrega de unproducto operacional con cada incremento. Los primeros incrementos sonversiones “incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo.El desarrollo incremental es útil sobre todo cuando el personal necesario para unaimplementación completa no está disponible. Los primeros incrementos se puedenimplementar con menos gente. Si el producto esencial es bien recibido se agrega(si se requiere) más personal para implementar el incremento siguiente. Además,los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo,un sistema grande podría requerir la disponibilidad de un hardware nuevo que estáen desarrollo y cuya fecha de entrega es incierta. Sería posible planear losprimeros incrementos de forma que se evite el uso de este hardware, lo que
  18. 18. permitiría la entrega de funcionalidad parcial a los usuarios finales sin retrasosdesordenados. Combina elementos del modelo en cascada aplicado en forma iterativa. Elmodelo incremental aplica secuencias lineales de manera escalonada conformeavanza el tiempo en el calendario. Cada secuencia lineal produce incrementos.Produce entregas de software pequeñas pero usables (incrementos). Cada parte seconstruye sobre partes ya entregadas. Modelo de desarrollo rápido de aplicaciones (DRA) El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso desoftware incremental que resalta un ciclo de desarrollo corto. El modelo DRA esuna adaptación a "alta velocidad" del modelo en cascada en el que se logra eldesarrollo rápido mediante un enfoque de construcción basado en componentes. Sise entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRApermite que un equipo de desarrollo cree un "sistema completamente funcional"dentro de un periodo muy corto (por ejemplo, de 60 a 90 días). Como otros modelos de proceso, el enfoque DRA cumple con las actividadesgenéricas del marco de trabajo que ya se han presentado. La comunicación trabaja
  19. 19. para entender el problema de negocios y las características de información quedebe incluir el software. La planeación es esencial porque varios equipos desoftware trabajan en paralelo sobre diferentes funciones del sistema. El modeladoincluye tres grandes fases — modelado de negocios, modelado de datos ymodelado del proceso — y establece representaciones del diseño que sirven comobase para la actividad de construcción del modelo DRA. La construcción resalta elempleo de componentes de software existente y la aplicación de la generaciónautomática de código. Por último, el despliegue establece una base para lasiteraciones subsecuentes, si éstas son necesarias. El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que lasrestricciones de tiempo impuestas sobre un proyecto DRA exigen un "ámbito deescalas". Si una aplicación de negocios se puede modular de forma que cada granfunción pueda completarse en menos de tres meses (mediante la aplicación delenfoque ya descrito), ésta es una candidata para el DRA. Cada gran función sepuede abordar mediante un equipo de DRA por separado, para después integrarlasy formar un todo.Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes:1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursoshumanos para crear en número correcto de equipos DRA.2) Si los desarrolladores y clientes no se comprometen con las actividades rápidasnecesarias para completar el sistema en un marco de tiempo muy breve, losproyectos DRA fallarán.3) Si un sistema no se puede modular en forma apropiada, la construcción de loscomponentes necesarios para el DRA será problemática.4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertirinterfaces en componentes del sistema, el enfoque DRA podría no funcionar.5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo,cuando una aplicación nueva aplica muchas nuevas tecnologías).Es un modelo de proceso del software incremental que resulta un ciclo dedesarrollo corto. El modelo DRA es una adaptación a alta velocidad del modelo en
  20. 20. cascada en el que se logra el desarrollo rápido mediante un enfoque deconstrucción basado en componentes. Hace un uso intensivo de componentesreusables de software con un ciclo de desarrollo extremadamente corto. Es importante destacar que los Modelo Prescriptivos proporcionan unconjunto de pautas para el diseño, uso y rehusó de los objetos de aprendizaje,como complemento al proceso de su descripción, de una manera iterativa oincremental, desde la concepción del objeto de aprendizaje hasta su reusabilidad acorto, mediano y largo plazo. Pero el éxito en la creación de cualquier objeto deaprendizaje dependerá de la adecuada aplicación del proceso de Ingeniería deSoftware, cuyas etapas facilitan el desarrollo de los objetos de aprendizaje.TECNICA DE DISEÑO ESTRUCTURADOOBJETIVOS DE LA TECNICA• Obtener la estructura modular y los detalles de proceso del sistema, partiendosolamente de los «productos» obtenidos en la fase de Análisis del Sistema.• Cambiar la atención del QUE al COMO.• Obtener un diseño que no sólo «funcione», sino que también sea mantenible,mejore la reutilización y se pueda probar y entender fácilmente.• Utilizar herramientas gráficas (Diagramas de Estructura de Cuadros) pararepresentar la estructura modular del sistema. Se trata por tanto, de conseguir que cada módulo de la estructura en árbolque se obtenga cumpla las siguientes características: 1. Módulos de pequeño tamaño.El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamañode los módulos es reducido, una determinada modificación afectará a un númeromayor de módulos, sin embargo, la cantidad de código a considerar será menor.o Independencia modular. Cuanto mayor es la independencia de un módulo esmás sencillo trabajar con él, por tanto, el diseño debe reducir la compartición deficheros, de datos, la de dispositivos, las interfases comunes con el SistemaOperativo y las llamadas, desde o hacia otros módulos.
  21. 21. 2. Características de Caja Negra.La característica de Caja Negra se aplica a cualquier sistema, programa o módulo,para dar una visión exclusiva de sus entradas y salidas, sin tener en cuenta losdetalles de cómo se realiza el proceso. El uso de la Caja Negra permite una visiónmás fácil del conjunto, posponiendo la consideración de los detalles para unaetapa posterior. 3. Modelización conceptual.Un sistema será más fácil de mantener si el modelo utilizado en su diseño se habasado en los conceptos lógicos de la organización, los cuales serán más familiaresy comprensibles para el personal de mantenimiento que las descripciones físicas(equipo, organización de la unidad, cómo se realiza el trabajo en la actualidad,...).o Aislamiento de los detalles. En un sistema existen partes que reflejan la filosofíay otras partes que reflejan los detalles. Debido a que los detalles son mássusceptibles de cambiar, ambas partes deben diseñarse por separado para evitarque una variación en los detalles afecte a la filosofía del sistema.

×