SADT SADT (Structured Analysis and Design Techinique) es una tcnica de anlisis y diseo de sistemas que ha sido ampliamente

utilizada para la definicin de sistemas, el anlisis de requisitos de software y el diseo de sistemas/software consiste en un conjunto de procedimientos que permiten al analista descomponer las funciones del software (o del sistema); una notacin grfica, los actigramas y datagramas, que comunican las relaciones de la informacin (datos y control) y de las funciones con el software; directrices para aplicar la metodologa al control del proyecto. Usando SADT, el analista desarrolla un modelo compuesto por muchos actigramas y datagramas definidos de forma jerrquica. La metodologa SADT engloba un conjunto de herramientas automticas de soporte para los procedimientos de anlisis y un mtodo organizativo bien definido mediante el que se aplican las herramientas. Quedan especificadas revisiones y puntos de referencia que permiten una validacin de la comunicacin entre el cliente y el desarrollador. Etapas De La Planeacin Estratgica De Sistemas Para llevar a cabo una planeacin 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 revisin de la dimensin de las operaciones de la organizacin, las polticas de sistemas y el plan de la empresa. El objetivo principal es establecer las metas de la organizacin 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 informacin de entrada de los miembros del equipo , incluyendo informacin de otras personas que puedan contribuir al proceso de planeacin como consultores y auditores internos. El proceso de planeacin deber alinear sus actividades con la estrategia de la empresa, enfocando los proyectos hacia las metas estratgicas de la compaa e identificando las reas en las que probablemente se encontraran oportunidades con altos beneficios. A partir de este proceso de investigacin se plantean metas generales de sistemas de informacin. Estas metas pueden proponerse como : o o o diseo e implementacin de sistemas que apoyen a las metas organizacionales, aprovechar las oportunidades de negocios proporcionadas por las nuevas tecnologas informticas y seguir una metodologa de desarrollo de sistemas que interacte con los usuarios y proporcione el estado de los sistemas.

NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Visin histrica del desarrollo de las metodologas 1970s o Merise 1976. Ministerio de industria francs o Analisis Estructurado Yourdon / DeMarco 1978. Edward Yourdon Tom DeMarco NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Visin histrica del desarrollo de las metodologas 1980s o SSADM 1981. Gobierno britnico o Structured Analysis and Design Technique (SADT) 1980 o Anlisis y Diseo estructurado para sistemas de tiempo real de o WARD y MELLOR 1985 o Anlisis y Diseo estructurado para sistemas de tiempo real de o HATLEY y PIRHBAY 1987 o METRICA. Espaa 1989 NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Visin histrica del desarrollo de las metodologas 1990s o Rapid application development (RAD) 1991. o Programacin Orientada a Objetos o Dynamic System Development Method 1995 UK o Scrum

o Rational Unified Process (RUP) 1999 NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Visin histrica del desarrollo de las metodologas Nuestros das o Extreme Programming(XP) desde 1999 o 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 NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Clasificacin de las metodologas Estructuradas No estructuradas o Orientadas a procesos o Orientadas a Datos o Mixtas o Orientadas a objetos o Sistemas en tiempo real NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Clasificacin de las metodologas Metodologas orientadas a procesos La ingeniera del software se basa en el modelo bsico de entrada/proceso/salida de un sistema. Est compuesta por: o Diagrama de flujo de datos (DFD). o Diccionario de datos o Especificaciones de proceso.

Ejemplos: metodologas de DeMarco, Gene y Sarson, Yourdon

NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Clasificacin de las metodologas Metodologas orientadas a datos Son metodologas basadas en la informacin. Primero se definen las estructuras de datos y, a partir de stos, se derivan los componentes procedimentales. Ejemplos: metodologas de Jackson, Warnier, Warnier-Orr. NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Clasificacin de las metodologas Metodologas orientadas a objeto La orientacin a objetos unifica procesos y datos encapsulndolos en el concepto de objetos. Tiene dos enfoques distintos: Revolucionario puro u ortodoxo. Ejemplos: metodologas 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: metodologa OMT de Rumbourgh. NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Clasificacin de las metodologas Sistemas de tiempo real Procesan informacin orientada al control ms que a los datos. Se caracterizan por concurrencia, priorizacin de procesos, comunicacin entre tareas y acceso simultneo a datos comunes. NUCLEO 2: METODOLOGAS DE DESARROLLO DE SOFTWARE Clasificacin de las metodologas Metodologas giles Metodologas Tradicionales Basadas en creatividad provenientes de prcticas de produccin de cdigo Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo Hechas para aceptar 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 pequeos (<10) en el mismo sitio Grupos grandes y a veces distribuidos Pocos Artefactos Mas artefactos Pocos roles Ms roles Menos nfasis en la arquitectura de software La arquitectura es escencial y se expresa por medio de modelos

