TEORÍA GENERAL DE SISTEMAS: Las definiciones que se dan sobre sistemas son

Transcripción

1 TGS: COMPONENTES EN COMÚN CON SISTEMAS AUTOMATIZADOS Y SISTEMAS EN LÍNEA, SISTEMAS DE TIEMPO REAL, SISTEMAS DE APOYO A DECISIONES O SISTEMAS BASADOS EN EL CONOCIMIENTO TEORÍA GENERAL DE SISTEMAS: Las definiciones que se dan sobre sistemas son numerosas. La mayoría de ellas vienen a coincidir, o se pueden resumir, en la dada por el iniciador de la Teoría General de Sistemas (T.G.S.) en su vertiente actual, Bertalanfy: un conjunto de elementos que deben estar fundamentalmente en interacción. Se puede decir que la T.G.S. tiene como misión fundamental formular de la forma más precisa posible el diseño de los sistemas, y mantenerlos en estado óptimo de actividad. Todo sistema admite un diseño hacia la consecución de un objetivo, en este sentido Churchman define el sistema como: un conjunto de partes coordinadas con vistas a alcanzar un conjunto de objetivos. El análisis del sistema es el estudio de los sistemas. Su propósito puede ser diseñar uno nuevo, o mejorar el existente. Dentro de la T.G.S. existen algunos principios generales que son de interés particular para quienes crean sistemas automatizados de información e incluyen los siguientes: 1. Cuanto más especializado sea el sistema, menos capaz es de adaptarse a circunstancias diferentes: Entre más general sea un sistema, menos óptimo será para una situación determinada; pero entre más óptimo sea, para tal situación menos adaptable será a nuevas circunstancias. 2. Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse en sistemas menores: Este punto es importante porque sugiere organizar el sistema computacional por el procedimiento de dividirlo en sistemas menores. En el ordenador lo consideramos: Subsistema de E/S Subsistema central Subsistema de comunicaciones 3. Los sistemas crecen: Un sistema de información típico, por ejemplo, crecerá hasta el punto de incluir más SW, más datos, más funciones y más usuarios que los que inicialmente habíamos planificado.

2 Para que un sistema tenga éxito, debe conocer a los demás sistemas con los que va a interactuar. Tipos de sistemas: Sistemas NATURALES HECHOS POR EL HOMBRE Físicos (galaxias, ríos, cordilleras) Vivientes (raza humana, animales, plantas) (Sistema financiero, de comunicaciones, sistema de información, etc.) En la actualidad casi todos los Sistemas hechos por el hombre incluyen entre sus elementos al ordenador y de hecho la gran mayoría de estos sistemas no podrían existir sin ellos. SISTEMAS AUTOMATIZADOS: Los sistemas automatizados, son sistemas hechos por el hombre que interactúan con o son controlados por uno o más ordenadores. Aunque hay diferentes tipos de sistemas automatizados, todos tienden a tener componentes en común: 1. El HW del ordenador: los procesadores, los discos, terminales, impresoras, unidades de cinta magnética, etc. 2. El SW del ordenador: los programas de sistemas tales como sistemas operativos, sistemas de bases de datos, programas de control de telecomunicaciones, además de los programas de aplicación que llevan a cabo las funciones deseadas por el usuario. 3. Las personas: los que operan el sistema, los que proveen su material de entrada y utilizan su material de salida, y los que proveen actividades de procesamiento manual en un sistema. 4. Los datos: la información que el sistema maneja durante un período de tiempo. 5. Los procedimientos: las políticas formales e instrucciones de operación del sistema. Una manera de ordenar por categorías los sistemas automatizados es por su aplicación: sistemas de manufactura, sistemas de contabilidad, sistemas de defensa, etc. Una división por categorías más útil de los sistemas automatizados es la siguiente: Sistemas en línea: Acepta material de entrada directamente del área donde se creó y el material de salida se devuelve directamente a donde es requerido. Los usuarios del sistema computacional normalmente interactúan con el ordenador desde terminales.

3 Sistemas de tiempo real: En los sistemas de tiempo real, el ordenador debe de reaccionar en milisegundos y a veces en microsegundos a los estímulos que recibe. Sistemas de apoyo a decisiones: Ayudan a los administradores de una organización a tomar decisiones inteligentes y documentadas. Sistemas basados en el conocimiento: Contienen grandes cantidades de diversos conocimientos que emplean en el desempeño de una determinada tarea. SISTEMAS EN LÍNEA: Un sistema en línea es aquel que acepta material de entrada directamente del área donde se creó. También es el sistema en el que el material de salida, o resultado de la computación, se devuelve directamente a donde es requerido. Una característica común de los sistemas en línea es que entran datos al ordenador o se les recibe de forma remota. Es decir, los usuarios del sistema computacional normalmente interactúan con el ordenador desde terminales. La información se teclea desde el lugar de origen Procesador Los datos se organizan de modo que se puedan recobrar fácilmente La salida se transmite a donde es requerida UN SISTEMA EN LÍNEA SISTEMAS DE TIEMPO REAL: Un sistema computacional de tiempo real puede definirse como aquel que controla un ambiente recibiendo datos, procesándolos y devolviéndolos con la suficiente rapidez como para influir en dicho ambiente en ese

4 momento. En la mayoría de los sistemas de tiempo real, el ordenador debe de reaccionar en milisegundos y a veces en microsegundos a los estímulos que recibe. SISTEMA DE TIEMPO REAL Estímulo Respuesta Ambiente Paso del tiempo UN SISTEMA DE TIEMPO REAL Dada la preocupación por la respuesta instantánea a las entradas del sistema, un analista que trabaja en sistemas de tiempo real generalmente estará muy atento con el comportamiento dependiente del tiempo que el sistema tenga. SISTEMAS DE APOYO A DECISIONES: Estos sistemas no toman decisiones por sí mismos, sino que ayudan a los administradores y a otros profesionales de una organización a tomar decisiones inteligentes y documentadas acerca de los diversos aspectos de cualquier operación. Una característica común es que no sólo recuperan y muestran los datos, sino que también realizan varios tipos de análisis matemáticos y estadísticos de los mismos. También tienen la capacidad, en la mayoría de los casos, de presentar la información en una variedad de formas gráficas (tablas, gráficos, etc.) al igual que en forma de reportes (informes) convencionales. SISTEMAS BASADOS EN EL CONOCIMIENTO: Los sistemas basados en el conocimiento, contienen grandes cantidades de diversos conocimientos que emplean en el desempeño de una determinada tarea. Los sistemas expertos son una especie de sistema basado en el conocimiento, aunque ambos términos a menudo se utilizan indistintamente. Un sistema experto es un programa de ordenador que contiene el conocimiento y la capacidad necesarios para desenvolverse a nivel de experto. Se prevé un momento en el futuro cercano en el cual los sistemas de IA y los SS.EE. formarán parte de la actividad normal del análisis de sistemas.

