2.1 MODELO ESTRUCTURADO DE DISEÑO DE SISTEMAS
El análisis estructurado, como otros métodos, permite construir modelos de sistemas a partir del análisis de sus procesos y/o actividades que se ejecutan asociados al sistema. Permite al equipo encargado del estudio del desarrollo o la organización conocer de forma lógica un sistema o proceso. El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta situación dada.
Estrategia de Desarrollo | Descripción | Características de Aplicación |
Método del ciclo de vida de desarrollo de sistemas | Incluye las actividades de investigación preliminar, determinación de requerimientos, diseño del sistema, desarrollo de software, prueba de sistemas e implantación. |
|
Método del análisis estructurado | Se enfoca en lo que el sistema o aplicación realizan sin importar la forma en que llevan a cabo su función (SE abordan los aspectos lógicos y no los físicos). Emplea símbolos gráficos para describir el movimiento y procesamiento de datos. Los componentes importantes incluyen los diagramas de flujo de datos y el diccionario de datos. |
|
Método del prototipo de sistemas | Desarrollo iterativo o en continua evolución donde el usuario participa directamente en el proceso |
|
2.2 MODELO ORIENTADO A OBJETOS
La fase de análisis determina lo que debe hacer la implementación y la fase de diseño del sistema determina el plan de ataque. La fase de diseño de objetos determina las definiciones completas de las clases y asociaciones que se utilizarán en la implementación, así como las interfaces y algoritmos de los métodos utilizados para implementar las operaciones. La fase de diseño de objetos añadirá objetos internos para la implementación y optimizará las estructuras de datos y los algoritmos. El diseño de objetos es análogo a la fase preliminar de diseño del ciclo de vida de desarrollo de software tradicional.
Ejemplo: Los Objetos de Software, al igual que los objetos del mundo real, también tienen características y comportamientos. Un objeto de software mantiene sus características en una o más "variables", e implementa su comportamiento con "métodos". Un método es una función o subrutina asociada a un objeto.
Para redondear estas ideas, imaginemos que tenemos estacionado en nuestra cochera un Ford Focus color azul que corre hasta 260 km/h. Si pasamos ese objeto del mundo real al mundo del software, tendremos un objeto Automóvil con sus características predeterminadas:
Marca = Ford
Modelo = Focus
Color = Azul
Velocidad Máxima = 260 km/h
Modelo = Focus
Color = Azul
Velocidad Máxima = 260 km/h
Cuando a las características del objeto le ponemos valores decimos que el objeto tiene estados. Las variables almacenan los estados de un objeto en un determinado momento.Definición teórica: Un objeto es una unidad de código compuesto de variables y métodos relacionados.
2.3 MODELO BASADO EN COMPONENTES
El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases).
El modelo de desarrollo basado en componentes conduce ala reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software. Según estudios de reutilización, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reducción del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un índice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software.
Ejemplo: uso de una fábrica de software sería el diseño de un esquema para la construcción de aplicaciones de clientes livianos para comercio electrónico usando el Microsoft .NET Framework, C#, el Microsoft Business Framework, Microsoft SQL Server, Microsoft Biztalk Server y el Microsoft Host Integration Server – una familia amplia pero muy útil de aplicaciones. Podríamos usar este esquema de fábrica de software para configurar Visual Studio Team System para convertirse en una fábrica de software que construya miembros de esta familia.
2.4 DISEÑO DE ARQUITECURA DE SOFTWARE
Análisis de requerimientos. Extraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.
La captura, análisis y especificación de requerimientos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de requerimientos, por ejemplo en dos capítulos del libro de Sommerville "Ingeniería del Software" titulados "Requerimientos del software" y "Procesos de la Ingeniería de Requerimientos".
La Especificación de Requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.
Entre las técnicas utilizadas para la especificación de requisitos se encuentran:
- Casos de Uso,
- Historias de usuario,
Siendo los primeros más rigurosos y formales, los segundas más ágiles e informales.
Arquitectura. La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La Arquitectura de Sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:
- Diagramas de clases
- Diagramas de base de datos
- Diagramas de despliegue plegados
- Diagramas de secuencia multidireccional
Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar. Entre las herramientas para diseñar arquitecturas de software se encuentran:
Programación, Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.
Prueba, Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.
Documentación, Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Un ejemplo, Para ejemplificar la aplicación del método ADD, a continuación mostraremos el resultado de algunos de los pasos del proceso para una iteración del diseño de arquitectura usando como base el ejemplo introducido en la columna anterior. Recordando, el ejemplo hacía referencia a la “compañía xyz que se dedica a la comercialización de productos de diversos fabricantes”. Para este ejemplo, supondremos que ya se tiene suficiente información sobre los drivers (paso 1), que es la primera iteración, que el elemento a descomponer es el sistema entero (paso 2) y que se ha identificado el siguiente sub-conjunto de drivers para la iteración:
- Caso de uso primario: Realizar consultas del catálogo de productos.
- Atributos de calidad: Escenario de modificabilidad relativo a la facilidad para agregar nuevos sistemas externos de fabricantes de productos.
- Restricción: Uso de librerías y herramientas Open Source.
2.5 DISEÑO DE INTERFAZ DE USUARIO
La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware y software computadora que presentan al usuario y le permiten interactuar con la de una información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software. Si la IU está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, ya que el usuario habitualmente tiende a culparse a sí mismo por no saber usar el objeto.
Los programas son usados por usuarios con distintos niveles de conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario.
Opciones de Menú | Operaciones |
Avería | Alta avería, Actualización período Avería, Borrado de avería. |
Cliente | Alta cliente, Modificar dirección, Emisión tarjeta, Cancelación tarjeta, Renovación tarjeta. |
Entrega | Alta entrega, Borrar Entrega |
Entrega/Vehículo | Alta entrega / vehículo, Borrar entrega / vehículo |
Fabricante | Alta fabricante, Actualizar datos |
Factura Fabricante | Alta factura fabricante, Borrar factura fabricante |
Modelo | Alta modelo, Borrar modelo |
Modelo/Pedido | Alta modelo/pedido, Borrar modelo/pedido |
Oficina | Alta oficina, Borrar oficina |
Pago Cliente | Alta pago cliente, Borrar pago cliente |
Pago Fabricante | Alta pago fabricante, Borrar pago fabricante |
Pedido | Alta pedido, Borrar pedido |
Reserva vehículo | Alta reserva vehículo, Borrar reserva vehículo |
Seguro | Alta seguro, Modificar porcentaje seguro, Borrar seguro |
Ejemplos de pantalla para la operación de Alta de Fabricante y Alta de Pedidos
2.6 DISEÑO DE BASE DE DATOS
Las metas más importantes que se persiguen al diseñar un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.
Almacenar Solo La Información Necesaria. A menudo pensamos en todo lo que quisiéramos que estuviera almacenado en una base de datos y diseñamos la base de datos para guardar dichos datos. Debemos de ser realistas acerca de nuestras necesidades y decidir qué información es realmente necesaria. Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicación.
Normalizar la Estructura de las Tablas. Si nunca antes hemos oído hablar de la " normalización de datos", no debemos temer. Mientras que la normalización puede parecer un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización. Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo.
Ejemplo, si quisiéramos seguir la pista de nuestra colección de CD’s en una hoja de cálculo, podríamos diseñar una tabla.
2.7 DISEÑO DE CONTROLES DE PROCESO
El diseñador debe refinar la estrategia para implementar los modelos de estados y sucesos presentes en el modelo dinámico. Como parte del diseño del sistema, se habrá seleccionado una estrategia básica para construir el modelo dinámico. Durante el diseño de objetos, es necesario desarrollar esta estrategia.
Para implementar el modelo dinámico hay tres aproximaciones básicas:
- Utilizar la posición dentro del programa para almacenar el estado (sistema controlado por procedimientos
- Implementación directa de un mecanismo de máquina de estados (sistema controlado por sucesos)
- Utilización de tareas concurrentes
Procesos: Hasta el momento, en la fase del diseño detallado, el analista de sistemas ha especificado las entradas, las salidas, la base de datos, los controles y los procedimientos para el nuevo sistemas de información. Si el nuevo sistema de información requiere hardware o software de sistemas adicionales, el analista de sistemas ya se habrá ocupado de que el proceso de abastecimiento de dichos recursos está en camino. El diseño detallado de los programas requiere concentrar los esfuerzos del analista de sistemas en definir los programas que formaron el sistema de información, los módulos detallados de cada programa y las relaciones entre los módulos y los programas.
Definición de programas.- El objetivo de la definición de programas es la preparación de una descripción de cada programa del sistemas de información. El analista de sistemas podría empezar agrupando las salidas que serán producidas por el sistema de información. Luego se podría diseñar un programa para generar cada grupo de salida. Para las entradas podría seguirse un proceso similar de agrupamiento y designación, comparando tareas tales como validación y edición de la entrada. Si los datos necesitan ordenarse, entonces podría definirse otros programas de utilería.
Este proceso de agrupar las entradas y las salidas y luego pensar en las transformaciones necesarias para pasar de la entrada a la salida, produce una lista de programas. Esta lista contendrá el nombre, número en clave, y una definición breve de cada programa del sistema de información.
http://www.monografias.com/trabajos14/disenio-sistemas/disenio-sistemas.shtml#CONTROL
http://www.monografias.com/trabajos30/base-datos/base-datos.shtml
www.itescam.edu.mx/principal/sylabus/fpdb/.../r33004.DOC -
http://www.bing.com/images/search?q=MODELO+BASADO+EN+COMPONENTES+&view=detail&id=02DBD3CEBE56C863B55D43BAC75AF83B548D5DC3&first=1&FORM=IDFRIR
http://html.rincondelvago.com/analisis-y-diseno-de-sistemas-de-informacion.html
