Buscar este blog

miércoles, agosto 18

MSF

Microsoft Solution Framework (MSF)




Esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.

MSF tiene las siguientes características:

• Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.

• Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.

• Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

• Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.

MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto:

• Modelo de Arquitectura del Proyecto,

• Modelo de Equipo

• Modelo de Proceso

• Modelo de Gestión del Riesgo

• Modelo de Diseño de Proceso

• Modelo de Aplicación.

Fase 1 - Estrategia y alcance

En esta fase deberían tener lugar los siguientes trabajos:

• Elaboración y aprobación del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participación del mayor número de agentes implicados en el proyecto. En este documento quedarán definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solución a implantar.

• Formación del Equipo de Trabajo y distribución de competencias y responsabilidades: generalmente se definen como áreas principales la de Diseño de Arquitectura, Pruebas de Laboratorio, Documentación, Logística y Coordinación.

• Elaboración del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de información y coordinación deben quedar suficientemente bien establecidos y consensuados.

• Elaboración de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigación y actuación y revisarse con periodicidad.

• Para un proyecto de migración a Windows 2000 podría estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervención de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner.

Fase 2 - Planificación y Prueba de Concepto

Deben alcanzarse los siguientes objetivos e hitos:

• Documento de Planificación y Diseño de Arquitectura: es el documento principal, donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. La aprobación de este documento es el hito principal de esta fase, y supone la directriz última de todos los trabajos técnicos, que, a partir de ese momento, deben ser consistentes con esta Guía. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos, se deberá hacer por acuerdo y conocimiento de todo el equipo de trabajo y se llevará un registro de versiones que permita hacer un seguimiento adecuado de estas revisiones.

• Documento de Plan de Laboratorio - Prueba de Concepto: la descripción del contenido del laboratorio de prueba de concepto, los diversos escenarios a simular, los criterios de validez, el control de incidencias y las métricas de calidad son objetivos a cubrir en este documento. Es un documento dinámico, en el que se recoge la idea y la experiencia práctica al llevarla a cabo en entorno controlado y aislado. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia, y su grado de estabilidad y rendimiento es considerado como "suficiente".

Fase 3 – Estabilización



La solución implantada en la maqueta se pasa a un entorno real de explotación, restringido en número de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situación. Los hitos y objetivos fundamentales de esta fase son:

Selección del entorno de prueba piloto: se acordará la composición y ubicación del conjunto de máquinas y usuarios que entrarán en la prueba. Esta selección se recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera que puedan aflorar el máximo de incidentes potenciales en el menor tiempo posible. La dimensión de la muestra tiene también que calcularse, sin perder de vista que la prueba piloto no es el despliegue propiamente, sino una fase de observación en la que es absolutamente crítico establecer unos cauces efectivos de tratamiento de los errores.

Gestión de Incidencias: aunque esta labor se habrá iniciado en la fase anterior, el éxito de la prueba piloto dependerá de que se forme un sistema de recogida de incidentes (helpdesk o similar), de atención al usuario (formación, consultas) y de resolución de problemas y documentación de los mismos (versionado de la plataforma).

Revisión de la documentación final de Arquitectura: el documento de Planificación y Diseño de Arquitectura se puede ver alterado parcialmente como resultado de esta fase. El documento final, aprobado por consenso, supone el principal documento del Proyecto y la culminación de los trabajos de diseño, al menos en sus líneas principales. Este documento se considerará definitivo cuando la solución puesta en marcha se muestre estable y el número de incidencias graves (de intervención o de resolución) sea nulo y la cantidad de las consideradas leves quede por debajo de un límite establecido en las Métricas de Calidad.

Elaboración de la documentación de Formación y Operaciones: con vistas al soporte post proyecto y los programas de formación a usuarios y administradores, en esta fase deben elaborarse las Guías de Usuario, de Administración, las "paso-a-paso", y otros cuyos contenidos deben acordarse previamente.

Elaboración del Plan de Despliegue: se debe consensuar la fecha de finalización de la fase Piloto, y las condiciones de calidad que debe cumplir la solución final para inciiar el despliegue. En el Plan deben identificarse las fases, estrategia de implantación, fechas, tareas a realizar, procedimientos de validación y método de control de incidencias.

Elaboración del Plan de Formación: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formación orientado a usuarios finales y administradores, y debe hacerse compatible con los ritmos acordados en el Plan de Despliegue.

El tiempo necesario para abordar esta fase es variable y depende en parte de factores ajenos a la complejidad de la propia solución, como es la adecuada selección del entorno de prueba y el momento del año en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo críticas como Fin de Año). En proyectos de similar envergadura se ha llegado al momento "Error Free Version" en 30 jornadas de trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios.

Fase 4 – Despliegue



Se llevarán a cabo en esta fase los planes diseñados en la anterior, principalmente el de despliegue y el de formación. Los principales trabajos e hitos a conseguir son, en este caso, además de los obvios (implantación de la plataforma, puesta en servicio de todas las funciones, formación a los usuarios y administradores), los siguientes:

• Continuación con las labores de recepción de incidencias, clasificación, tratamiento, resolución y distribución de fixes o intervención on-site.

• Registro de mejoras y sugerencias, funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma, incluyendo mejoras aportadas por los fabricantes de software (nuevas versiones o Service Packs, por ejemplo)

• Revisión de las Guías y manuales de usuario, rectificación de errores y obtención de los documentos de formación definitivos.

• Entrega de los documentos definitivos acordados como "deliverables" en la fase de Vision Scope.

• Revisión (si procede) de la matriz de riesgos, las métricas de calidad y establecimiento de los estándares de calidad y SLA definitivos.

• Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la información y experiencia obtenidos.

La duración fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad política o de negocio) que pueden retardar o acelerar la conclusión.

La experiencia demuestra que no hay una relación directa entre número de máquinas y tiempo necesario para el despliegue. Los factores más relevantes en el cálculo suelen ser la dispersión o concentración geográfica, la complejidad del proceso de migración, el grado de automatización alcanzado, la experiencia y nivel de los técnicos que realizan la operación y condicionantes de calendario, a menudo con restricciones no técnicas, sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio).

Metodologias Estructuradas

Metodología de DeMarco:




Es un Análisis Estructurado, creado por Tom DeMarco.

Consta de los pasos siguientes pasos:

• Estudio del entorno físico actual: modelo del sistema actual con sus procedimientos. A través de un conjunto de DFD

• Derivación del correspondiente modelo lógico actual: modelo derivado del anterior sin connotación física.

• Derivación del nuevo modelo lógico: tomar en cuenta las nuevas necesidades. Formado por un DFD, diccionario de datos y especificaciones de proceso del sistema.

• Crear un conjunto de modelos físicos alternativos: del modelo lógico se establecen alternativas se enoje el más conveniente.

• Valorar cada opción: costos y beneficios de los modelos físicos.

• Seleccionar una opción: selecciona modelo físico

• Empaquetar la especificación: se recopila toda la documentación.

Metodología de Gane y Sarson:



• Es el resultado de varios años de práctica en consultoría de análisis y diseño estructurado.

• Creado por la empresa MCAUTO/IST bajo el nombre de STRADIS SDM.

• Es parecido al de DEMARCO, la principal diferencia es que hay una etapa en la que se define los contenidos de los almacenes de datos que aparecen en DFD en 3FN.





Diferencias entre metodologias de DeMarco y Gane Sarson

Fase del análisis Estructurado

Método DeMarco



• Construir el mod.físico actual DFD físico actual

• construir mod. Lógico actual DFD lógico actual

• crear un conjunto de modelos físicos alternativos

Método Gane y Sarson



• construir el Mod. Lógico actual DFD lógico actual

• construir el mod. Lógico del nuevo sistema: datos en 3FN

• seleccionar un Mod. Lógico



Metodología de Yourdon / Constantine



Consta de las siguientes fases

• realizar los DFD del sistema

• Realizar el diagrama de estructuras a partir del DFD, mediante análisis de transformación, y análisis de transacción.

• Evaluación del diseño midiendo la calidad de la estructura mediante el acoplamiento y cohesión

• preparación del diseño para la implementación dividiéndola en Unidades. Físicas o cuadernos de carga.



1. Modelo de ambiente:

Además de determinar que pertenece al interior y al exterior del sistema también es necesario definir con claridad las interfaces entre el sistema y el ambiente, se necesita saber que información entra al sistema desde el mundo exterior, y qué información sale del sistema. Consta de las siguientes partes:

a. Declaración de propósitos



Descripción textual, corta y concisa, del propósito general del sistema, dirigida al nivel administrativo superior. Puede constar de 3 o 4 frases, pero nunca debe superar 1 párrafo. Debe establecer claramente la frontera del sistema, a que otros sistemas afectan, y puede incluir los beneficios que se esperan del nuevo sistema.

b. Lista de eventos

Es una lista narrativa de los acontecimientos o estímulos que ocurren en el mundo exterior y a los cuales debe dar respuesta el sistema. Debe indicarse el tipo de evento como: F de flujo de datos, C de control (ocurre en un momento impredecible) y T temporal (ocurre regularmente, en un tiempo conocido). No confundir con flujos de datos, describir desde fuera hacia dentro. Puede incluir eventos de fallo, cuando falla un terminador.

c. Diagrama de contexto



DFD con una sola burbuja, debe enfatizar:

• las personas, organizaciones y sistemas con los que se comunica el sistema (terminadores). Se representan con rectángulos. Los terminadores no se comunican entre sí.

• los datos que el sistema recibe del mundo exterior (entradas)

• los datos que el sistema produce y que se envían al mundo exterior (salidas)

• los almacenes de datos externos que el sistema comparte con los terminadores.

• la frontera entre el sistema y el resto del mundo

Cuando se termine el modelo ambiental debe ser posible confirmar:

• el sistema necesita cada flujo de entrada del diagrama de contexto para reconocer que ha ocurrido un evento, necesitarlo para producir una respuesta, o ambos.

• cada flujo de salida deber ser respuesta a un evento.

• cada evento no temporal (F o C) debe tener entradas a partir de las cuales el sistema pueda detectarlo.

• cada evento debe producir salidas inmediatas como respuesta, o bien almacenar los datos que luego serán salidas, o ocasionar un cambio de estado en el sistema (diagrama de transición de estados).

2. Modelo de comportamiento:



• Modelo preliminar de comportamiento

• Nivelación ascendente hasta el diagrama de contexto:

• Nivelación descendente: 5 DFD

• Diagrama E-R: definir entidades y atributos en el Diccionario de Datos

• Diccionario de datos completo: incluir descripciones de procesos primitivos

3. Modelo de implantación de programas:

a. Diagramas de estructura correspondientes a los DFD de último nivel

• muestra la organización jerárquica de módulos dentro de una tarea, solo una tarea, individual, correspondiente a un proceso.

• las flechas, con dirección, parten del módulo que hace la llamada hacia el módulo llamado.

• sobre las flechas anteriores se dibujan los parámetros de entrada y de salida, siempre refiriéndonos al módulo llamado, como pequeñas flechas orientadas según sean parámetros de entrada o de salida.

metodologia SSADM y METRICA

METODOLOGIA SSADM

El gobierno británico a principios de los 80 plantea estandarizar proyectos de tecnología de información bajo la necesidad de crear una metodología y se desarrolló entre el Central Computing and Telecommunications Agency (CCTA) y Learmonth and Burchett Management Systems (LBMS), dando como resultado la metodología SSADM (Structures Systems Analysis and Design Method).


Los aspectos claves de SSADM v 4 Son :

• Énfasis en los usuarios : sus requisitos y participación.

• Definición del proceso de producción : qué hacer, cuándo y cómo.

• Tres puntos de vista : datos, eventos, procesos.

• Máxima flexibilidad en herramientas y técnicas de implementación.

SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y diseño, pero no cubre aspectos como la planificación estratégica ni entra en la construcción del código.



Estructura general de Métrica v 2.0

Métrica v 2.0 es una metodología propuesta por el Ministerio de las Administraciones Públicas para que todas las organizaciones sigan el mismo modelo y unificar los criterios para mayor homogeneidad y eficiencia en las aplicaciones informáticas.

Para construir Métrica v 2.0 hay unas etapas intermedias en las que hay que asegurar la calidad en la construcción de las aplicaciones informáticas relacionadas con el campo del tratamiento de la información, elaborando un marco homogéneo de referencia para verificar que los productos que se generen tengan el nivel de calidad apropiado y que se cumplan las previsiones iniciales de plazo y coste.

Métrica está en versión 2 porque en 1.991 se decidió revisar el proyecto Métrica con el objetivo de obtener una nueva versión por los siguientes motivos :

1. Mejorar la anterior versión de 1.989

2. Responder a la demanda por parte de los centros informáticos de una referencia para el desarrollo de sistemas de información.

3. Contar con una metodología compatible con EuroMétodo

4. Aprovechar el mercado de herramientas CASE mucho mayor que cuando se realizó la primera versión de Métrica.

Las fases de Métrica v. 2.0

Las fases de Métrica v.2.0. son :

• Fase 0 : Plan de sistemas de información

• Fase 1 : Análisis de sistemas

• Fase 2 : Diseño de sistemas

• Fase 3 : Construcción de sistemas

• Fase 4 : Implementación de sistemas

A continuación vamos a dar una breve descripción de las fases de Métrica v.2.0.

Fase 0: Plan de sistemas de información

En esta fase de la metodología de Métrica v.2 se pretende definir :

• La información necesaria para satisfacer los objetivos estratégicos de la organización.

• La arquitectura de la información, en cuanto a procesos y datos, y así satisfacer los objetivos estratégicos de la organización.

• Los nuevos sistemas a desarrollar para implantar dicha arquitectura.

PSI 1: DEFINIR OBJETIVOS, ORGANIZACION, AMBITO Y PLANIFICACION DEL PROYECTO

• Especificación de objetivos

• Identificación de las Unidades afectadas

• Organización de los participantes

• Planificación del proyecto

PSI 2: IDENTIFICAR LAS NECESIDADES DE INFORMACION DE LAS UNIDADES AFECTADAS

• Identificación de funciones y objetivos

• Identificación de requisitos

• Identificación de las necesidades de información

PSI 3: IDENTIFICAR LAS DIRECTRICES DE GESTION Y TECNICAS.

• Identificación de las directrices de gestión

• Identificación de las directrices técnicas

PSI 4: DISEÑAR LA ARQUITECTURA DE LA INFORMACION

• Diseño del modelo conceptual de datos

• Diseño de la jerarquía de funciones

• Diseño de la Arquitectura de la Información

PSI 5: REVISAR LA SITUACION ACTUAL DE LOS SISTEMAS DE INFORMACION.

• Identificación y descripción de los sistemas existentes

• Análisis del entorno tecnológico actual

• Diagnóstico de la situación actual

PSI 6: ESPECIFICAR LOS NUEVOS SISTEMAS.

• Identificación de mejoras en los sistemas actuales

• Identificación de nuevos sistemas

• Determinación de prioridades de desarrollo

• Especificación de los sistemas

PSI 7: DEFINIR LAS ALTERNATIVAS TECNOLOGICAS.

• Identificación de necesidades tecnológicas futuras

• Definición de opciones tecnológicas

PSI 8: ELABORAR EL PLAN DE ACCION.

• Elaboración de un plan de implantación

• Mantenimiento del plan de sistemas

DOCUMENTACION ASOCIADA AL MODULO PSI

Fase 1: Análisis de sistemas

El objetivo de esta fases describir el alcance y los requisitos del sistema generando diferentes alternativas para solucionar el problema y recomendar una de ellas si es oportuno. Una vez seleccionada una alternativa se tiene que generar las especificaciones formales que describan al sistema y estas tienen que ser aprobadas por el usuario.

ARS: ANALISIS DE REQUISITOS DEL SISTEMA

En este módulo se identifican los requisitos que ha de satisfacer el sistema y se evalúan las distintas alternativas que solucionan el problema recomendando una de ellas.

ARS 1: ESTABLECER EL AMBITO Y ALCANCE DEL PROYECTO.

• Definición del Proyecto

• Identificación de los usuarios participantes

ARS 2: IDENTIFICAR Y DEFINIR REQUISITOS

• Planificación y realización de entrevistas

• Identificación de problemas y necesidades

ARS 3: DISEÑAR EL MODELO LOGICO ACTUAL

• Construcción del modelo lógico actual de procesos.

• Construcción del modelo lógico actual de datos