5 RELACIÓN ERAS GENERACIONES HW GENERACIONES 1ª GENERACIÓN: Válvulas de vacío 2ª GENERACIÓN: Transistor SW ERAS 1ª ERA: Década Distribución limitada SW a medida 2ª ERA: Década 3ª GENERACIÓN: Circuito integrado Sistema Multiusuario Sistema de tiempo real Bases de datos SW como producto 3ª ERA: Década 4ª GENERACIÓN: Circuito integrado + Microprocesador Sistema distribuido SW de bajo coste Impacto en el consumo 70 actual 4ª ERA: Década 5ª GENERACIÓN: Circuitos Ultragrande Escala de Integración (ULSI) Sistemas expertos Comenzando Sistemas potentes de sobremesa Tecnología orientada a objetos Redes neuronales Computación paralela

6 FASES Y ACTIVIDADES DEL CICLO GENÉRICO La creación de cualquier sistema SW implica la realización de tres pasos genéricos: definición, desarrollo y mantenimiento. Estos pasos (fases) los encontramos siempre independientemente del tamaño, complejidad y área de aplicación del proyecto elegido. La fase de definición se centra sobre el qué: Se intenta caracterizar el sistema que se ha de construir. Por tanto, han de identificarse los requisitos clave del sistema y del SW. Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma, o combinación de paradigmas, de ingeniería del SW aplicado (Ciclo de vida clásico, Ciclo de vida de prototipos, Modelo en espiral y Técnicas de cuarta y quinta generación), de alguna forma se producirán tres pasos específicos: Análisis del sistema: El análisis del sistema define el papel de cada elemento de un sistema informático, asignando finalmente al SW el papel que va a desempeñar. Planificación del proyecto de software: Una vez establecido el ámbito del SW se definen las tareas y se planifica el trabajo. Análisis de requisitos: El ámbito establecido para el SW proporciona la dirección a seguir, pero antes de comenzar a trabajar es necesario disponer de una información más detallada del ámbito de información y de función del SW. La fase de desarrollo se centra en el cómo: Se diseña la arquitectura del SW y las estructuras de los datos y de los programas. Se producirán tres pasos concretos: Diseño del SW: Traduce los requisitos del SW a un conjunto de representaciones (algunas gráficas y otras tabulares o basadas en lenguajes) que describen la estructura de los datos, la arquitectura, el procedimiento algorítmico y las características de la interfaz. Codificación: Las representaciones del diseño deben ser traducidas a un lenguaje artificial, dando como resultado unas instrucciones ejecutables por ordenador. El paso de la codificación es el que lleva a cabo esa traducción. Prueba del SW: Una vez que el SW ha sido implementado en una forma ejecutable por máquina debe ser probado para descubrir los defectos que puedan existir en la función, en la lógica y en la implementación. La fase de mantenimiento se centra en el cambio: Comienza una vez construido el sistema, coincidiendo con su vida útil. Durante ella, el SW es sometido a una serie de modificaciones y reparaciones. Va asociada a la corrección de errores, a las adaptaciones requeridas por la evolución del entorno del SW y a las modificaciones debidas a los cambios

7 de los requisitos del cliente dirigidos a reforzar o a ampliar el sistema. Esta fase vuelve a aplicar los pasos de las fases de definición y de desarrollo, pero en el contexto del SW ya existente. Se encuentran cuatro tipos de cambios: Corrección: El mantenimiento correctivo cambia el SW para corregir los defectos. Adaptación: El mantenimiento adaptativo consiste en modificar el SW para acomodarlo a los cambios de su entorno externo. Mejora: El mantenimiento perfectivo amplia el SW más allá de sus requisitos funcionales originales. Prevención: Ya que el SW se deteriora debido al cambio, de ahí este mantenimiento preventivo o reingeniería del SW, que hace que los programas se puedan corregir, adaptar y mejorar más fácilmente. Las fases y sus pasos relacionados descritos anteriormente, se complementan con varias actividades protectoras : las revisiones que se realizan durante cada paso para asegurar que se mantiene la calidad. Resumiendo, el SW se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos, ha pasado a ser una industria por sí misma; un factor que limita la evolución de los sistemas informáticos. DEFINICIÓN - Análisis del sistema - Planificación del proyecto - Análisis de requisitos Modificación y adaptación Fallos de definición DESARROLLO - Diseño del SW - Codificación - Prueba Errores MANTENIMIENTO - Corrección - Adaptación - Mejora - Prevención ESQUEMA DEL CICLO DE VIDA DEL SW

8 PERSPECTIVAS FUTURAS Los cambios en la tecnología de la ingeniería del SW son rápidos y estrictos, pero, al mismo tiempo, el progreso avanza de forma lenta. Es el SW el que marca la diferencia, pero además, los programas y datos que lo constituyen, ayudan a generar el producto más importante que puede adquirir cualquier persona, empresa o gobierno: la información. En informática los cambios suelen seguir una progresión (regla en años) es el tiempo que pasa generalmente a convertirse una idea en producto de masas. Los cambios que afectan a la ingeniería del SW estarán determinados simultáneamente por estos cuatro aspectos: 1. (La gente que trabaja) Las personas y la forma en que construyen sistemas. Al aumentar el tamaño de los programas, aumentan las personas que trabajan, se crean equipos individuales de trabajo, la comunicación se hace así más difícil pero se solucionará cambiando la forma de comunicación (correo electrónico). 2. (El proceso que aplican) El nuevo proceso de ingeniería del SW. En situaciones difíciles es probable que el SW se desplace a un modelo evolutivo de desarrollo. Es probable que en el futuro se apunte a sistemas orientados a objetos combinando con herramientas CASE. 3. (La naturaleza de la información) Nuevas formas de representación de la información. Los datos son información en bruto, la información se obtiene procesándolos, el conocimiento se obtiene asociando informaciones, la sabiduría consiste en obtener principios generales de fragmentos del conocimiento. La ingeniería que viene, además de información procesará conocimientos. La clave residirá en nuestra habilidad para asociar la información de fuentes distintas sin una conexión evidente y combinarlos de forma adecuada.

