SADT SADT (Structured Analysis and Design Techinique) es una técnica de análisis y diseño de sistemas que ha sido ampliamente utilizada para la definición de sistemas, el análisis de requisitos de software y el diseño de sistemas/software consiste en un conjunto de procedimientos que permiten al analista descomponer las funciones del software (o del sistema); una notación gráfica, los actigramas y datagramas, que comunican las relaciones de la información (datos y control) y de las funciones con el software; directrices para aplicar la metodología al control del proyecto. Usando SADT, el analista desarrolla un modelo compuesto por muchos actigramas y datagramas definidos de forma jerárquica. La metodología SADT engloba un conjunto de herramientas automáticas de soporte para los procedimientos de análisis y un método organizativo bien definido mediante el que se aplican las herramientas. Quedan especificadas revisiones y puntos de referencia que permiten una validación de la comunicación entre el cliente y el desarrollador. Etapas De La Planeación Estratégica De Sistemas Para llevar a cabo una planeación de sistemas se requiere de 3 pasos: establecer las metas de los sistemas, determinar y asignar prioridades a las solicitudes de proyectos de sistemas y Evaluar los recursos y la capacidad de los sistemas. Establecer las metas de los sistemas. Este paso implica la revisión de la dimensión dim ensión de las operaciones de la organización, las políticas de sistemas y el plan de la empresa. El objetivo principal es establecer las metas de la organización y enlazarlas con las metas de los sistemas. A partir de esto empiezan a surgir ideas de proyectos en sistemas para dar soporte a estas metas. Para dar forma a las ideas de proyectos, se recopila información de entrada de los miembros del equipo , incluyendo información de otras personas que puedan contribuir al proceso de planeación como consultores y auditores internos. El proceso de planeación deberá alinear sus actividades con la estrategia de la empresa, enfocando los proyectos hacia las metas estratégicas de la compañía e identificando las áreas en las que probablemente se encontraran oportunidades con altos beneficios. A partir de este proceso de investigación se plantean metas generales de sistemas de información. Estas metas pueden proponerse como : o
o
o
diseño e implementación de sistemas que apoyen a las metas organizacionales, aprovechar las oportunidades de negocios proporcionadas por las nuevas tecnologías informáticas y seguir una metodología de desarrollo de sistemas que interactúe con los usuarios y proporcione el estado de los sistemas.
NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Visión histórica del desarrollo de las metodologías 1970s Merise 1976. Ministerio de industria francés o Analisis Estructurado Yourdon / DeMarco 1978. Edward Yourdon – Tom DeMarco o NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Visión histórica del desarrollo de las metodologías 1980s SSADM 1981. Gobierno británico o Structured Analysis and Design Technique (SADT) 1980 o Análisis y Diseño estructurado para sistemas de tiempo real de o WARD y MELLOR 1985 o Análisis y Diseño estructurado para sistemas de tiempo real de o HATLEY y PIRHBAY 1987 o METRICA. España 1989 o NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Visión histórica del desarrollo de las metodologías 1990s Rapid application development (RAD) 1991. o Programación Orientada a Objetos o Dynamic System Development Method 1995 UK o Scrum o
Rational Unified Process (RUP) 1999 NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Visión histórica del o
desarrollo de las metodologías “ Nuestros días”
Extreme Programming(XP) desde 1999 Enterprise Unified Process (EUP) extensiones RUP desde 2002 o Constructionist design methodology (CDM) desde 2004 o Agile Unified Process (AUP) desde 2005 por Scott Ambler o NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Clasificación de las metodologías Estructuradas No estructuradas Orientadas a procesos o Orientadas a Datos o Mixtas o Orientadas a objetos o Sistemas en tiempo real o NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Clasificación de las metodologías Metodologías orientadas a procesos La ingeniería del software se basa en el modelo básico de entrada/proceso/salida de un sistema. Está compuesta por: Diagrama de flujo de datos (DFD). o Diccionario de datos o Especificaciones de proceso. o o
Ejemplos: metodologías de DeMarco, Gene y Sarson, Yourdon
NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Clasificación de las metodologías Metodologías orientadas a datos Son metodologías basadas en la información. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los componentes procedimentales. Ejemplos: metodologías de Jackson, Warnier, Warnier-Orr. NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Clasificación de las metodologías Metodologías orientadas a objeto La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de objetos. Tiene dos enfoques distintos: Revolucionario puro u ortodoxo. Ejemplos: metodologías OOD de Booch, CRC/RDD de Wirfs-Brock. Sintetista o evolutivo. Toman como base los sistemas estructurados y conforman elementos de uno y otro tipo. Ejemplos: metodología OMT de Rumbourgh. NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Clasificación de las metodologías Sistemas de tiempo real Procesan información orientada al control más que a los datos. Se caracterizan por concurrencia, priorización de procesos, comunicación entre tareas y acceso simultáneo a datos comunes. NUCLEO 2: METODOLOGÍAS DE DESARROLLO DE SOFTWARE Clasificación de las metodologías Metodologías Ágiles Metodologías Tradicionales Basadas en creatividad provenientes de prácticas de producción de código Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Hechas para a ceptar cambios Resistencia a los cambios Impuestas internamente Impuestas externamente Proceso menos controlado Proceso controlado por multiples normas No existe contrato tradicional o es flexible Existe contrato prefijado El cliente es parte del equipo de desarrollo El cliente se reune con el equipo Grupos pequeños (<10) en el mismo sitio Grupos grandes y a veces distribuidos Pocos Artefactos Mas artefactos Pocos roles Más roles Menos énfasis en la arquitectura de software La arquitectura es escencial y se expresa por medio de modelos El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development ) es un proceso de desarrollo de software, desarrollado
inicialmente por James Martin en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering) . Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Delphi, Foxpro , Anjuta, Game Maker, Velneo o Clarion.
o o o
Año Metodología 1968 concepto sobre prog.estructurada 1974 Tec. De prog. Estructurada
o o o o
o o o o o o o o o o
o o o o o
1975 primeros conceptos sobre diseño estructurado 1977 primeros conceptos sobre análisis estructurado Año Metodología 1978 análisis estructurado 1981 SSADM versión inicial 1985 análisis y diseño estructurado para sistemas tiempo real 1986 SSADM siguiente versión 1987 análisis diseño estructurado para sistemas tiempo real. 1989 Métrica versión inicial 1990 SSADM siguiente versión Ano Metodología 1993 Métrica siguiente versión 1995 Métrica versión actual Desarrollo OO el paradigma de OO trata los procesos y datos de forma conjunta
MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistemas de
información. Promovida por el Ministerio de Administraciones Públicas del Gobierno de España para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination)
Versiones de METRICA: evolución histórica. La primera versión de Métrica se publicó en el año 1989 por ERITEL. Desde entonces hasta la actualidad se han publicado cuatro versiones diferentes, las cuales se detallan a continuación: Versión
Año
Creador
V1
1989
ERITEL
V2
1993
Coopers & Lybrand
V2.1
1995
Universidad Carlos III
V3
2000
IECISA y CSI
Según [Booch 1986], los beneficios del enfoque OO son:
Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programación basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, y recientemente Java .
Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseños completos. Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y tecnología.
El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad. Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor, si su única función es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actúan entre sí mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, éste tomará las acciones para ejecutar o no el mensaje, de manera apropiada.
Object-Oriented Design (OOD), Booch. Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA. Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.
partir del año 1994, Grady Booch
[Booch96](precursor
de Booch '93) y Jim Rumbaugh (creador de OMT)
se unen en una empresa común, Rational Software Corporation, y comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versión del UML. A finales de ese mismo año, Ivar Jacobson, creador de OOSE (Object Oriented Software Engineer ) se añade al grupo.
Ivar Jacobson desarrolló el proceso de software OOSE en Objectory AB alrededor de 1992. Año 1990 1991 1991 1992 1994 1994 1998
Nombre Diseño de Software Orientado a objetos (DOOS) Análisis y Diseño Orientado a Objetos (OOA/OOD) Técnica de Modelado de objetos (OMT) Ingeniería del Software Orientada a Objetos (OOSE) Análisis y Diseño con Aplicaciones Orientadas a Objetos (OOADA) Método Fusion Métrica v3 Proceso Unificado de Desarrollo de Software (UML)
Autor Wirfs-Brock Coad y Yourdon Rumbaugh Jacobson Booch Coleman
La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck , autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis
en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software. El Proceso Racional Unificado ( Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades. Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como Rational Unified Process (RUP) desde 1999.
CATALYSIS. Por Camilo Latouche Es un método para desarrollo de software utilizado que presenta y especifica conceptos de modelado con mayor precisión, por lo cual nos resulta interesante. Este método provee un proceso sistemático que permite construir modelos precisos desde las etapas tempranas de desarrollo. Esto es posible debido a que Catalysis define más formalmente que en otros procesos, el concepto de abstracción/refinamiento de modelos. El refinamiento de modelos relaciona los requerimientos del sistema con el código, pasando por las distintas etapas intermedias. Además permite, a partir de modelos detallados, recuperar también en forma precisa, modelos abstractos. La relación de refinamiento proporciona importantes ventajas hacia el mejoramiento de la claridad y mejor comprensión de los modelos, y por lo tanto, hacia su exactitud. Algunos de los conceptos de Catalysis, como tipo, especificación de acciones, refinamiento de modelos fueron incluidos en la versión de UML 1.0, sin profundizar en su modelado y formalización. A su vez, los diagramas de Catalysis [1] se basan en notación UML pero los elementos utilizados en los diagramas no se condicen estrictamente con los definidos en el metamodelo de UML. Por el momento, Catalysis no cuenta con herramientas CASE específicas para editar sus diagramas, y aunque se aconseja utilizar las herramientas de edición para UML, éstas no incluyen todos los elementos necesarios para construir los diagramas Catalysis ni para verificar su precisión, como el método lo requiere. Resulta observable que la causa fundamental por la que no existen herramientas CASE que cubran estos requisitos es que Catalysis no tiene definido aún un metamodelo que permita la verificación de sus diagramas y la validación de consistencia entre modelos. Los dos conceptos básicos que se utilizan en Catalysis son: Objeto y Acción. Estos dos conceptos se definen al mismo nivel de abstracción. Los objetos representa un cluster de información y funcionalidad, y las acciones representan comportamiento, por ejemplo, un evento, una tarea, un mensaje, un cambio de estado una actividad, etc. Las acciones afectan a los objetos,
cambiando su estado. Estos conceptos forman la base para la construcción de los distintos modelos. Catalysis clasifica los modelos en estáticos, dinámicos e interactivos. Dentro de los modelos estáticos se tienen los diagramas de objetos y los de tipos. Dentro de los dinámicos, se tienen las especificaciones de acciones y los diagramas de estados y, dentro de los interactivos se tienen los casos de uso, las colaboraciones y los diagramas de interacción.