ARS 4: ESTUDIAR ALTERNATIVAS DE CONSTRUCCION

• Definición de Alternativas.

• Selección de una Alternativa.

DOCUMENTACION ASOCIADA AL MODULO ARS

EFS: ESPECIFICACION FUNCIONAL DEL SISTEMA

En este módulo se construyen las especificaciones detalladas del sistema partiendo de los requisitos y soluciones obtenidos del módulo anterior.

EFS 1: CONSTRUIR EL MODELO DE PROCESOS DEL NUEVO SISTEMA

• Diseño del diagrama de contexto del sistema

• Identificación y definición de subsistemas

• Especificación de interfases con otros sistemas

• Descripción de procesos manuales

EFS 2: CONSTRUIR EL MODELO DE DATOS DEL NUEVO SISTEMA

• Construcción del modelo de datos

• Normalización del modelo de datos

EFS 3: REALIZAR EL ANALISIS DETALLADO DEL NUEVO SISTEMA

• Construcción del modelo entidad-evento

• Consolidación de los modelos de datos y procesos

EFS 4: DEFINIR INTERFASES DE USUARIO

• Producción de prototipos preliminares y diálogos

• Especificación de informes y formularios

EFS 5: COMPLETAR ESPECIFICACIONES DEL SISTEMA

• Especificación de requisitos de seguridad y control

• Especificación de requisitos de copias de respaldo, contingencias y recuperación de errores

• Especificación de requisitos de rendimiento

EFS 6: COMPLETAR ESPECIFICACIONES DE ENTREGA

• Preparación del plan de pruebas del sistema

• Especificación del plan de entrega del sistema

• Verificación y validación de la especificación funcional del sistema.

DOCUMENTACION ASOCIADA AL MODULO EFS

Fase 2: Diseño de sistemas

En esta fase su objetivo es obtener las especificaciones físicas del sistema para la construcción del mismo.

DTS: DISEÑO TECNICO DEL SISTEMA

En este módulo se describe como será el sistema desde el punto de vista físico, para ello tenemos que diseñar la arquitectura física del sistema, el esquema externo de datos del sistema teniendo en cuenta el entorno tecnológico en que va a funcionar.

DTS 1: DISEÑAR LA ARQUITECTURA FISICA DEL SISTEMA.

• Diseño de la Estructura modular del sistema

• Descripción de interfases entre módulos del sistema

• Descripción de interfases con otros sistemas

• Descripción de interfases de usuario

• Definición de componentes del sistema

DTS 2: DISEÑAR LA ESTRUCTURA FISICA DE DATOS DEL SISTEMA.

• Elaboración del modelo físico de datos

• Optimización del modelo físico de datos

DTS 3: ESPECIFICAR EL ENTORNO TECNOLOGICO DEL SISTEMA.

• Definición del entorno tecnológico del sistema

• Especificación de requisitos de comunicaciones del sistema

• Especificación de requisitos de operación, seguridad y control

DTS 4: COMPLETAR EL PLAN DE PRUEBAS DEL SISTEMA.

• Diseño de planes de prueba del sistema

• Definición del entorno y limitaciones de prueba.

DTS 5: COMPLETAR ESPECIFICACIONES DE DISEÑO.

• Preparación de planes de construcción

• Preparación de planes para la implantación

• Revisión del Diseño Técnico del Sistema

DOCUMENTACION ASOCIADA AL MODULO DTS

Fase 3: Construcción de sistemas

El objetivo de esta fase es construir y probar los componentes del sistema obtenidos en las especificaciones físicas de la fase anterior de Diseño de Sistemas.

DCS: DESARROLLO DE COMPONENTES DEL SISTEMA

En este módulo se realizan la construcción, pruebas unitarias y de integración del equipo lógico y se desarrollan los procedimientos de operación de componentes del sistema.

DCS 1: PREPARAR ENTORNO DE DESARROLLO, PRUEBAS Y PROCEDIMIENTOS DE OPERACION.

• Implantación de la Base de Datos Física o ficheros de datos

• Preparación del entorno de desarrollo

• Preparación del entorno de pruebas

• Definición de procedimientos de operaciones de producción e implantación

DCS 2: DESARROLLAR Y PROBAR COMPONENTES DEL SISTEMA

• Generación del código de los componentes del sistema

• Preparación, ejecución y evaluación de las pruebas unitarias

• Documentación de los componentes del Sistema

DCS 3: REALIZAR PRUEBAS DE INTEGRACION

• Preparación y ejecución de pruebas de integración

• Evaluación y documentación de los resultados de las pruebas de integración

DOCUMENTACION ASOCIADA AL MODULO DTS

DPU: DESARROLLO DE PROCEDIMIENTOS DE USUARIO

En este módulo se definen todas las operaciones que han de realizar los usuarios para trabajar con el sistema y se les suministra a los usuarios toda la información necesaria para que sean capaces de utilizar el nuevo sistema de forma satisfactoria, obteniendo los mejores beneficios.

DPU 1: COMPLETAR EL PLAN DE DESARROLLO DE PROCEDIMIENTOS DE USUARIO.

• Preparación de un borrador del plan de desarrollo de procedimientos de usuario.

• Especificación de criterios de calidad y estándares de procedimientos de usuario.

DPU 2: ELABORAR PROCEDIMIENTOS DE USUARIO

• Diseño de la estructura de los procedimientos de usuario

• Elaboración de procedimientos de usuario

DPU 3: DETERMINAR NECESIDADES ESPECIALES PARA EL FUNCIONAMIENTO DEL SISTEMA

• Identificación de perfiles de usuario

• Especificación de recursos necesarios

DPU 4: DESARROLLAR PLAN DE FORMACION DE USUARIOS

• Identificación de requisitos y recursos necesarios para la formación de usuarios.

• Preparación de los materiales de formación de usuarios

DPU 5: CONSOLIDAR PROCEDIMIENTOS DE USUARIO

• Organización de la documentación de procedimientos de usuario.

• Consolidación de la documentación de procedimientos de usuario

Fase 4: Implementación de sistemas

El objetivo de esta fase es conseguir la aceptación final del nuevo sistema por parte de los usuarios y poner en funcionamiento el nuevo sistema.

PIA: PRUEBAS, IMPLANTACION Y ACEPTACION DEL SISTEMA

En este modulo se realizarán las pruebas de sistema y las de aceptación, es decir, se comprueba el sistema en su totalidad y así posteriormente, poner en explotación el nuevo sistema.

PIA 1: DISEÑAR Y REALIZAR LAS PRUEBAS DEL SISTEMA

• Preparación de las pruebas del sistema

• Creación del entorno de pruebas del sistema

• Realización de las pruebas del sistema

PIA 2: ACTUALIZAR EL PLAN DE IMPLANTACION

• Revisión del plan de implantación

• Preparación del plan de trabajo de implantación

PIA 3: REALIZAR LAS PRUEBAS DE ACEPTACION

• Preparación de las pruebas de aceptación

• Preparación del entorno de producción

• Realización de las pruebas de aceptación

PIA 4: ESTABLECER PROCEDIMIENTOS DE PRODUCCION

• Instalación de procedimientos automáticos de producción

• Instalación de procedimientos manuales de producción

• Inicio de procedimientos de producción

Evolución de las metodologías

veremos cómo han surgido las metodologías más representativas en la historia de la Ingeniería del Software.

Años Metodologías




1968 Concepción sobre la programación estructurada de DIJKDTRA

1974 Técnicas de programación estructurada de WARNIER y JACKSON

1975 Primeros conceptos sobre diseño estructurado de MYERS y YOURDON

1977 Primeros conceptos sobre el análisis estructurado GANE y SARSON

1978 Análisis estructurado : DEMARCO y WIINBERG. Nace MERISE

1981 SSADM. Information Engineering

1985 Análisis y Diseño estructurado para sistemas de tiempo real de WARD y MELLOR

1986 SSADM Versión 3

1987 Análisis y Diseño estructurado para sistemas de tiempo real de HATLEY Y PIRHBAY

1989 METRICA

1990 SSADM Versión 4

1993 METRICA Versión 2

1995 METRICA Versión 2.1

Programacion Extrema XP

PROGRAMACION EXTREMA




Es una de las metodologías de desarrollo de software más exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto.

La Programación Extrema se basa en 12 principios básicos agrupados en cuatro categorías:

Retroalimentación a escala fina.

1. El principio de pruebas: se tiene que establecer un período de pruebas de aceptación del programa (llamado también período de caja negra) donde se definirán las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit testing frameworks). Un buen ejemplo de un ambiente de prueba es el JUnit para Java. Otros ambientes de pruebas para otros lenguajes como C, C++, JavaScript, XML y servicios Web.

2. Proceso de planificación: en esta fase, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo.

Son muy importantes y tienen que ser una constante las reuniones periódicas durante esta fase de planificación. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y señalar aquellos puntos a los que se les ha de dar más importancia por su dificultad o por su punto crítico.

3. El cliente en el sitio: se le dará poder para determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder las preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento. Este representante del cliente estará con el equipo de trabajo durante toda la realización del proyecto.

4. Programación en parejas: uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. De acuerdo con los experimentos, este principio puede producir aplicaciones más buenas, de manera consistente, a iguales o menores costes. Aunque el pair-programming puede no ser para todo el mundo, laevidencia anecdótica en la lista de correo de XP demuestra un gran éxito.

Proceso continuo en lugar de por lotes.



1. Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día. Esto reduce los problemas de integración comunes en proyectos largos y estilo cascada.

2. Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a través de todo el proceso de desarrollo. Los programadores evalúan continuamente el diseño y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimización del código duplicado y/o ineficiente.

3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo.

Entendimiento compartido.

1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos.

Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma sencilla.

2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de como funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema.

3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un simple programador posee un conjunto de código. Los defensores de XP argumentan que mientras haya más gente trabajando en una pieza, menos errores aparecerán.

4. Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona.

Bienestar del programador.

La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad. Como dice Beck, está bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas.

RUP

RUP Proceso Unificado




• El Proceso Unificado es un proceso de desarrollo de software: “conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software”.

• RUP es un marco genérico que puede especializarse para una variedad de tipos de sistemas, diferentes áreas de aplicación, tipos de organizaciones, niveles de aptitud y diferentes tamaños de proyectos.

• RUP está basado en componentes. El software esta formado por componentes de software interconectados a través de interfaces.

• RUP está dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental.

Dirigido por Casos de Uso

• Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema.

• Todos los casos de uso juntos constituyen el modelo de casos de uso.

• Los casos de uso también guían el proceso de desarrollo (diseño, implementación, y prueba). Basándose en los casos de uso los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso. De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, avanza a través de una serie de flujos de trabajo que parten de los casos de uso.

Iterativo e Incremental

• Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas pequeñas o mini proyectos.

• Cada mini proyecto es una iteración que resulta en un incremento.

• Las iteraciones hace referencia a pasos en el flujo de trabajo, y los incrementos a crecimientos en el producto.

• Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada.

• Los desarrolladores basan la selección de lo que implementarán en cada iteración en dos cosas: el conjunto de casos de uso que amplían la funcionalidad, y en los riesgos más importantes que deben mitigarse.

• En cada iteración los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, para

• implementar dichos casos de uso. Si la iteración cumple sus objetivos, se continúa con la próxima. Sino deben revisarse las decisiones previas y probar un nuevo enfoque.



El Ciclo de Vida del Proceso Unificado



El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del sistema.



Fases

Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición.



Disciplinas

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son:

Requerimientos, Análisis, Diseño, Codificación, y Prueba.

El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visión tradicional en cascada.

















Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba.




El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos desde el modelo de casos de uso hasta el modelo de pruebas.

MODELO DE CICLO DE VIDA

1. Ciclo de Vida Clásico Relevamiento Análisis Diseño Preliminar Prueba de Sistema Prueba de unidad Prueba de Subsistema Estudio de requisitos requerimientos del usuario Calendario, presupuesto pedido de requisitos especificación funcional necesidades de rendimiento especificación del sistema configuración final especificación del programa módulos codificados módulos probados subsistemas probados sistema probado Diseño detallado Codificación
2. Ciclo de Vida Estructurado 1. Factibilidad 2. Análisis 3. Diseño 8. Conversión de Bases 6. Ctrol. de Calidad 4. Implemen- tación 9. Instalación Usuarios Directorio Operaciones 5. Pruebas de Aceptación 7. Desc. de Proced. Directorio requerimientos del sistema políticas de usuario restricciones restricciones operacionales base de datos existentes documento especificación estructurada especificación de diseño sistema instalado Informe tentativo costo- beneficio restricciones reporte de costo- beneficio conjunto de pruebas de control de calidad manual del sistema sistema integrado sistema aceptado base de datos convertidas
3. Prototipo
 Antes o después se dispondrá de un modelo gráfico completo del sistema, que será la vía para reemplazarlo por el sistema definitivo.
 Que pueda incurrirse peligrosamente en suponer que el prototipo es el sistema en producción.
o Inferimos
 No puede manejar altos volúmenes de transacciones. Carece de detalles operativos, tales como, recuperaciones de errores, rastreos de auditoría, facilidades de backups, documentación para el usuario y procedimiento de conversión.
4. Estrategia de modelado A partir del modelo físico actual Modificar Modelo Esencial Actual Usuario Modelar Sistema Físico Actual Derivar Esencia Sistema Actual Información del sistema actual Nuevos requerimientos Modelo lógico actual Nuevo modelo lógico Modelo físico actual Usuario Modelar Sistema Físico Actual Modificar Modelo Esencial Actual Usuario Modelar Sistema Físico Actual Derivar Esencia Sistema Actual Modificar Modelo Esencial Actual Usuario Modelar Sistema Físico Actual
5. Estrategia de modelado Con abstracción de la encarnación actual Modificar Modelo Esencial Actual Usuario Modelar Esencia Sistema Actual Información del sistema actual Nuevos requerimientos Nuevo modelo lógico Modelo lógico actual Modificar Modelo Esencial Actual Usuario Modelar Esencia Sistema Actual
6.
o 1- Estudio de Factibilidad.
o 2- Análisis.
o 3- Diseño.
o 4- Implementación.
o 5- Generación de Test de Aceptación.
o 6- Control de Calidad.
o 7- Descripción de Procedimientos.
o 8- Conversión de Base de Datos.
o 9- Instalación.

CODIFICAR Y CORREGIR

Es un modelo poco útil, pero sin embargo bastante común Se puede tener una especificación formal, o no tenerla Si no se ha utilizado formalmente un método, probablemente ya se esté usando el método Codificar y Corregir en forma intuitiva Cuando se utiliza éste método se empieza con una idea general de lo que se necesita construir, Se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo.
Ventajas:
No conlleva ninguna gestión; no se pierde tiempo en la planificación, en la documentación, en el control de calidad, en el cumplimiento de los estándares, o en cualquier otra actividad que no sea codificación pura.
Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso.
Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa está familiarizada con éste modelo.
Para proyectos pequeños que se intentan liquidar en un tiempo breve, o para modelos como programas de demostración o prototipos desechables, el modelo codificar y corregir puede ser útil.
Desventajas:
El modelo resulta peligroso para otro tipo de proyectos que no sean pequeños.
Puede que no suponga gestión alguna, pero tampoco ofrece medios de evaluación del progreso.
No proporciona medios de evaluación de la calidad o de identificación de riesgos.
Si al llevar tres cuartas partes de la codificación descubre que el diseño es incorrecto, no hay otra solución que desechar el trabajo y comenzar de nuevo.

ESPIRAL


Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini-proyectos.
Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estén controlados.
Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada.
Método Desarrollo en Espiral
Funcionamiento:
Se parte de una escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuación se establece una aproximación a la siguiente interacción.
Cada iteración supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel:
Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas. En cada bucle alrededor del espiral, la culminación del análisis de riesgo resulta una decisión de “seguir” o “no seguir”.
Cada interacción en el método espiral lleva consigo los seis pasos que a continuación se nombran: Determinar objetivos, alternativas y límites, Identificar y resolver riesgos, Evaluar alternativas,
Generar las entregas de esa iteración, y comprobar que son correctas.
En el modelo en espiral, las primeras iteraciones son las menos costosas.
Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseño, la implementación del producto y la prueba del mismo.
En cada Cuadrante del Método espiral se realiza las siguientes actividades:
Planificación:
Determinación de objetivos, alternativas, restricciones, y elaboración del plan de desarrollo para el ciclo actual.
Análisis de Riesgos:
Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto
Ingeniería:
Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc. Evaluación por el cliente, Valoración de resultados.