9 Todo tratamiento implica: E/, P y /S SABIDURÍA Proceso CONOCIMIENTO Proceso INFORMACIÓN Proceso DATOS EN BRUTO El SW futuro procesará conocimientos que es la entrada de los SS.EE. LA NATURALEZA DE LA INFORMACIÓN E/ P /S INFORMACIÓN INFORMACIÓN De otras informaciones CONOCIMIENTO CONOCIMIENTO De otras informaciones CONOCIMIENTO SABIDURÍA Clave del futuro del SW: Posibilidad y habilidad de asociar la información y el conocimiento de distintas fuentes UN CAMBIO QUE AFECTA AL FUTURO DEL SW: LA NATURALEZA DE LA INFORMACIÓN

10 4. (La tecnología subyacente) La tecnología como impulsor. El HW seguirá probablemente dos caminos paralelos, uno de tecnologías ya maduras (procesadores CISC y RISC) y otra dirección podría ser el desarrollo de arquitecturas menos tradicionales que pueden ocasionar cambios radicales en el SW que se construya. A pesar de esto, se puede asegurar que la calidad de SW nunca perderá importancia y que un buen diseño, un análisis efectivo y una correcta validación siempre estarán presentes en su desarrollo. Comenzando el nuevo milenio, el SW ha pasado a ser el producto y la industria más importante en el mundo, su impacto y su importancia han aumentado. Sin embargo, las nuevas generaciones de desarrolladores de SW deberán enfrentarse a la mayoría de problemas y desafíos a los que se enfrentaron las generaciones anteriores.

11 NATURALEZA DE LA INFORMACIÓN Todo tratamiento implica: E/, P y /S SABIDURÍA Proceso CONOCIMIENTO Proceso INFORMACIÓN Proceso DATOS EN BRUTO El SW futuro procesará conocimientos que es la entrada de los SS.EE. LA NATURALEZA DE LA INFORMACIÓN E/ P /S INFORMACIÓN INFORMACIÓN De otras informaciones CONOCIMIENTO CONOCIMIENTO De otras informaciones CONOCIMIENTO SABIDURÍA Clave del futuro del SW: Posibilidad y habilidad de asociar la información y el conocimiento de distintas fuentes UN CAMBIO QUE AFECTA AL FUTURO DEL SW: LA NATURALEZA DE LA INFORMACIÓN

12 Nuevas formas de representación de la información. Los datos son información en bruto, la información se obtiene procesándolos, el conocimiento se obtiene asociando informaciones, la sabiduría consiste en obtener principios generales de fragmentos del conocimiento. La ingeniería que viene, además de información procesará conocimientos. La clave residirá en nuestra habilidad para asociar la información de fuentes distintas sin una conexión evidente y combinarlos de forma adecuada.

13 CICLOS DE VIDA EN GENERAL CICLO DE VIDA CLÁSICO (EN CASCADA, LINEAL O SECUENCIAL) COMUNICACIÓN - Inicio del proyecto - Recopilación o análisis de requisitos PLANEACIÓN - Estimación MODELADO - Itinerario - Seguimiento - Análisis - Diseño CONSTRUCCIÓN - Código - Prueba DESPLIEGUE - Soporte - Entrega - Retroalimentación Lo que realmente caracteriza el ciclo de vida de un proyecto como clásico son dos aspectos: una fuerte tendencia a la implantación ascendente del sistema y la insistencia en la progresión lineal y secuencial de una fase a la siguiente. El ciclo de vida clásico es un ciclo de fases, que sigue un esquema en cascada, análogo al esquema general. Este paradigma contempla las siguientes fases: Análisis del sistema: El SW suele ser parte de un sistema mayor, formado por HW, SW, bases de datos y personas. Por ese motivo, se debe comenzar estableciendo los requisitos del sistema, asignando funciones a los distintos componentes y definiendo las interfases entre componentes. Análisis de los requerimientos del SW: Como fruto de este análisis se genera un documento conocido como especificación de requisitos del SW (SRS). Diseño: Consiste en construir una estructura para el SW que permita cumplir los requisitos con la calidad necesaria. Codificación: Consiste en plasmar el diseño en programas escritos e un lenguaje de programación adecuado. Prueba: En las pruebas se debe comprobar que los programas se corresponden con el diseño, realizan correctamente sus funciones y que el sistema satisface los requisitos planteados. Mantenimiento: Dependiendo de la naturaleza y motivación de cada operación de mantenimiento concreta, será necesario revisar desde la codificación, desde el diseño o desde una fase de análisis.

14 El ciclo de vida clásico es el paradigma más antiguo y más ampliamente usado en la ingeniería del SW. Sin embargo, con el paso de los años se han producido críticas al paradigma. Entre los problemas que se presentan algunas veces se encuentran: 1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre hay iteraciones y se crean problemas en la aplicación del paradigma. 2. Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. 3. El cliente debe tener paciencia. Hasta llegar a las etapas finales del desarrollo del proyecto, no estará disponible una versión operativa del programa. Cada uno de estos problemas es real. Sin embargo, el paradigma clásico del ciclo de vida tiene un lugar definido e importante dentro del trabajo realizado en ingeniería de SW. El ciclo de vida clásico sigue siendo el modelo procedimental más ampliamente usado por los ingenieros del SW, a pesar de sus inconvenientes. CICLO DE VIDA DE PROTOTIPOS COMUNICACIÓN PLAN RÁPIDO DESARROLLO ENTREGA RETROALIMENTACIÓN MODELADO DISEÑO RÁPIDO CONSTRUCCIÓN DEL PROTOTIPO Hay situaciones en que no es posible usar el ciclo de vida clásico. En estas situaciones es posible seguir el modelo de ciclo de vida de prototipos. Se basa en la construcción de un prototipo durante las primeras etapas del ciclo de vida. Un prototipo es un modelo a escala reducida del sistema que se va a construir. El ciclo de vida comienza con la realización de un breve análisis de los requisitos, tras el cual se diseña y codifica el prototipo. Sobre el prototipo se discuten y detallan las especificaciones, modificando el prototipo de acuerdo con éstas, siguiendo un proceso