El desarrollo rpido de aplicaciones o RAD (acrnimo en ingls de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El mtodo comprende el desarrollo interactivo, la construccin de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin. Hoy en da se suele utilizar para referirnos al desarrollo rpido de interfaces grficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas ms conocidas son Visual Studio, Delphi, Foxpro , Anjuta, Game Maker, Velneo o Clarion.
o o o
Ao Metodologa 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 diseo estructurado 1977 primeros conceptos sobre anlisis estructurado Ao Metodologa 1978 anlisis estructurado 1981 SSADM versin inicial 1985 anlisis y diseo estructurado para sistemas tiempo real 1986 SSADM siguiente versin 1987 anlisis diseo estructurado para sistemas tiempo real. 1989 Mtrica versin inicial 1990 SSADM siguiente versin Ano Metodologa 1993 Mtrica siguiente versin 1995 Mtrica versin actual Desarrollo OO el paradigma de OO trata los procesos y datos de forma conjunta

MTRICA es una metodologa de planificacin, desarrollo y mantenimiento de sistemas de informacin. Promovida por el Ministerio de Administraciones Pblicas del Gobierno de Espaa para la sistematizacin de actividades del ciclo de vida de los proyectos software en el mbito de las administraciones pblicas. Esta metodologa 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: evolucin histrica.

La primera versin de Mtrica se public en el ao 1989 por ERITEL. Desde entonces hasta la actualidad se han publicado cuatro versiones diferentes, las cuales se detallan a continuacin: Versin V1 V2 V2.1 V3 Ao 1989 1993 1995 2000 Creador ERITEL Coopers & Lybrand Universidad Carlos III IECISA y CSI

Segn [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 programacin 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 diseos completos. Tercero, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.

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 funcin 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 actan 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 ao 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa comn, Rational Software Corporation, y comienzan a unificar sus dos mtodos. Un ao ms tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versin del UML. A finales de ese mismo ao, Ivar Jacobson, creador de OOSE (Object Oriented Software Engineer) se aade al grupo.

Ivar Jacobson desarroll el proceso de software OOSE en Objectory AB alrededor de 1992.

Ao 1990 1991 1991 1992 1994 1994 1998 Nombre Diseo de Software Orientado a objetos (DOOS) Anlisis y Diseo Orientado a Objetos (OOA/OOD) Tcnica de Modelado de objetos (OMT) Ingeniera del Software Orientada a Objetos (OOSE) Anlisis y Diseo con Aplicaciones Orientadas a Objetos (OOADA) Mtodo Fusion Mtrica v3 Proceso Unificado de Desarrollo de Software (UML) Autor Wirfs-Brock Coad y Yourdon Rumbaugh Jacobson Booch Coleman

La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms 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 aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos. Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software. El Proceso Racional Unificado (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo con las necesidades. Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el Rational Unified Process, que se vendiera como
Rational Unified Process (RUP) desde 1999.

CATALYSIS. Por Camilo Latouche

Es un mtodo para desarrollo de software utilizado que presenta y especifica conceptos de modelado con mayor precisin, por lo cual nos resulta interesante. Este mtodo provee un proceso sistemtico que permite construir modelos precisos desde las etapas tempranas de desarrollo. Esto es posible debido a que Catalysis define ms formalmente que en otros procesos, el concepto de abstraccin/refinamiento de modelos. El refinamiento de modelos relaciona los requerimientos del sistema con el cdigo, pasando por las distintas etapas intermedias. Adems permite, a partir de modelos detallados, recuperar tambin en forma precisa, modelos abstractos. La relacin de refinamiento proporciona importantes ventajas hacia el mejoramiento de la claridad y mejor comprensin de los modelos, y por lo tanto, hacia su exactitud. Algunos de los conceptos de Catalysis, como tipo, especificacin de acciones, refinamiento de modelos fueron incluidos en la versin de UML 1.0, sin profundizar en su modelado y formalizacin. A su vez, los diagramas de Catalysis [1] se basan en notacin 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 especficas para editar sus diagramas, y aunque se aconseja utilizar las herramientas de edicin para UML, stas no incluyen todos los elementos necesarios para construir los diagramas Catalysis ni para verificar su precisin, como el mtodo 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 an un metamodelo que permita la verificacin de sus diagramas y la validacin de consistencia entre modelos. Los dos conceptos bsicos que se utilizan en Catalysis son: Objeto y Accin. Estos dos conceptos se definen al mismo nivel de abstraccin. Los objetos representa un cluster de informacin 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 construccin de los distintos modelos. Catalysis clasifica los modelos en estticos, dinmicos e interactivos. Dentro de los modelos estticos se tienen los diagramas de objetos y los de tipos. Dentro de los dinmicos, 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 interaccin.