METODOLOGIA ESTRUCTURADA


• Se maneja como proyecto
• Gran volumen de datos y transacciones
• Abarca varias áreas organizativas de la empresa
• Tiempo de desarrollo largo
• Requiere que se cumplan todas las etapas, para poder cumplir las siguientes (progresión lineal y secuencial de una fase a la otra)



Todo proceso de desenvolvimiento de software usando metodología Estructurada simplificada está basado en la identificación de los eventos a los que el sistema debe responder.
La secuencia metodológica es al siguiente:
• Definir la lista de eventos
Desarrollar una lista de requerimientos en lenguaje natural según lo descripto en el punto 4.2.1.
• Producir un diagrama de contexto
Modelizar la relación del sistema con el contexto, determinando cuales son las áreas de la empresa que participarán del sistema como fuentes de información
• Definir el modelo comportamental
Utilizamos el DFD como herramienta modeladora de la transformación de las entradas en salidas
Modelizar la relación de los repositorios de datos con la técnica del Modelo Relacional de Datos. -RDM
• Crear el modelo de implementación del usuario
Definir los módulos del sistema. En esta etapa son decididos los procesos a ser automatizados; se somete a la evaluación del usuario cada proceso del modelo comportamental
• Definir los requisitos de implementación
Mientras son definidos los procesos a ser informatizados, se debe discutir y documentar los requisitos de implementación de esos procesos y del sistema de software como un todo: Desempeño, restricciones de costos, restricciones operacionales, consideraciones sobre seguridad y auditoría, tecnología a ser empleada, modificaciones en procedimientos manuales y en otros sistemas informatizadas ya existentes.
• Elaborar diagramas de estructura.
Para cada proceso a ser automatizado, será creado un diagrama de estructura. Las funciones de los diagramas son derivadas de los flujos de datos que entran y que salen de los proceso, y de las transformaciones que generan los datos de salida a partir de los datos de entrada.
• Integrar los diagramas de Estructura.
Los diagramas de estructura deben ser integrados en programas, el agrupamiento de funciones puede ser hecho por proximidad temporal de utilización, rutinas On-Line, mensual, anual, etc., o por cualquier otro tipo de afinidad, como por ejemplo, en el caso de sistemas distribuido, el agrupamiento es hecho conforme al procesador en que serán ejecutadas las funciones. La estructura del software es completada, incorporándose a él módulos de apoyo operacional, como: módulos de implementación de backups, módulos de control, módulos para la creación y restauración de índices, módulos para alteración de parámetros de operaciones, etc. estos módulos serán incorporados al Diagrama de estructura, donde el acceso a ellos fuese mas conveniente
• Proyectar la interfaz con el usuario
La parte mas importante y mas compleja de la interfaz con el usuario será desarrollada a partir de los flujos de datos de entrada y de salida de los procesos a ser automatizados. Una única interfaz puede ser generada para atender varios flujos simultáneamente. Las interfaces necesarias a los módulos que implementan menús de selección y a los módulos de apoyo operacional complementaran el proyecto de la interfaz con el usuario.
• Proyectar la base de datos física
Definir las características físicas de cada dato, como el tipo el dominio; la organización de cada archivo, como la definición de las llaves principales, índices, etc.
• Especificar los módulos.
La especificación de los módulos, a través de pseudo código flujogramas u otros


SCROM

Scrum permite además seguir de forma clara el avance de las tareas a realizar, de forma que los "jefes" puedan ver día a día cómo progresa el trabajo.

Sin embargo, Scrum no es una metodología de desarrollo, puesto que no indica qué se debe hacer para hacer el código. Debería, por tanto, complementarse con alguna otra metodología de desarrollo. Se lleva bien con las metodologías ágiles y en concreto, con la programación extrema.

METODOLOGIAS DE DESARROLLO DE SITEMAS DE INFORMACION


Son métodos que indican cómo hacer más eficiente el desarrollo de sistemas de información. Para ello suelen estructurar en fases la vida de dichos sistemas con el fin de facilitar su planificación, desarrollo y mantenimiento.
Las metodologías de desarrollo de sistemas deben definir: objetivos, fases, tareas, productos y responsables, necesarios para la correcta realización del proceso y su seguimiento.
Los principales objetivos de una metodología de desarrollo son:
• Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí.
• Satisfacer las necesidades de los usuarios del sistema.
• Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo.
• Ajustarse a los plazos y costes previstos en la planificación.
• Generar de forma adecuada la documentación asociada a los sistemas.
• Facilitar el mantenimiento posterior de los sistemas.
Una metodología completa es algo más que una notación, un proceso, y herramientas. Además de una "notación, de un proceso, y de herramientas," estas "metodologías completas" proporcionan:
• Guías para estimar costos,
• Manejo del proyecto en las tareas y entregas,
• Medidas y métricas,
• Formas definidas y dirección en las entregas de la construcción,
• Políticas y procedimientos para garantizar la calidad del software,
• Descripciones de los roles y programas de entrenamiento detallados,
• Ejemplos totalmente trabajados,
• Ejercicios de entrenamiento,
• Técnicas para adaptar el método, y
• Técnicas definidas
Generaciones de metodología:
1. Desarrollo convencional
2. Desarrollo estructurado
3. Desarrollo orientado a objetos
Desarrollo convencional.
• Los resultados finales son impredecibles
• No hay forma de controlar lo que está sucediendo en el Proyecto
• Los cambios organizativos afectan negativamente al proceso de desarrollo

Desarrollo estructurado.
• Programacion estructurada
• Diseño estructurado
• Analisis estructurado
• Especificaciones funcionales
o Graficas
o Particionadas
o Minimamente redundantes

CARACTERISTICAS DESEABLES DE UNA METODOLOGIA

• Existencia de reglas predefinidas
• Cobertura total del ciclo de desarrollo
• Verificaciones intermedias
• Planificación y control
• Comunicación efectiva
• Utilización sobre un abanico amplio de proyectos
• Fácil formación
• Herramientas CASE
• Actividades que mejoren el proceso de desarrollo
• Soporte al mantenimiento
• Soporte de la reutilización de software

CLASIFICACIONES:
• Estructuradas
o Orientadas a procesos
o Orientadas a datos
 Jerarquicas
 No jerárquicas
o Mixtas
• Orientadas a objetos
• Para sistemas de tiempo real

INCREMENTAL

INCREMENTAL
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.

Los principios básicos son:

Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequeña parte de los sistemas, antes de proceder a la próxima incremental, o
Se definen los requisitos antes de proceder con la evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema, o
El concepto inicial de software, análisis de las necesidades, y el diseño de la arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalación del prototipo final.

METODOLOGIAS ORIENTADA A OBJETOS

Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad, código que es dificil de modificar, ciclos de desarrollo largos y tecnicas de codificacion no intuituvas.

Un lenguajeorientado a objetos ataca estos problemas. Tiene tres características basicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.

El concepto de programaciónorientada a objetos (OOP) no es nuevo, lenguajes clásicos como SmallTalk se basan en ella. Dado que la OOP. se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolución del problema se realiza en términos de objetos, un lenguaje se dice quOrganización de loLos objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".

1. RELACIONES

Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.

Las hay de dos tipos fundamentales:

-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero
s objetos

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.

Existen varios tipos tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "arbol". En otros casos puede ser más compleja.

En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.

-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteríza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.

-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clasesde objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.
e está basado en objetos si soporta objetos como una característica fundamental del mismo.


El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.

Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bién estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.

ESTRUCTURA DE UN OBJETO

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:


1 - RELACIONES

2 - PROPIEDADES

3 - METODOS

Cada uno de estos componentes desempeña un papel totalmente independiente:

Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por punteros a otros objetos.

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.

Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.

Encapsulamiento y ocultación

Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la OOP.

Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuída la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información.

Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto. deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas ordenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla.

El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. Si el objeto ha sido bien construído, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilización de programas
Organización de los objetos

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.

Existen varios tipos tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "arbol". En otros casos puede ser más compleja.

En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.

-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteríza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.

-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clasesde objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.
Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".

1. RELACIONES

Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.

Las hay de dos tipos fundamentales:

-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero



Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que e

n una organizacion jerárquica compleja un hijo puede tener varios padres).

-Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización.

Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que permita al usuario obtener la definición de una palabra cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la organización jerárquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo


METODOS

Una operación que realiza acceso a los datos. Podemos definir método como un programa procedimental o procedural escrito en cualquier lenguaje, que está asociado a un objeto determinado y cuya ejecución sólo puede desencadenarse a través de un mensaje recibido por éste o por sus descendientes.

Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin embargo, es conveniente utilizar el término 'método' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su campo de acción, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos.

Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un método de dos maneras diferentes:

-Métodos propios. Están incluídos dentro de la cápsula del objeto.

-Métodos heredados. Estan definidos en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A veces estos métodos se llaman métodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase.

Polimorfísmo

Una de las características fundamentales de la OOP es el polimorfísmo, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría Demonios suma, mientras que para un objeto STRING significaría concatenación ("pegar" strings uno seguido al otro)

DEMONIOS


Es un tipo especial de métodos, relativamente poco frecuente en los sistemasde OOP, que se activa automáticamente cuando sucede algo especial. Es decir, es un programa, como los métodos ordinarios, pero se diferencia de estos porque su ejecución no se activa con un mensaje, sino que se desencadena autmáticamente cuando ocurre un suceso determinado: la asignación de un valor a una propiedad de un objeto, la lectura de un valor determinado, etc.

Los demonios, cuando existen, se diferencian de otros métodos por que no son heredables y porque a veces están ligados a una de las propiedades de un objeto, mas que al objeto entero

Beneficios que se obtienen del desarrollo con OOP

Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de ingenieríade software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfases hombre-máquina "a-la-Windows" suele ser bastante conveniente.

Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc.

Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad del código orientado a objetos, es más sencillo modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en consecuencia un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos respectivos permanezcan intactos. La introducción de tecnologíade objetos como una herramienta concepual para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente extendibles y a partir de componentes reusables. Esta reusabilidad del código disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software

CASCADA

METODO DE CASCADA

Modelo en cascada está dirigido por documentos.

SIRVE PARA:

Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
Ayuda a minimizar los gastos de la planificación porque permite realizarla sin planificación porque permite realizarla sin problemas.
los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rápido. Incluso en los casos en los que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada (con retroceso) pueden funcionar mejor.
Las desventajas del modelo se centran en las dificultades para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningún trabajo de diseño y antes de escribir ningún código.
No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, métodos y actividades que abarcan varias etapas de la cascada; estas actividades son difíciles de ajustar en las etapas discontinuas del modelo para un proyecto de desarrollo rápido, el modelo en cascada puede suponer una cantidad excesiva de documentación.
El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento.


Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implementación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el término "cascada" de este artículo.
Los principios básicos del modelo de cascada son los siguientes:

1-El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.

2-Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.

3-Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff por el usuario y la tecnología de la información de gestión al final de la mayoría de las fases antes de comenzar la próxima fase.

metodologias

Descripción de las metodologías existentes para el desarrollo de software
Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta imprescindible teniendo en cuenta las necesidades cambiantes que tiene el entorno de desarrollo actual y el acelerado progreso de la informática a nivel mundial resulta una idea interesante. Estas metodologías pueden involucrar prácticas tanto de metodologías ágiles como de metodologías tradicionales
Metodología RUP
El proceso de desarrollo RUP aplica varias de las mejores practicas en el desarrollo moderno de software, en una forma que se adapta a un amplio rango de proyectos y organizaciones. Provee a cada miembro del equipo, un fácil acceso a una base de conocimiento con guías., plantillas y herramientas para todas las actividades criticas del desarrollo de software. Esta metodología permite que todos los integrantes de un equipo de trabajo, conozcan y compartan el proceso de desarrollo, una base de conocimientos y los distintos modelos de cómo desarrollar el software utilizando un lenguaje modelado común

El RUP es un proceso de desarrollo de software:

Su principal objetivo es asegurar la producción de software de alta calidad, que cumpla las necesidades de sus usuarios finales, que sea realizado en las fechas acordadas y con el presupuesto disponible.

El RUP es un producto:
IBM comercializa un producto que permite instancia al RUP según las características del proyecto, siendo una referencia en la metodología que sirve como repositorio único de información.

El RUP es un marco de trabajo
Este marco de trabajo puede ser adoptado y extendido para satisfacer las necesidades de la organización que lo utilice seleccionando las fases y interacciones, los flujos de trabajo y disciplinas que se van a recorrer y los entregables o productos que se van a construir. Es importante conocer como esta organizado y estructurado el proceso para poder seleccionar el frame work, los elementos del proceso que mas valor darán al proyecto.

El RUP incorpora muchas de las conocidas como “buenas practicas” en el desarrollo de software moderno, las cuáles se deben tener presentes en el desarrollo de aplicaciones empresariales para garantizar el éxito del proyecto, tales como: Desarrollo iterativo, Gestión de Requerimientos, Arquitectura basada en componentes, Modelo Visual, Verificación de la calidad en forma continua y control de cambios.

El RUP presenta 3 características:

1. Dirigido por los casos de uso.
2. Centrado en la arquitectura.
3. Ciclo de vida iterativo.

Otras características

• Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio•
Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integración final del sistema
• Reduce el costo del riesgo a los costos de un solo incremento
• Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener resultados claros a corto plazo
• Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada iteración.
• Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual además permite que se aprecien oportunidades de mejoras en el diseño
El proceso de desarrollo está dividido en Fases a lo largo del tiempo cada una de las cuales tiene objetivos específicos:

Las fases son las siguientes:

1) Inicio
2) Elaboración
3) Construcción
4) transición

Metodología UML