15 cíclico. El resultado de este proceso es el documento de especificación de requisitos del SW. A partir de este punto se puede desechar el prototipo, diseñándose el sistema definitivo, o pueden realizarse refinamientos sucesivos del prototipo hasta alcanzar un producto utilizable. Normalmente un cliente define un conjunto de objetivos generales para el SW, pero no identifica los requisitos detallados de entrada, proceso o salida. La construcción de prototipos comienza con la recolección de los requisitos. Luego se produce un diseño rápido que conduce a la construcción de un prototipo. El prototipo es evaluado por el cliente/usuario y se utiliza para refinar los requisitos del SW a desarrollar. La clave está en definir al comienzo las reglas del juego; debe construirse el SW real siempre con los ojos puestos en la calidad y en el mantenimiento del producto. CICLO DE VIDA EN ESPIRAL PLANEACIÓN Estimación Análisis de riesgos MODELADO Análisis Diseño COMUNICACIÓN CONSTRUCCIÓN Código Prueba DESPLIEGUE Entrega Retroalimentación

16 Ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis del riesgo. El modelo, define cuatro actividades principales: Planificación: Determinación de objetivos, alternativas y restricciones. Análisis de riesgo: Análisis de alternativas e identificación/resolución de riesgos. Ingeniería: Desarrollo del producto de siguiente nivel. Evaluación del cliente: Valoración de los resultados de la ingeniería. Con cada iteración alrededor de una espiral el cliente evalúa el trabajo de ingeniería y sugiere modificaciones. En base a los comentarios del cliente se produce la siguiente fase de planificación y análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de seguir o no seguir. Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto. El modelo en espiral demanda una consideración directa de riesgos técnicos en todas las etapas del proyecto y, si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos. Pero, al igual que otros paradigmas no es la panacea. Requiere una considerable habilidad para la valoración del riesgo, y cuenta con esta habilidad para el éxito. El modelo en sí mismo es relativamente nuevo y no se ha usado tanto como el ciclo de vida o la creación de prototipos. TÉCNICAS DE T4G Y T5G El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de SW que facilitan, al que desarrolla el SW, la especificación de algunas características del SW a alto nivel. Luego, la genera automáticamente el código fuente basándose en la especificación del técnico. Actualmente, no existe un entorno T4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones del SW. Ha habido mucha controversia en un considerable debate sobre el uso del paradigma T4G. Los defensores aducen reducciones drásticas en el tiempo de desarrollo del SW y una mejora significativa en la productividad de la gente que construye el SW. Los detractores aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistemas de SW desarrollados mediante T4G, es cuestionable.

17 El estado actual de los métodos de T4G es este, aproximadamente: 1. Con muy pocas excepciones, el ámbito de aplicación actual de las T4G está limitado a las aplicaciones de sistemas de información de gestión. 2. Los datos preliminares recogidos en compañías que utilizan T4G parecen indicar que el tiempo requerido para producir SW se reduce mucho para aplicaciones pequeñas y de tamaño medio. 3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de SW exige el mismo o más tiempo de análisis, diseño y prueba, perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación. Las T4G ya se han convertido en una parte importante del desarrollo del SW en el área de aplicaciones de sistemas de información y probablemente llegarán a usarse bastante en aplicaciones de ingeniería y de tiempo real. La demanda de SW continuará creciendo, pero los métodos y los paradigmas convencionales contribuirán probablemente cada vez menos al desarrollo del mismo. Las T4G llenarán el hueco existente. TÉCNICAS DE DESARROLLO INCREMENTAL: Son los métodos de desarrollo que permiten crear y entregar un programa por etapas. Las técnicas incrementales reducen el riesgo dividiendo los proyectos en una serie de subproyectos más pequeños. El desarrollo incremental ofrece una facilidad mayor para realizar modificaciones a mitad de camino. A parte del modelo en espiral, tenemos los siguientes modelos: MODELO DE CASCADA PURA Concepto del software Análisis de requerimientos Diseño global Diseño detallado Codificación y depuración Prueba del sistema

18 El modelo en cascada pura es el modelo de ciclo de vida más conocido y ofrece una velocidad de desarrollo aceptable en algunas circunstancias. Otros modelos, sin embargo, proporcionan una velocidad de desarrollo superior. La mayoría de inconvenientes de este modelo están en el tratamiento como etapas secuenciales disjuntas. MODELO SASHIMI (CASCADA CON FASES SOLAPADAS) Concepto del software Análisis de requerimientos Diseño global Diseño detallado Codificar y depurar Prueba del sistema Puede evitar algunos inconvenientes del modelo en cascada solapando sus etapas, pero este enfoque genera nuevos problemas. No debemos esperar necesariamente a que termine una etapa para comenzar otra. Se pueden realizar actividades en paralelo, lo cual puede suponer una mala comunicación. MODELO DE PROTOTIPADO EVOLUTIVO Concepto inicial Diseño e implementación del prototipo inicial Refinar el prototipo hasta que sea aceptable Completar y entregar el prototipo Con el prototipado evolutivo, se comienza por diseñar e implementar las partes más importantes del programa en un prototipo, y a continuación se amplía y refina el prototipo hasta que se termine. El prototipo se convierte en el software que se entrega finalmente. Se desarrolla el concepto del sistema a medida que avanza el proyecto, se comienzan diseñando e implementando las partes más importantes y visibles del sistema en un

