Es un conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a
los desarrolladores a realizar nuevo software.
Ilustracin Error! No text of specified style in document.-1: Metodologa - Ciclo de Vida Una Metodologa indica cmo hay que obtener los distintos productos parciales o finales y puede seguir uno o varios modelos de Ciclo de Vida. Un Ciclo de Vida indica que es lo que hay que obtener a lo largo del desarrollo del proyecto pero no indica cmo hacerlo.
Una Metodologa es un concepto ms amplio que Mtodo o Se puede considerar como un conjunto de mtodos. o Una metodologa puede englobar un conjunto de mtodos (de anlisis, diseo, programacin, etc.) para abarcar el ciclo de vida completo. o Clasificacin de las metodologas:
Ilustracin Error! No text of specified style in document.-2: Clasificacin de las Metodologas.
METODOLOGIAS ESTRUCTURADAS ORIENTADAS A PROCESOS ORIENTADAS A DATOS MIXTAS NO ESTRUCTURADAS ORIENTADAS A OBJETOS SISTEMAS DE TIEMPO REAL AGILES 2.3.1 Metodologas agiles vs metodologas tradicionales.
Metodologa gil Metodologa Tradicional Pocos Artefactos. El modelado es prescindible, modelos desechables. Ms Artefactos. El modelado es esencial, mantenimiento de modelos Pocos Roles, ms genricos y flexibles Ms Roles, ms especficos No existe un contrato tradicional, debe ser bastante flexible Existe un contrato prefijado Cliente es parte del equipo de desarrollo (adems in-situ) El cliente interacta con el equipo de desarrollo mediante reuniones Orientada a proyectos pequeos. Corta duracin (o entregas frecuentes), equipos pequeos (< 10 integrantes) y trabajando en el mismo sitio Aplicables a proyectos de cualquier tamao, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos La arquitectura se va definiendo y mejorando a lo largo del proyecto Se promueve que la arquitectura se defina tempranamente en el proyecto nfasis en los aspectos humanos: el individuo y el trabajo en equipo nfasis en la definicin del proceso: roles, actividades y artefactos Se esperan cambios durante el proyecto Se espera que no ocurran cambios de gran impacto durante el proyecto Ilustracin Error! No text of specified style in document.-3: Metodologas agiles vs metodologas tradicionales. 2.3.2 XP (Extreme Programmig)
La Programacin Extrema es una metodologa ligera de desarrollo de software que se basa en la simplicidad, la comunicacin y la realimentacin o reutilizacin del cdigo desarrollado.
Ilustracin Error! No text of specified style in document.-4: XP (Extreme Programmig)
Uso de la metodologa XP
XP surgi como respuesta y posible solucin a los problemas derivados del cambio en los requerimientos. Se plantea como una metodologa a emplear en proyectos de riesgo, adems XP aumenta la productividad del equipo de trabajo.
Las cuatro variables de XP son: Coste: Mquinas, especialistas y oficinas. Tiempo: Total y de Entregas. Calidad: Externa e Interna. Alcance: Intervencin del cliente. Su utilidad es medida con cuatro valores: Simplicidad en las soluciones implementadas. Comunicacin. Retroalimentacin. Coraje. XP Proceso ligero, gil, de bajo riesgo, flexible, predecible, cientfico y divertido de desarrollar software. Orientado hacia quien produce y usa el software Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema. Fases XP
Ilustracin Error! No text of specified style in document.-5: Fases XP
En las fases de XP se utilizan:
Se utilizan historias de usuario: las necesidades, escritas por los usuarios, con la ayuda de los diseadores, que quieren ser satisfechas con el sistema. Se crean los planes de entregas, los cuales estiman el tiempo de desarrollo de las historias de usuario. Se llevan a cabo la planificacin de iteracin: identificar las historias de usuario que se van a desarrollar en una iteracin especfica. Se desarrollan reuniones diarias, con el fin de facilitar la comunicacin entre el grupo de trabajo y la exposicin de los diferentes problemas. Se escoge una metfora de sistema, esto para facilitar el manejo consistente de los nombres de las clases y los mtodos. Se proponen soluciones a problemas tcnicos o de diseo. Se ignoran las funcionalidades extra que podran incorporarse al proyecto, es decir, se trata de centrar en lo principal. Se remueve la redundancia, se eliminan las funcionalidades no necesarias y se rejuvenecen los diseos obsoletos. Se utilizan estndares para escribir el cdigo. Se crean las pruebas antes de empezar a codificar, lo cual har ms sencillas y efectivas las pruebas. XP Planificacin Historias de Usuario Plan de entrega Velocidad del proyecto Iteraciones Rotaciones Reuniones Diseo Metafora del sistema Tarjetas CRC Soluciones Soluciones puntuales Funcionalidad minima Reciclaje Desarrollo Disponibilidad de cliente Unidad de Pruebas Programacin en parejas Integracin Pruebas Implantacin Pruebas de aceptacin Esta se realiza en equipos de trabajo y luego se lleva a cabo una integracin paralela (debido a esta integracin no se garantiza la consistencia y la calidad necesidad de hacer pruebas exhaustivas). Se deja la optimizacin para el final, una vez que el cdigo requerido este completo. Se crean pruebas de aceptacin a partir de las historias de usuario. El cliente es el responsable de revisar, tanto las pruebas de aceptacin, como los resultados obtenidos al ser stas aplicadas. Una historia de usuario no se considera lista hasta que haya pasado todas sus pruebas de aceptacin. Roles de XP
Las metodologas tradicionales imponen un proceso disciplinado, estn orientados a documentos y se vuelven demasiado burocrticas e ineficaces. XP es tiene la ventaja de estar ms orientada a las personas que a los procesos. 2.3.3 RUP (RationalUnifiedProcess)
RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cmo, cundo y qu debe hacerse en el proyecto .Como 3 caractersticas esenciales est dirigido por los Casos de Uso: que orientan el proyecto a la importancia para el usuario y lo que este quiere, est centrado en la arquitectura: que Relaciona la toma de decisiones que indican cmo tiene que ser construido el sistema y en qu orden, y es iterativo e incremental: donde divide el proyecto en mini proyectos donde los casos de uso y la arquitectura cumplen sus objetivos de manera ms depurada.
XP
Cliente Programador Tester Tracker Coach Consultor Big boss Como filosofa RUP maneja 6 principios clave: Adaptacin del proceso
El proceso deber adaptarse a las caractersticas propias de la organizacin. El tamao del mismo, as como las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto.
Balancear prioridades
Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.
Colaboracin entre equipos
El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados
Elevar el nivel de abstraccin Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. stos se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con UML. Enfocarse en la calidad El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin El ciclo de vida de RUP RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades.
Ilustracin Error! No text of specified style in document.-6: Ciclo de Vida RUP En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Se define el alcance del proyecto. Elaboracin: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos. Construccin: se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario. Transicin: se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.
Descripcin de las Actividades
Dependiendo de las iteraciones del proceso el equipo de desarrollo puede realizar 7 tipos de actividades en este:
Fase de Inicio
Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en actividades modelado del negocio y de requisitos.
Modelado del negocio
En esta fase el equipo se familiarizar ms al funcionamiento de la empresa, sobre conocer sus procesos.
o Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado. o Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. o Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo.
Requisitos En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.
Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podra hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Definir el mbito del sistema. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
Fase de Elaboracin
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura.
Anlisis y Diseo
En esta actividad se especifican los requerimientos y se describen sobre cmo se van a implementar en el sistema.
Transformar los requisitos al diseo del sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseo para que sea consistente con el entorno de implementacin
Fase de Construccin
Implementacin Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El resultado final es un sistema ejecutable. Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados, formando el Plan de Integracin. Cada implementador decide en qu orden implementa los elementos del subsistema. Si encuentra errores de diseo, los notifica. Se integra el sistema siguiendo el plan. Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas. Verificar las funciones del producto de software segn lo diseado. Verificar que los requisitos tengan su apropiada implementacin.
Despliegue
Esta actividad tiene como objetivo producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos.
Durante todo el Proyecto
Gestin del proyecto
Se vigila el cumplimiento de los objetivos, gestin de riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.
Proveer un marco de trabajo para la gestin de proyectos de software intensivos. Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos.
Configuracin y control de cambios
El control de cambios permite mantener la integridad de todos los artefactos que se crean en el proceso, as como de mantener informacin del proceso evolutivo que han seguido.
Entorno
La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas, procesos y mtodos. Brinda una especificacin de las herramientas que se van a necesitar en cada momento, as como definir la instancia concreta del proceso que se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
Seleccin y adquisicin de herramientas. Establecer y configurar las herramientas para que se ajusten a la organizacin. Configuracin del proceso. Mejora del proceso. Servicios tcnicos.
Roles en RUP
Analistas: Analista de procesos de negocio. Diseador del negocio. Analista de sistema. Especificador de requisitos.
Desarrolladores: Arquitecto de software. Diseador. Diseador de interfaz de usuario. Diseador de cpsulas. Diseador de base de datos. Implementador. Integrador.
Gestores: Jefe de proyecto. Jefe de control de cambios. Jefe de configuracin. Jefe de pruebas. Jefe de despliegue. Ingeniero de procesos. Revisor de gestin del proyecto. Gestor de pruebas.
Apoyo: Documentador tcnico. Administrador de sistema. Especialista en herramientas. Desarrollador de cursos. Artista grfico.
Especialista en pruebas: Especialista en Pruebas (tester). Analista de pruebas. Diseador de pruebas.
Otros roles: Stakeholders. Revisor. Coordinacin de revisiones. Revisor tcnico
Notas: Para grandes organizaciones con un nmeros equipos de ingenieros y la comunicacin entre cada equipo es crtica por lo tanto es necesario que los artefactos sean completos y bastante comprensivos. En tanto que para pequeos proyectos no es recomendable presentarse tanto rigor en las preparaciones de los artefactos, la eficiencia del proceso depende ms de las habilidades de cada trabajador.
Programacin modular
En la programacin modular consta de varias secciones dividas de forma que interactan a travs de llamadas a procedimientos, que integran el programa en su totalidad.
En la programacin modular, el programa principal coordina las llamadas a los mdulos secundarios y pasa los datos necesarios en forma de parmetros. A su vez cada modulo puede contener sus propios datos y llamar a otros mdulos o funciones.
Programacin orientada a objetos (POO) Se trata de una tcnica que aumenta considerablemente la velocidad de desarrollo de los programas gracias a la reutilizacin de los objetos. El elemento principal de la programacin orientada a objetos es el objeto. El objeto es un conjunto complejo de datos y programas que poseen estructura y forman parte de una organizacin. Un objeto contiene varios datos bien estructurados y pueden ser visibles o no dependiendo del programador y las acciones del programa en ese momento. El polimorfismo y la herencia son unas de sus principales caractersticas y por ello dedicaremos ms adelante un artculo exclusivamente a tratar estos dos trminos.
Programacin concurrente Este tipo de programacin se utiliza cuando tenemos que realizar varias acciones a la vez. Se suele utilizar para controlar los accesos de usuarios y programas a un recurso de forma simultanea. Se trata de una programacin ms lenta y laboriosa, obteniendo unos resultados lentos en las acciones.
Programacin funcional Se caracteriza principalmente por permitir declarar y llamar a funciones dentro de otras funciones.
Programacin lgica Se suele utilizar en la inteligencia artificial y pequeos programas infantiles. Se trata de una programacin basada en el clculo de predicados (una teora matemtica que permite lograr que un ordenador basndose en hecho y reglas lgicas, pueda dar soluciones inteligentes).