La metodología que se propone, denominada UML-MAST, concilia las diferencias entre la visión del diseñador de sistemas de tiempo real y la del de sistemas orientados a objetos. A tal fin define un nivel de abstracción adecuado para los elementos de modelado del comportamiento de tiempo real, que permite formularlos con una estructura paralela a la arquitectura lógica del sistema, y vincularlos a esta. La semántica de modelado sigue el perfil UML para planificabilidad, rendimiento y tiempo (SPT) estandarizado por el OMG, del que UML-MAST puede considerase una implementación. La propuesta se integra con las herramientas de análisis y diseño de sistemas de tiempo real MAST que analiza los modelos y retorna los resultados al modelo inicial para su interpretación por el diseñador. Asimismo, se han definido criterios para la extensión de esta metodología a otros niveles de abstracción tales como sistemas basados en componentes y sistemas implementados utilizando Ada 95. Parte de los resultados de este trabajo han sido incorporados por el OMG a su perfil SPT.

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
MSF
MSF es una metodología desarrollada por Microsoft Consulting Services en conjunto con varios grupos de negocios de Microsoft y otras fuentes de la industria. MSF provee los principios, modelos y disciplinas para un correcto desarrollo de proyectos en cualquier plataforma (Linux, Citrix, Microsoft, Unix).
Esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.
MSF características:
• Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.
• Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.
• Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
• Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.
MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo.
metodología: en cinco principales fases
• Visión y Alcances.
• Planificación.
• Desarrollo.
• Estabilización.
• Implantación.
Visión y Alcances: trata uno de los requisitos fundamentales para el éxito del proyecto, la unificación del equipo detrás de una visión común.
El equipo debe tener una visión clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en términos que motivarán a todo el equipo y al cliente. Se definen los líderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas últimas se deben respetar durante la ejecución del proyecto en su totalidad, y se realiza la evaluación inicial de riesgos del proyecto.
Es en esta fase es cuando la mayor parte de la planeación para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto.
Desarrollo: Durante esta fase el equipo realiza la mayor parte de la construcción de los componentes (tanto documentación como código), sin embargo, se puede realizar algún trabajo de desarrollo durante la etapa de estabilización en respuesta a los resultados de las pruebas
Scrum
Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro, porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.
Toma forma de las prácticas de trabajo que a partir de los 80 comienzan a adoptar algunas empresas tecnológicas y que Nonaka y Takeuchi acuñaron como "Campos de Scrum". El modelo Scrum, aplicado al desarrollo de software, emplea el principio de desarrollo ágil: "desarrollo iterativo e incremental", denominando sprint a cada iteración de desarrollo. Las prácticas empleadas por Scrum para mantener un control ágil en el proyecto son:
• Revisión de las iteraciones
• Desarrollo incremental
• Desarrollo evolutivo
• Auto-organización del equipo
• Colaboración
Define un marco para la gestión de proyecto. Está especialmente indicado a proyectos con un rápido cambio de requisitos. En Scrum inicialmente planean el contexto y un estimado amplio de la entrega. Luego desarrollan el estimado de la entrega basado en el desarrollo del ambiente del proyecto.
El proceso del ciclo de vida de Scrum reconoce que el proceso de desarrollo fundamental está completamente indefinido y usa mecanismos de control para perfeccionar la flexibilidad, manipular lo imprescindible y el control del riesgo.
Los valores que hacen posible a las prácticas de Scrum crear "campos de Scrum" son:
• Autonomía del equipo
• Respeto en el equipo • Responsabilidad y auto-disciplina
• Foco en la tarea
• Información transparencia y visibilidad
Programación Extrema XP
XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo.
XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. Kent Beck, el padre de XP, describe la filosofía de XP.
XP utiliza un técnica denominada Historias de Usuario es utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales.
Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
• Programador.
• Cliente.
• Encargado de pruebas (Tester).
• Encargado de seguimiento (Tracker).
• Entrenador (Coach).
• Consultor.
• Gestor (Big boss).
Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos.
XP consiste de seis fases
Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.
ICONIX
El proceso ICONIX se define como un proceso de desarrollo de software práctico. Está entre la complejidad de RUP y la simplicidad y pragmatismo de XP, sin eliminar las tareas de análisis y diseño que XP no contempla.
Es un proceso simplificado en comparación con otros procesos más tradicionales, que unifica un conjunto de métodos de orientación a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto. ICONIX presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Además, está adaptado a patrones y ofrece el soporte UML, dirigido por Casos de Uso y es un proceso iterativo e incremental.
características de ICONIX
• Iterativo e incremental: varias interacciones ocurren entre el modelo del dominio y la identificación de los casos de uso. El modelo estático es incrementalmente refinado por los modelos dinámicos.
• Trazabilidad: cada paso está referenciado por algún requisito. Se define la trazabilidad como la capacidad de seguir una relación entre los diferentes artefactos producidos
• Dinámica del UML: la metodología ofrece un uso dinámico del UML como los diagramas del caso de uso, diagramas de secuencia y de colaboración. Las tareas que se realizan en la metodología ICONIX son
• Análisis de requisitos
• Análisis y diseño preliminar
• Diseño
• Implementación
Crystal
Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos.
El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).
Crystal Clear
Alistair Cockburn es el propulsor detrás de la serie de metodologías Crystal. Las mismas presentan un enfoque ágil, con gran énfasis en la comunicación, y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP.
Crystal “Clear” es la encarnación más ágil de la serie y de la que más documentación se dispone. La misma se define con mucho énfasis en la comunicación, y de forma muy liviana en relación a los entregables. Crystal maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma part time para realizar validaciones sobre la Interfase del Usuario y para participar en la definición de los requerimientos funcionales y no funcionales del software.
Una cuestión interesante que surge del análisis de la serie Crystal es el pragmatismo con que se customiza el proceso. Las personas involucradas escogen aquellos principios que les resultan efectivos y mediante la aplicación de la metodología en diversos proyectos agregan o remueven principios en base al consenso grupal del equipo de desarrollo.
Los siete valores o propiedades son:
1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal o mensual.
2. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseñador senior; eso se llama Experto al Alcance de la Oreja. Una reunión separada para que los concurrentes se concentren mejor es descrita como El Cono del Silencio.
3. Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas por algunas semanas o una vez al mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir.
4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su código necesita mejorarse, o que sería conveniente que se bañase más seguido.
5. Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicación sobre dirección y prioridades, típicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles.
6. Fácil acceso a usuarios expertos.
7. Ambiente técnico con prueba automatizada, management de configuración e integración frecuente. Muchos equipos ágiles compilan e integran varias veces al día.
FDD
FDD es un proceso diseñado por Peter Coad, Erich Lefebvre y Jeff De Luca y se podría considerar a medio camino entre RUP y XP, aunque al seguir siendo un proceso ligero (en mi opinión, si tenemos que distinguir entre pesado/ligero) es más similar a este último. FDD está pensado para proyectos con tiempo de desarrollo relativamente cortos (menos de un año). Se basa en un proceso iterativo con iteraciones cortas (~2 semanas) que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar.
Las iteraciones se deciden en base a features (de ahí el nombre del proceso) o funcionalidades, que son pequeñas partes del software con significado para el cliente. Así, construir el sistema de ventas es algo que requiere mucho tiempo, y construir el sistema de persistencia no tiene significado para el cliente, pero si lo tiene enviar pedido por e-mail.
FDD se divide en 5 fases:
1. Desarrollo de un modelo general
2. Construcción de la lista de funcionalidades
3. Plan de releases en base a las funcionalidades a implementar
4. Diseñar en base a las funcionalidades
5. Implementar en base a las funcionalidades
3. Fases de FDD
4. Vista general de FDD
Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones, siendo las dos últimas las que absorben la mayor parte del tiempo según va avanzando el proyecto, limitándose las primeras a un proceso de refinamiento.
El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque siempre habrá un responsable último (arquitecto jefe o jefe de programadores en función de la fase en que se encuentre), con mayor experiencia, que tendrá la última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue que todos formen parte del proyecto y que los menos inexpertos aprendan de las discusiones de los más experimentados, y al tener un responsable último, se asignan las responsabilidades que todas las empresas exigen.
Las funcionalidades a implementar en una release se dividen entre los distintos subgrupos del equipo, y se procede a implementarlas. Las clases escritas tienen propietario (es decir, solo quién las crea puede cambiarlas), es por ello que en el equipo que implementa una funcionalidad dada deberán estar todos los dueños de las clases implicadas, pudiendo encontrarse un programador en varios grupos, implementando distintas funcionalidades. Habrá también un programador jefe (normalmente el más experimentado) que hará las funciones de líder del grupo que implementa esa funcionalidad.
En el proceso de implementar la funcionalidad también se contemplan como partes del mismo (en otros métodos se describen como actividades independientes) la preparación y ejecución de pruebas, así como revisiones del código (para distribuir el conocimiento y aumentar la calidad) e integración de las partes que componen el software.
FDD también define métricas para seguir el proceso de desarrollo de la aplicación, útiles para el cliente y la dirección de la empresa, y que pueden ayudar, además de para conocer el estado actual del desarrollo, a realizar mejores estimaciones en proyectos futuros.
ASD
Este proceso consiste en un cambio de filosofía en las organizaciones pasando de la transición del modelo Comando-Control al modelo liderazgo-Colaboración. Lleva los conceptos de los Sistemas Adaptativos Complejos al campo de la Ingeniería de Software en particular. Dada la complejidad inherente al software concluye que la aplicación de esta teoría es esencial para el nuevo escenario que plantea la economía global.
ASD propone tres fases esenciales:
especulación
colaboración
aprendizaje
El proyecto comienza con una fase de especulación en que se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se irán realizando. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que no será el lugar en que finalizará el proyecto. En cada iteración, se aprenderán nuevas funcionalidades, se entenderán viejas cuestiones, y cambiarán los requerimientos.
La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construye la funcionalidad definida durante la especulación.
ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteración el equipo colabora intensamente para liberar la funcionalidad planificada. También existe la posibilidad de explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto profundamente. ASD no propone técnicas ni prescribe tareas al momento de llevar a cabo la construcción simplemente mencionando que todas las prácticas que sirvan para reforzar la colaboración serán preferidas, siguiendo de esta forma la línea de las metodologías ágiles respecto a la orientación a componentes.
La fase final de ASD, Aprender, consiste en la revisión de calidad que se realiza al final de cada ciclo.
Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar grupos de enfoque en el cliente, mediante los cuales se explora un modelo de la aplicación y se anotan los requerimientos de cambio del cliente.
Las revisiones al diseño, al código o a las pruebas permitirán aprender sobre la calidad de los mismos. En este caso, el énfasis estará puesto en aprender cuales han sido los errores o desvíos y poder resolverlos, y no en encontrar culpables. Asimismo, esta es la etapa en que se evaluarán las exploraciones que se hayan realizado dando la capacidad de poder modificar la arquitectura del sistema si se ha encontrado algún camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los requerimientos.
Finalmente se puede afirmar que ASD es un marco filosófico basado en la teoría de Sistemas Adaptativos Complejos que permite encarar la construcción de software en forma ágil utilizando las prácticas que resulten convenientes en cada caso. En este sentido resulta similar a Scrum.
AUPAgile Unified Process es una versión simplificada de Rational Unified Process, desarrollada por Scott Amber.
Divide el ciclo de desarrollo en 4 fases:
Incepción: identificación del alcance y dimensión del proyecto, propuesta de la arquitectura y de presupuesto del cliente.
Elaboración: Confirmación de la idoneidad de la arquitectura.
Construcción: Desarrollo incremental del sistema, siguiendo las prioridades funcionales de los implicados.
Transición: Validación e implantación del sistema.
DSDM
DSDM es otra metodología diseñada para responder a los plazos de entrega cortos y una cantidad limitada de recursos. Nace en 1994 con el objetivo de crear una metodología RAD (Desarrollo Rápido de Aplicaciones, en inglés, Rapid Application Development) unificada. Al igual que Cristal, DSDM se esfuerza por acortar las líneas de comunicación entre el cliente, promotor, y las empresas interesadas, a fin de prestar un servicio más eficiente en el proceso de producción de software. Al fijar el plazo de entrega (generalmente 6 meses) y el establecimiento de límites de los recursos, es más fácil establecer un proceso de desarrollo que responda a los usuarios "reales requerimientos del negocio." Según el sitio web del Consorcio DSDM, DSDM en un marco de desarrollo que "se centra en las prioridades del negocio y ofrece los entregados dentro de los plazos y costos del proyecto, en orden de prioridad determinado por las necesidades y los objetivos del proyecto.
Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos.
DSDM de 5 fases.
1. . Estudio de viabilidad
2. Estudio de negocio
3. Iteración de modelado funcional
4. Iteración de diseño y desarrollo
5. Implementación
Las tres últimas son iterativas, además de existir realimentación a todas las fases.
Xbreed
es una mezcla de XP y Scrum ideas desarrolladas por Mike Beedle. SCRUM XBreed utiliza como marco de gestión, mientras que la adaptación de una versión reducida de Extreme Programming para su proceso de desarrollo
Fue diseñado con la intención de desarrollar "software reutilizables en un tiempo récord." Mediante el empleo de patrones de diseño para crear los objetos reutilizables, XBreed crea una biblioteca de componentes que, idealmente, son fácilmente reinsertados en nuevos proyectos de software. El proceso de desarrollo depende en gran medida de la capacidad y los conocimientos de los miembros de su equipo, que requieren fuertes y poca transferencia de conocimientos generales de comunicación para mantener el proyecto funcionando bien y eficientemente, los requisitos son ayudados por el uso de SCRUM.
En la actualidad está evolucionando y cambiando de nombre. Mantiene los principios de gestión de Scrum, y ahora se denomina AE (Agile Enterprise).
Lean Development Lean
fue descrito por Mary Poppendieck, es una de las últimas contribuciones a la comunidad Ágil de Desarrollo de Software. Basado en los principios de producción ajustada japoneses, Lean es otro paradigma de desarrollo de naturaleza similar a la de Cristal y TEA en la medida en que fomenta un cambio en la cultura, así como un cambio en el proceso. Estos principios están diseñados para aumentar la velocidad de entrega, los productos de software de alta calidad y menor coste de producción.
Win-Win Spiral
propuesto por Barry Boehm es un nuevo logro en un proceso tradicional de software. Manteniendo al mismo tiempo muchos de los elementos tradicionales la versión Win-Win Spiral Model se esfuerza por comprender a todos los interesados en el proceso de desarrollo. Se trata de un motor de colaboración que establece que "ganar" las condiciones establecidas por los usuarios, clientes, desarrolladores, ingenieros de sistemas y con el fin de evolucionar y priorizar los requisitos durante todo el proceso. Las prácticas tradicionales, como los requisitos de ingeniería, diseño, código, y probar, aún están presentes en cada iteración de la espiral, pero el paso de colaboración durante el proceso de desarrollo hace que sea claramente de adaptación. Esta colaboración ofrece el software más rápido, con mayor calidad, menos costosa y, debido a la inicial de satisfacción de las necesidades de los usuarios y la cantidad reducida de mantenimiento
Estabilización: En esta fase se conducen pruebas sobre la solución, las pruebas de esta etapa enfatizan el uso y operación bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solución para el lanzamiento.
Implantación: Durante esta fase el equipo implanta la tecnología base y los componentes relacionados, estabiliza la instalación, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobación final del cliente.
MIDAS
es una metodología genérica y fácilmente adaptable a cualquier tipo de SIW. Es un framework metodológico para el desarrollo de Sistemas de Información para Windows (SIW por sus siglas en inglés), en el que se propone un proceso de desarrollo ágil integrado en una arquitectura dirigida por modelos, alineándose así con la propuesta MDA del OMG.
MIDAS propone modelar un SIW atendiendo a dos dimensiones ortogonales. Por un lado, y debido a que la metodología se basa en una propuesta MDA, es necesario tener en cuenta el grado de dependencia de la plataforma de los modelos construidos. En primer lugar, será necesario modelar el sistema construyendo modelos independientes de la computación (CIM), modelos independientes de la plataforma (PIM) y modelos específicos de la plataforma (PSM) y, en segundo lugar, será necesario especificar las reglas que permitan realizar transformaciones entre estos modelos. Por otro lado, la segunda dimensión a considerar está relacionada con tres aspectos básicos: el contenido (es decir, la información presente en el SIW), el hipertexto (relacionado con el modelado de las posibles rutas de navegación que podría seguir un usuario del SIW durante su interacción con el mismo) y el comportamiento propiamente dicho del sistema.
Además, MIDAS sugiere la utilización del Lenguaje de Modelado Unificado (UML) como única notación para modelar tanto los PIMs como los PSMs.
RMM
está basada en los conceptos implantados en el Modelo de diseño de hipertexto, es decir, en las entidades y en los tipos de entidades. Su objetivo es mejorar la navegación a través de un análisis de las entidades del sistema. En teoría, se obtiene una navegación más estructurada y logra que esta sea más intuitiva para el usuario. Los conceptos de slices y m-slices, que consisten en la agrupación de datos de una entidad en diferentes pantallas, es una de las aportaciones más importantes de esta metodología. Fue la primera metodología completa que se publica para software multimedia. Su problema principal es que no permite realizar consultas a partir de dos entidades y como está muy atado al modelo entidad relación cuando se define una relación se obliga a descomponerlas en dos relaciones copiando el modelo E-R. Además no considera las consultas a la base de datos para la creación de páginas Web dinámicas.
UWE
La propuesta de Ingeniería Web basada en UML es una metodología detallada para el proceso de autoría de aplicaciones con una definición exhaustiva del proceso de diseño que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Modelado.
UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial hincapié en características de personalización, como es la definición de un modelo de usuario o una etapa de definición de características adaptativas de la navegación en función de las preferencias, conocimiento o tareas de usuario.
Otras características relevantes del proceso y método de autoría de UWE son el uso del paradigma orientado a objetos, su orientación al usuario, la definición de un meta-modelo (modelo de referencia) que da soporte al método y el grado de formalismo que alcanza debido al soporte que proporciona para la definición de restricciones sobre los modelos.
OOHDME
Modelo de Diseño de Hipermedia Orientado a Objeto el sucesor del modelo de diseño hipertexto HDM, se trata de una metodología que se fundamenta en la orientación a objeto. Propone las siguientes fases: Diseño conceptual o análisis de dominio que utiliza el método de diseño orientado a objeto para obtener esquemas conceptuales de las clases y las relaciones entre las mismas. Utiliza las “técnicas de modelo de objeto” llamada notación OMT para el diseño de la navegación, donde se define la estructura de navegación por medio de modelos, es decir, a través de diferentes vistas del esquema conceptual; la fase de diseño de interfaz abstracta, se apoya en un modelo orientado a objeto para especificar la estructura y el comportamiento de la interfaz del sistema, este modelo se crea a través de tres tipos de diagramas: diagramas abstractos para cada clase, diagramas de configuración para reflejar los eventos externos y diagrama de estado para señalar el comportamiento dinámico; y por último, la fase de implementación, es decir, la construcción de los programas en programación orientada a objeto.