19 prototipo y se va ampliando y refinando el prototipo hasta que se termine. El prototipo se convierte en el software que finalmente se entregará al cliente. Se utiliza con ventaja cuando los requerimientos cambian con rapidez, cuando el cliente es reacio a especificar el conjunto de requisitos y también cuando los desarrolladores no están seguros de la arquitectura o los algoritmos adecuados que podemos utilizar. Tiene el inconveniente de la imposibilidad de conocer desde el principio del proyecto lo que tardaremos en obtener un producto aceptable, e incluso desconocemos el número de iteraciones que tendremos que realizar. MODELO DE ENTREGA POR ETAPAS Concepto del software Análisis de requerimientos Diseño global Etapa 1: Diseño detallado, codificación, depuración, prueba y entrega Etapa 2: Diseño detallado, codificación, depuración, prueba y entrega Prioridad media: Diseño detallado, codificación, depuración y prueba La entrega por etapas evita el problema del modelo en cascada de no terminar ninguna parte del sistema que se está realizando hasta que esté finalizado completamente. Una vez finalizado el diseño, se puede implementar y entregar el sistema en etapas. El software se le muestra al cliente en etapas refinadas sucesivamente. Se atraviesa los pasos del modelo en cascada pasando por la definición, análisis y diseño global de una arquitectura para el programa completo que se intenta construir y luego se procederá a realizar el diseño detallado, la codificación, depuración y prueba independientemente en cada una de las etapas.

20 MODELO DE ENTREGA EVOLUTIVA Concepto del software Análisis preliminar de requerimientos Entregar la versión final Diseño global y del núcleo del sistema Desarrollar una versión Incorporar la realimentación del cliente Entregar la versión Pedir la realimentación del cliente Este modelo ofrece el control que se obtiene con la entrega por etapas y la flexibilidad que se obtiene con el prototipado evolutivo. Puede ajustarlo para proporcionar el control y la flexibilidad que necesite. Se desarrolla una versión del producto, se le muestra al cliente y se refina en función de la realimentación del cliente. MODELO DE DISEÑO POR HERRAMIENTAS: Pueden ofrecer una velocidad de desarrollo excepcional, pero por el contrario, el control que tenemos sobre la funcionalidad del producto es mucho menor que en otros ciclos. Este modelo, y el siguiente, sólo lo añaden algunos autores. SOFTWARE COMERCIAL EXISTENTE: Que encontraremos disponible de forma inmediata y que siempre podemos revisarlo y adaptarlo a nuestras necesidades.

21 DIAGRAMAS CON LOS QUE UN PROYECTO QUEDA DEFINIDO DIAGRAMA DE CONTEXTO: El diagrama de contexto es un DFD. Este diagrama es el primer diagrama de la jerarquía. También se le conoce como diagrama de nivel 0. El objetivo de este diagrama es delimitar la frontera entre nuestro sistema y el mundo exterior, y definir sus interfaces, es decir, los flujos de datos de entrada y salida, o sea, el contexto. Este diagrama está formado exclusivamente por un proceso que representa una especie de caja negra del sistema completo, un conjunto de entidades externas que representan la procedencia y el destino de la información del sistema, y un conjunto de flujos de datos que representan los caminos por los que fluye dicha información. En este diagrama es necesario que estén representadas todas las entidades externas. Ejemplo: Pedido libros USUARIO Devolución libros 0 Gestionar biblioteca Sanción USUARIO Altas/Bajas BIBLIOTECARIO DIAGRAMA DE FLUJO DEL SISTEMA: Es una herramienta adicional muy útil para los diseñadores que deben desarrollar una arquitectura global del HW y SW del sistema para implantar los requerimientos del usuario. Sin embargo, no parece ser una herramienta de modelado apropiado para el análisis de sistemas, porque enfatiza los detalles de la implantación física. Pudiera ser útil para modelar al final de la actividad de análisis, cuando se está desarrollando el modelo de implantación del usuario. El ingeniero de sistemas refina el diagrama de contexto de arquitectura al estudiarlo con más detalle. Se identifican los subsistemas principales que permiten funcionar al sistema dentro del contexto definido por el diagrama. Los subsistemas principales se definen en un diagrama de flujo del sistema (DFS) que se obtiene del diagrama de contexto. El flujo de información a través de las regiones del diagrama de contexto se utiliza para guiar al ingeniero de sistemas en el desarrollo del DFS, un esquema más detallado del sistema. El DFS muestra los subsistemas principales y el flujo de las líneas de

22 información importantes (datos y control). Además, la plantilla del sistema divide el proceso del subsistema en cada una de las regiones de proceso. En este punto, cada uno de los subsistemas puede contener uno o más elementos del sistema (por ejemplo, HW, SW, personas) tal y como los ha asignado el ingeniero del sistema. El DFS inicial se convierte en el nodo superior de una jerarquía de DFS. Cada rectángulo del DFS original puede expandirse en otra plantilla de arquitectura dedicada a ella en forma exclusiva. Cada uno de los DFS del sistema puede utilizarse como punto de partida de subsiguientes fases de ingeniería para el subsistema que se describe. Ejemplo: Archivo de transacciones # 1 Archivo de transacciones # 2 Programa de edición de transacciones Archivo temporal (disco) Archivo principal Actualizar programa Informe diario

23 PASO DE ANÁLISIS A DISEÑO Diseño Procedimental Diseño de Interfaz Diseño Arquitectónico Diseño de Datos DISEÑO DE DATOS: Transforma el modelo de la información que se creo durante el análisis en las estructuras de datos necesarias para el SW. Los objetos y las relaciones en el DER junto con el DD son la base de este diseño. DISEÑO ARQUITECTÓNICO: Definen la relación entre las principales estructuras del programa. El proceso consiste en dividir el programa en módulos que se identifican por separado y luego se integran para satisfacer los requisitos del sistema. La base de este diseño está en la interacción de subsistemas definidos en el DFD. DISEÑO DE LA INTERFAZ: Se describe la comunicación del SW consigo mismo, también con los sistemas que operan con él y con los usuarios que lo emplean. La base del diseño de la interfaz es el DFD que se complementa algunas veces con algunas especificaciones (o informaciones) de control. DISEÑO PROCEDIMENTAL: Transforma los módulos del diseño arquitectónico (que son las estructuras del programa) en una descripción procedimental de los componentes del SW. La base de este diseño está en el DTE, en las especificaciones de proceso y en las especificaciones de control.

24 RESUMIR LOS CUATRO PILARES 1 EVITAR ERRORES CLÁSICOS MEJOR PLAN POSIBLE 2 APLICAR LAS BASES DE DESARROLLO 3 GESTIONAR LOS RIESGOS APLICAR LOS MÉTODOS ORIENTADOS A LA PLANIFICACIÓN Que permita desarrollar más rápido Que reduce el riesgo de planificación Que hacen visible el progreso EVITAR ERRORES CLÁSICOS: Se deben evitar a toda costa. Estos errores pueden estar relacionados con las personas, con el proceso, con el producto o con la tecnología. APLICAR LAS BASES DE DESARROLLO: Bases de gestión: Estimación: Del tamaño, del esfuerzo y planificar en base a ellos. Planificación: Siguiendo actividades para evitar problemas. Seguimiento: Comprobación paso a paso de planes previos. Medidas: Recogiendo datos medibles para analizar calidad y productividad. Bases técnicas: Gestión de requisitos: Llevados a documentación. Construcción: Trabajo dirigido a calidad del código. Gestión de la configuración (SCM): Con métodos para evaluar los cambios. Bases de control de calidad: Módulos propensos a errores. Prueba. Revisiones técnicas: Reuniones, lectura de código, inspecciones. GESTIONAR LOS RIESGOS: Su función es identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen a amenazar la terminación satisfactoria de un proyecto de SW. La gestión de riesgo se divide en:

25 Estimación de riesgos: Identificación, análisis y priorización. Control de riesgos: Planificación de la gestión, resolución y monitorización. APLICAR LOS MÉTODOS ORIENTADOS A LA PLANIFICACIÓN: Hay tres tipos: Que mejoran la velocidad. Que reducen el riesgo. Que hacen visible el progreso. Métodos orientados a la planificación Métodos orientados a los riesgos de planificación Métodos orientados a la velocidad Métodos orientados a la visibilidad

26 RAD: ESTRATEGIA GENERAL Y ESQUEMA. EXPLICAR PERSONAS El RAD (Rapid Application Development) o DRA (Desarrollo Rápido de Aplicaciones), que tal y como su propio nombre indica hace especial énfasis en un ciclo de desarrollo extremadamente corto, y que para algunos autores no es más que una adaptación a alta velocidad del Modelo Lineal Secuencial. El tiempo de desarrollo se ha convertido en una prioridad tan importante que en la mayoría de las ocasiones nos impide valorar otros parámetros, que al final terminan afectando al propio tiempo de desarrollo. Un proyecto de desarrollo rápido puede ser cualquier proyecto que necesite hacer especial hincapié en la velocidad de desarrollo, utilizaremos el término de igual forma a desarrollo veloz o planificación más corta, en definitiva significa desarrollar SW a una velocidad superior a la que conseguimos en estos momentos. Las soluciones simples suelen funcionar sólo con problemas sencillos, y el desarrollo de SW no lo es, el desarrollo rápido es aún menos simple. Para tener éxito desarrollando SW de forma rápida se requieren dos condiciones: Seleccionar métodos eficaces en lugar de métodos ineficaces. Seleccionar métodos orientados de forma específica para alcanzar objetivos de planificación. Se pueden seleccionar tres tipos de métodos orientados a la planificación: Métodos que mejoran la velocidad de desarrollo, permitiéndose entregar antes el SW. Métodos que reducen el riesgo en la planificación, evitando grandes retrasos. Métodos que hacen visible el progreso, e impiden tener la impresión de estar efectuando un desarrollo muy lento. Métodos orientados a la planificación Métodos orientados a los riesgos de planificación Métodos orientados a la velocidad Métodos orientados a la visibilidad

27 Recordar por último que seleccionar métodos eficaces y evitar los que no lo son es mucho más fácil de decir que de hacer. ESTRATEGIA GENERAL PARA EL DESARROLLO RÁPIDO: Uno de los errores más frecuentes en los que incurren las personas que quieren desarrollar de forma rápida, es centrarse en métodos orientados solamente a la planificación, sin tener en cuenta que son sólo una parte de lo que necesitamos para obtener el plan más corto posible. Se puede obtener un desarrollo rápido siguiendo una estrategia dividida en cuatro partes: 1. Evitar los errores clásicos. 2. Aplicar las bases de desarrollo. 3. Gestionar los riesgos. 4. Aplicar métodos orientados a la planificación (de la figura anterior). DIMENSIONES (FACTORES) DE LA VELOCIDAD DE DESARROLLO: Nuestro proyecto SW se desarrolla a través de cuatro dimensiones principales: PERSONAS, PROCESO, PRODUCTO Y TECNOLOGÍA. PERSONAS: Las personas forman una de las cuatro dimensiones principales a través de las cuales se desarrolla nuestro producto SW. Los temas relacionados con el personal tienen un impacto mayor en la productividad del SW y por lo tanto en su calidad. Los métodos más efectivos son aquellos que sacan el máximo partido al potencial humano de sus desarrolladores. En definitiva si nos interesa el desarrollo rápido, ocupémonos de las personas. SELECCIÓN DEL PERSONAL PARA EQUIPOS DE PROYECTOS: Barry Boehm presenta cinco principios de selección: Máximo talento: Utiliza poco y mejor personal. Trabajo adecuado: Asignar tareas según las habilidades y motivación de las personas. Progresión Profesional: Ayudando a la gente a actualizarse por sí misma en lugar de obligarles a trabajar donde son más necesarios. Equilibrar los equipos: Seleccionando personal que se complemente y armonice con los demás.

28 Eliminar la inadaptación: Reemplazando a los miembros problemáticos del equipo lo antes posible. ORGANIZACIÓN DEL EQUIPO: La forma con que se organiza al personal tiene una gran influencia sobre la eficiencia en el trabajo. MOTIVACIÓN: La motivación es potencialmente el mejor aliado para el desarrollo rápido de los proyectos.

29 BASES DE GESTIÓN Los fundamentos de Gestión tienen, al menos, tanta influencia como los técnicos en la planificación de desarrollos, las organizaciones que intentan implantar la disciplina de IS antes que la Gestión de Proyectos, están abocadas al fracaso ya que la Gestión controla las tres magnitudes del triángulo clásico de equilibrio: Planificación, Coste y Producto. Los fundamentos de Gestión consisten en determinar el tamaño del producto, asignando los recursos apropiados a un producto de ese tamaño. ESTIMACIÓN Y PLANIFICACIÓN: Para crear una buena Planificación SW los proyectos pasan por tres etapas básicas. Primero se estima el tamaño del producto, luego se estima el esfuerzo y por último se realiza la Planificación basándose en el esfuerzo estimado. Una estimación correcta es una condición necesaria para una Planificación efectiva, que además es esencial para un desarrollo eficiente. PLANIFICACIÓN: Una mala Planificación se manifiesta como fuente de problemas más a menudo que cualquier otra causa. Incluye las siguientes actividades: Estimación y Planificación. Determinar el número de personas que deben participar en el equipo de proyecto, las habilidades técnicas que son necesarias, cuándo aumentar el número de personas y quién participará. Decidir cómo organizar el equipo. Elegir el modelo de Ciclo de Vida que se va a realizar. Gestión de Riesgos. Tomar Decisiones estratégicas, tales como: controlar el conjunto de prestaciones del producto y decidir si hay que crear o bien comprar algunas partes del producto. SEGUIMIENTO: Una vez planificado el proyecto, hay que seguir el proceso de desarrollo para comprobar que se está cumpliendo con el plan previsto. El seguimiento es una actividad fundamental en el proceso de Planificación del SW, está claro que si no se puede seguir un proyecto, no hay forma de saber si el plan se está llevando a cabo ni lo que se debe hacer después. Si hacemos un seguimiento efectivo podremos detectar inmediatamente los problemas de Planificación cuando aún estamos a

30 tiempo de resolverlos, el desarrollo rápido no puede llevarse a efecto si no seguimos el proyecto. MEDIDAS: Recoger datos métricos para analizar la calidad y productividad del SW a lo largo del tiempo, es una de las buenas normas a seguir para obtener una buena organización. Si además de los datos sobre el Coste y la Planificación obtenemos datos históricos, como, el tamaño de los programas en número de líneas de código, o cualquier otra medida, tendremos una buena base para poder planificar proyectos futuros. Una organización que desee implantar el desarrollo rápido debe utilizar métricas específicas recogiendo las medidas y datos básicos para saber cuál es la velocidad de desarrollo y si va mejorando o no a medida que transcurre el tiempo.

31 BASES TÉCNICAS Un estudio realizado en 1984 comprobó que no se puede alcanzar una gran productividad sin utilizar estas Bases Técnicas. Hay algunos proyectos que utilizan modernos métodos de Programación con los mismos resultados que otros que no los utilizan, esto nos indican que las Bases Técnicas son necesarias pero no suficientes para conseguir un rápido desarrollo. GESTIÓN DE REQUERIMIENTOS (REQUISITOS): Es éste un proceso que consiste en reunir requisitos y plasmarlos en un documento. El éxito en la gestión de los requerimientos está en conocer los suficientes métodos diferentes como para poder escoger los que sean más apropiados para un proyecto específico. Las Bases de Gestión de Requerimientos son: Metodologías de Análisis de Requerimientos. Métodos para crear el modelo del Sistema. Métodos de Comunicación como el Desarrollo Conjunto de Aplicaciones (JAD). Las relaciones entre la Gestión de Requerimientos y los diferentes modelos del Ciclo de Vida. La Gestión de Requerimientos proporciona de dos formas diferentes una gran influencia en la velocidad de desarrollo. En primer lugar es un paso que tiende a hacerse sin prisas, comparado con otras actividades, si aceleramos este paso sin afectar a la calidad se puede disminuir el tiempo de desarrollo. En segundo lugar, obtener los requerimientos que se necesitan en el primer momento normalmente cuesta de 50 a 200 veces menos que si se espera a obtenerlos en fases posteriores. Un proyecto normal tienen un 25 por 100 de cambios en los Requerimientos, algunos métodos de Gestión de Requerimientos permiten reducir el número de estos cambios, otros métodos permiten reducir el coste de cada cambio. Podemos imaginar el efecto combinado que puede producir por un lado reducir el número de cambios y por otro el coste de los mismos. Consiguiendo esto, el desarrollo rápido está más cerca. DISEÑO: Antes de construir un sistema SW debemos pensar y hacer una arquitectura y un diseño. Un error de diseño que no es detectado hasta la fase de comprobación cuesta 10 veces más tiempo para solucionarlo que si se aprecia en la etapa de diseño.

32 Los conceptos de Modularidad (que permite a un programa ser intelectualmente manejable) y Ocultamiento (que hace que los objetos sean inaccesibles a otros módulos para que no haya colisiones) son las bases del diseño Orientado a Objetos. El Diseño bien hecho, es la base de la construcción, planificación, seguimiento y control de un proyecto y es imprescindible para conseguir una velocidad máxima de desarrollo. CONSTRUCCIÓN: Cuando llegamos aquí es que ya se ha llevado a cabo la mayor parte del trabajo para el éxito o el fracaso del proyecto. El trabajo de Construcción es importante hacerlo bien. Las bases de la Construcción incluyen algunos temas como: Métodos de Codificación. Métodos de Comprobación y de Depuración. Ventajas e inconvenientes del Lenguaje de Programación utilizado. Estrategias y Métodos para refinar el Código. Uso de Herramientas de Construcción, etc. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE: La SCM (Software Configuration Management) es un método de Gestión de los artefactos del proyecto de forma que éste permanezca en estado controlable durante todo el tiempo. El artefacto más controlado del proyecto suele ser el Código Fuente pero podemos aplicar SCM (Gestión de Configuración del SW) a los requerimientos, planes, diseños, casos de prueba y a cualquier otro elemento que se utilice para construir el producto.

33 BASES DE CONTROL DE CALIDAD Proporcionan un gran apoyo para obtener la máxima velocidad de desarrollo. La clave principal para no cometer errores, sobre todo en los primeros momentos, es prestar una especial atención desde el primer día a estas Bases de Control. Pocas son las organizaciones que tienen una tasa de defectos muy baja, en cuyo punto, la reducción adicional del número de defectos aumentará la cantidad de tiempo de desarrollo. El tiempo extra es necesario cuando se aplica a Sistemas críticos para la vida, pero no para cuando no se producen estas circunstancias extremas. MÓDULOS PROPENSOS A ERRORES: Son responsables de un número desproporcionado de defectos, son mucho más costosos y consumen más tiempo de ejecución. Es prioritario identificar y rediseñar este tipo de módulos PRUEBA: La Prueba de Ejecución: Encontrar los errores al ejecutar el programa y ver lo que hace, es indudablemente el método más común del Control de Calidad. Existen dos clases de Prueba, la individual, en la que el desarrollador comprueba su propio código y la prueba del Sistema, en la que un probador independiente observa si el Sistema funciona como se esperaba de él. En lo que respecta a la velocidad de desarrollo y a los métodos de control de calidad, la Prueba es la oveja negra, con ella se descubre si el producto tiene una calidad muy baja y se convierte así en el mensajero de las malas noticias que afectan a la planificación. La mejor forma de afrontar la Prueba es preparar un plan antes de las posibles malas noticias, estableciendo la Prueba de tal forma que se pueda relanzar inmediatamente el producto. REVISIONES TÉCNICAS: Incluyen toda clase de Revisiones que se utilizan para detectar defectos. Los tipos de Revisiones más frecuentes son: Reuniones: Son útiles porque se pueden utilizar para detectar errores antes de la prueba. Con las Reuniones se pueden encontrar entre un 30 y un 70 por 100 de errores en los programas. Lectura de código: El programador, autor de la codificación, distribuye el listado del programa fuente entre dos o más revisores que le informan de cualquier error que detecten.

34 Inspecciones: Son un tipo de Revisión técnica formal que también ha demostrado ser efectiva en la corrección de errores, sobre todo en requerimientos, prototipos de interfaz de usuario, diseño y otros artefactos del proyecto. Detectan al mismo tiempo tanto el Síntoma como la Causa del defecto. Se recomienda siempre seguir las instrucciones ya que la mayoría de las veces los proyectos SW fallan simplemente porque tanto los Programadores como los directivos no siguen las Bases de Desarrollo que se han descrito, es también cierto que se puede desarrollar SW, a veces rápidamente, sin dominar estos fundamentos, pero a juzgar por los resultados que se obtienen si no utilizamos los fundamentos de las Bases de Desarrollo no tendremos el control necesario sobre los proyectos no solo para desarrollarlos de forma rápida si no que incluso desconoceremos si podemos terminar los trabajos hasta que no finalizan.

35 ESTIMACIÓN Y SUS HERRAMIENTAS El argumento básico de la estimación del SW es que: El desarrollo del SW es un proceso de refinamiento gradual. El proceso para crear una planificación de desarrollo exacta consta de tres pasos: 1. Estimar el tamaño del producto (Número de Líneas de Código). 2. Estimar el esfuerzo (personas mes). 3. Estimar la planificación (meses). Estos tres pasos se pueden englobar dentro de un paso general: 4. Dar un intervalo de estimación e ir refinando periódicamente ese intervalo, para ir aumentando la precisión a medida que avanza el proyecto. ESTIMACIÓN DEL TAMAÑO: Se hace sobretodo utilizando un enfoque algorítmico como los puntos de función, que son una medida sintética del tamaño de los programas y se pueden determinar fácilmente a través de las líneas de codificación (LDC) que requieren. Algunos consejos para la estimación del tamaño son: Evitar las estimaciones improvisadas. Reservar tiempo suficiente para la estimación y planificarla. Utilizar datos de proyectos anteriores. Utilizar estimaciones basadas en el desarrollador. Estimar por consenso entre los miembros del equipo. Estimar a un bajo nivel de detalle. Utilizar herramientas de estimación de SW. Usar técnicas distintas para estimar y luego comparar los resultados. Cambiar los métodos de estimación conforme avanzamos en el proyecto. ESTIMACIÓN DEL ESFUERZO: Es bueno conocer este dato para saber el número de personas que hay que incorporar al proyecto. Para estimar el esfuerzo se pueden utilizar los datos sobre proyectos anteriores o bien utilizar, utilizar un método algorítmico de planificación como es el modelo COCOMO o el modelo de ciclo de vida de Putnam y Myers para convertir la estimación del número de líneas de código en estimación del esfuerzo. Recurso ( ) 2 C = C1 Caracteristica estimada (C 1 y C 2 estimados en otros proyectos)

36 ESTIMACIÓN DE LA PLANIFICACIÓN: Existe una regla que permite calcularla a partir del esfuerzo, es la ecuación: Planificac ión en meses 1 = personas mes La calidad de la estimación del SW depende del nivel de refinamiento de la definición del propio SW. Cuanto más refinada sea la definición, de mayor calidad será la estimación. Es conveniente refinar la estimación de los proyectos a medida que vamos avanzando en la ejecución de los mismos.

37 DESARROLLO ORIENTADO AL CLIENTE Algunos expertos en desarrollo rápido aseguran que la buena comunicación con el usuario final es uno de los tres factores críticos de este tipo de proyectos. Las dos razones principales son: Estas buenas relaciones aumentan la velocidad de desarrollo actual. Las buenas relaciones con el cliente mejoran la percepción de la velocidad de desarrollo. MÉTODOS ORIENTADOS AL CLIENTE: Se pueden dividir en varias categorías: Planificación. Análisis de requerimientos. Diseño. Construcción. No podemos olvidar que al utilizar métodos orientados al utilizar métodos orientados al cliente aumenta la proporción de requerimientos reales que podemos recopilar desde un primer momento (metodologías tipo JAD). GESTIÓN DE LAS ESPECTATIVAS DEL CLIENTE: El esforzarnos en comprender las expectativas del cliente puede ahorrarnos muchas fricciones y trabajo extra, ya que, parte de nuestro trabajo como desarrolladores de SW es educar a nuestros clientes para que comprendan el desarrollo del mismo. Crear expectativas poco realistas en los clientes resulta a la larga un riesgo insuperable en cualquier tipo de proyecto. Si hacemos promesas en función de un trabajo sencillo generando expectativas realistas, ésa será una buena labor, y parte del trabajo como desarrolladores.