Fuente: http://www.wikilearning.com/articulo/mds_360__metodologia_de_desarrollo_de_softw are/24658 PORTADA MDS 360 METODOLOGA DE DESARROLLO DE SOFTWARE UN ENFOQUE PRCTICO Y GLOBAL VERSIN 1.0.

11 BETA (20071020) WILSON JAVIER ARGELLO GMEZ wilson.arguello@otcolombia.com REA DE INVESTIGACIN 2004-2007 ORANGE TECHNOLOGIES www.otcolombia.com BOGOT, COLOMBIA 0 RESUMEN MDS 360 define las actividades y sub-actividades que comprende un proyecto de desarrollo de software desde un enfoque prctico y global. 1 PREMBULO El desarrollo de software es un proceso exigente y la falta de una metodologa estndar y prctica lo ha convertido en un trabajo individual y casi artstico donde cada programador tiene su propia forma de hacer las cosas. En el mbito empresarial se requiere trabajo en equipo con personal interdisciplinario y objetivos comunes y una metodologa de desarrollo es indispensable. Varias circunstancias (que se abordan en los principios de esta metodologa) tienden a generar software ms parecido a una colcha de retazos que a una solucin integral que satisfaga al cliente y apoye los procesos empresariales. 2 DEFINICIN Un proyecto de desarrollo de software es el esfuerzo que se emprende para crear o mejorar un programa. MDS 360 define las actividades y sub-actividades que comprende un proyecto de desarrollo de software desde un enfoque prctico y global. Es prctico por su baja complejidad y porque aporta plantillas para la mayora de las tareas y global porque comprende todas las fases del proyecto. 3 PRINCIPIOS

La base de esta metodologa consiste en fortalecer las actividades de los proyectos de desarrollo de software con procedimientos, documentos y soportes que respalden la correcta ejecucin del proyecto. Aseguramiento de la calidad Cumplir las acciones implantadas en el sistema de calidad de cada empresa. Administracin y control del proyecto Administrar tareas y tiempos, realizar seguimientos, conocer el estado actual y mantener la retroalimentacin del proyecto. Documentacin Llevar el registro de todas las actividades del proyecto y mantener la documentacin al da. Entregas Cumplir con el propsito, el alcance y los plazos estimados. Los entregables no slo son programas definitivos, tambin se incluye programas para pruebas, capacitacin, documentacin tcnica, manual de usuario, entre otros. 4 ACTIVIDADES MDS 360 se basa en actividades y sub-actividades que se pueden realizar en secuencia o paralelo dependiendo de las caractersticas de cada proyecto. Anlisis de requerimientos Entrevistas Anlisis documental Lista de funcionalidades Diagrama y especificacin de casos de uso Definicin de la solucin Definicin de la arquitectura Definicin de la plataforma Definicin del cronograma Plan de entregas Implementacin Especificacin de clases y operaciones Diseo de base de datos Diseo de interfaz de usuario Implementacin de clases y operaciones Pruebas de desarrollo Actualizacin de manuales Integracin y entrega

Pruebas y aceptacin Capacitacin de usuario lder Pruebas de usuario Aceptacin Implantacin Capacitacin de usuarios Paso a produccin Post-implantacin y mantenimiento Copias de seguridad Actualizacin de componentes Cambios en la informacin Soporte tcnico Mejoras Gestin de mejoras Gestin de errores 4.1 ANLISIS DE REQUERIMIENTOS Esta actividad trata lo relacionado con la interpretacin, aclaracin y entendimiento de los requerimientos del cliente. Siempre se debe definir primero los procesos inmersos en el requerimiento y sobre ellos realizar el planteamiento del programa. Nunca se debe definir los procesos a partir del anlisis de requerimientos. Es un error muy comn entender que los desarrolladores de software son analistas de procesos. El anlisis de requerimientos genera el documento de especificacin de requerimientos del software: que es la descripcin completa del comportamiento y la lista de funcionalidades del programa a desarrollar. El documento de especificacin de requerimientos tambin debe incluir los requerimientos no funcionales que son aquellos que limitan tanto el diseo como la implementacin, entre ellos tenemos la confiabilidad, la escalabilidad y el costo. 4.1.1 Entrevistas Las entrevistas estn implcitas en las reuniones, juntas, conferencias, dilogos y dems espacios donde se analiza los requerimientos mediante el mtodo de pregunta y respuesta. Es preciso que el cuestionario est preparado con anticipacin al encuentro, sin embargo, sobre la marcha de la reunin pueden aparecer nuevas preguntas que complementen el interrogatorio. Se recomienda grabar la entrevista en audio y/o vdeo con el fin de repasar lo conversado y sobre todo para realizar su trascripcin en los documentos de soporte

establecidos. Toda entrevista debe estar debidamente documentada. 4.1.2 Anlisis documental En la prctica toda aplicacin debe cumplir con un marco regulado por documentos (leyes, decretos, normas, polticas, circulares, principios, etc). Es comn entregar a los desarrolladores los documentos que regulan el programa cuando lo correcto es que se les entregue los procesos. El anlisis documental ayuda a entender y precisar los requerimientos. 4.1.3 Lista de funcionalidades Una funcionalidad es una parte del programa que tiene significado para el cliente y debe ser ejecutable, medible, probable y descrita con suficiente detalle para mejor comprensin del programador. La lista de funcionalidades es el eje fundamental de esta metodologa. Las funcionalidades complejas se deben desagregar en funcionalidades ms simples y de ms fcil comprensin. Cada funcionalidad se desarrolla individualmente y precisa su propio diseo, implementacin, pruebas, aceptacin e integracin. Se debe definir el formulario de pruebas que debe satisfacer cada funcionalidad. La satisfaccin del formulario de pruebas es el punto de inflexin que usa el usuario lder para aceptar el paso a produccin de cada funcionalidad. 4.1.4 Casos de uso Un caso de uso es una tcnica usada para plasmar los requerimientos funcionales de un sistema. Los casos de uso se describen en un lenguaje de usuario como UML, no debe describirse con terminologa tcnica, y por lo general se desarrolla entre el cliente y el programador. Esta metodologa establece que debe haber por lo general un caso de uso por cada funcionalidad. Cuando una funcionalidad presenta variantes en su procedimiento es preciso crear un caso de uso para cada comportamiento. 4.2 DEFINICIN DE LA SOLUCIN Es el proceso que se realiza para resolver el problema y plantear la solucin. 4.2.1 Definicin de la arquitectura

Define la estructura del sistema que comprende: los componentes, las propiedades externas de estos componentes y la relacin entre ellos. Un componente es todo elemento del sistema que ofrece un servicio predefinido. Un componente puede ser: un servicio web, una biblioteca de clases, un programa, un dispositivo, un driver, etc. Algunos patrones o estilos de arquitectura son: cliente-servidor, modelo por capas, computacin distribuida, Puesto-A-Puesto, por plugins, orientada a servicios, entre otras. 4.2.2 Definicin de la plataforma La plataforma hace referencia al hardware y software usado tanto para el desarrollo como para la implantacin. Se debe definir el ambiente tanto de desarrollo como de implantacin: hardware, computadores, impresoras, sistema operativo, lenguaje de desarrollo, base de datos, drivers, dispositivos, etc. 4.2.3 Definicin del cronograma El costo de un proyecto se fundamenta en el tiempos que toma el desarrollo de cada actividad. La duracin de cada actividad se debe estimar en horas hombre. Entre los desarrolladores hay la costumbre de subestimar los tiempos de cada tarea basndose en suposiciones y comparativos apresurados e informales. Es preciso que la definicin de tiempos est acorde con la realidad bajo el anlisis realizado. Siempre hay que desconfiar de los cronogramas con tiempos muy cortos. Y se debe alejar del anlisis de tiempos las presiones y premuras que provienen del solicitante, usuarios finales, administrador del proyecto y la misma empresa. Se recomienda que los das laborales no sobrepasen la carga normal de horas de trabajo. Las largas jornadas laborales no siempre llevan a acelerar las tareas. Es mejor tener un cronograma largo y viable que corto e ilusorio. En el cronograma tambin se debe agregar las tareas ya realizadas. 4.2.4 Plan de entregas El plan de entregas es la planificacin del desarrollo de las funcionalidades por grupos o mdulos con el fin de entregar un programa totalmente funcional y listo para entrar a produccin.

Para cada entrega se debe planificar las funcionalidades a desarrollar y el periodo de tiempo que tomar su desarrollo. El periodo entre entregas puede ser de 1 mes siempre que el proyecto tome ms de 2 meses, para proyectos pequeos las entregas pueden ser cada 15 das. El periodo es propio de cada proyecto, de cada grupo de desarrollo y de cada empresa; posiblemente generar programas cada cierto tiempo funciones correctamente para unas empresa y no para otras, todo depende de la dinmica del procedo de desarrollo: personal exclusivo para desarrollo, suficiente personal de pruebas, requerimientos cambiantes, calidad de los desarrolladores, etc. 4.3 IMPLEMENTACIN Proceso de desarrollo de cada funcionalidad. Se debe implementar una funcionalidad a la vez, realizando todas las sub-actividades. 4.3.1 Especificacin de clases Diseo y declaracin de las clases y operaciones de cada funcionalidad. En lo posible se recomienda apoyarse en UML para la especificacin de cada clase y generar el diagrama de clases. 4.3.2 Diseo de base de datos El diagrama E/R es el bosquejo bsico del diseo de base de datos pero el entregable de esta sub-actividad es el script de generacin o modificacin de la estructura de datos. Se debe especificar las tablas, campos y relaciones y definir los ndices, llaves primarias, llaves forneas, constreimientos, datos por defecto, etc. 4.3.3 Diseo de interfaz de usuario Esta es la parte visual del programa y la que ms aprecia el usuario final. El usuario final quiere algo agradable, amigable, fcil de usar, completo pero sencillo, estndar y personalizable. Los programas deben tener un diseo homogneo. Se debe tener en cuenta el tamao de las ventanas, de la fuente, los colores, los fondos, la usabilidad, la ergonoma, etc. Tambin hacer parte de la interfaz los reportes, los archivos de salida y en general cualquier exposicin del programa a nuestros sentidos. 4.3.4 Implementacin de clases y operaciones

Codificacin de las clases y su operaciones. La implementacin incluye: interpretacin, creacin, reutilizacin, refinamiento, integracin, compilacin y prueba del cdigo fuente. Tambin hace parte de esta sub-actividad el control de errores, manejo de transacciones, empaquetamiento de clases, comunicacin entre desarrolladores, integracin de cdigo fuente, etc. 4.3.5 Pruebas de desarrollo Las pruebas de desarrollo se deben realizan en un ambiente ms parecido al ambiente de produccin que al de pruebas. En lo posible usar un base de datos que no sea la de desarrollo. Se debe realizar pruebas con datos lo ms parecido a la realidad. Cuidado con las pruebas donde se llenan todos los campos con 1!. Las pruebas se basan en el formulario de pruebas establecido para cada funcionalidad. Un buen examen e inspeccin de lo desarrollado genera tranquilidad y sobre todo calidad. 4.3.6 Actualizacin de manuales Tan pronto se tiene lista cada funcionalidad se debe actualizar los manuales: el tcnico y el de usuario final. Se sugiere que el manual de usuario est incluido en el programa y que sea contextual, es decir, que el usuario en cualquier momento tenga la opcin de solicitar la ayuda en lnea de la funcionalidad que est trabajando. El manual tcnico debe incluir una seccin clara donde ser indique el cambio en la plataforma y en los componentes para el paso a produccin del nuevo desarrollo. 4.3.7 Integracin y entrega La integracin cosiste en tomar los fuentes de la entrega anterior y agregar el cdigo fuente de las nuevas funcionalidades desarrolladas y generar el programa ejecutable y/o el instalador segn sea conveniente. Se entrega el programa, los scripts de cambios en la estructura de datos, la lista de cambios de todos los componentes y los nuevos componentes se que usaron para el desarrollo de la entrega. Se debe tener muy claro las versiones para no crear confusin. Si hay actualizacin en la plataforma o componentes se debe entregar a produccin exactamente la misma versin que se us en desarrollo. 4.4 PRUEBAS Y ACEPTACIN

Se debe preparar un ambiente de pruebas lo ms similar al ambiente de produccin y que no sea el mismo que el ambiente de pruebas de desarrollo. Se ejecuta la actualizacin sugerida por el desarrollador y se pasa al usuario lder para sus pruebas. 4.4.1 Capacitacin de usuario lder Se capacita al usuario lder respecto al nuevo desarrollo. Esta capacitacin no se debe realizar en un lenguaje tcnico sino basado en la terminologa del proceso que se apoya. 4.4.2 Pruebas de usuario El usuario lder realiza las pruebas de cada funcionalidad de acuerdo con el formulario definido en la lista de funcionalidades. Las pruebas deben ser concienzudas y exactas, no hacer suposiciones y por ningn motivo debe estar presente el desarrollador; la fase de pruebas y presentacin del software del desarrollador con el usuario se da en la capacitacin. Para las pruebas se debe tener en cuenta adems los requerimientos no funcionales. En tanto que se desarrolla las pruebas el desarrollador inicia el desarrollo de la prxima entrega. 4.4.3 Aceptacin De acuerdo con las pruebas, el usuario lder determina la aceptacin del paso a produccin del programa con las nuevas funcionalidades. La no aceptacin implica un requerimiento de correccin al desarrollador y la realizacin de nuevas pruebas. 4.5 IMPLANTACIN Adecuacin de la plataforma, paso a produccin del programa y capacitacin de usuarios. 4.5.1 Capacitacin de usuarios La capacitacin al usuario final se debe realizar con anticipacin al paso a produccin para que los usuarios conozcan los cambios y se preparen ante las novedades. 4.5.2 Paso a produccin El paso a produccin implica la adecuacin y actualizacin de la plataforma y la distribucin y/o instalacin del programa. Es recomendable realizar los respaldos necesarios que permitan regresar a la versin anterior ante cualquier imprevisto.

Avisar con anticipacin a los usuarios indicando la fecha y hora de la actualizacin y los cambios que tendr la nueva versin. 4.6 POST-IMPLANTACIN Y MANTENIMIENTO El sistema ya desarrollado pasa a produccin donde su utilidad crea dependencia y apoyo a los procesos de la compaa, por lo tanto las sub-actividades post-implantacin hacen parte del funcionamiento del sistema. 4.6.1 Copias de respaldo Se debe planear y ejecutar las actividades que lleven a respaldar la informacin y los componentes del sistema. Su frecuencia de los respaldos de determina de acuerdo con el uso del sistema, la cantidad de informacin, la arquitectura y dems parmetros propios de cada sistema. 4.6.2 Actualizacin de componentes Esta sub-actividad trata sobre todo de los componentes que interactan con el programa pero que no son parte del desarrollo. Componentes como: controladores, drivers, actualizaciones del sistema operativo, service pack de aplicaciones, actualizaciones del motor bases de datos, etc, deben ser actualizados con precaucin. Siempre se debe realizar la actualizacin primero en un ambiente similar al de produccin y verificar que todo funcione correctamente. 4.6.3 Cambios en la informacin Muchas veces los sistemas no tienen la funcionalidad que permita realizar algunas tareas y es preciso realizar cambios como: agregar, eliminar o alterar registros, crear, mover, renombrar o eliminar archivos, modificar la configuracin o parametrizacin de un programa, etc. Estos cambios deben realizarse mediante un procedimiento formalmente establecido y respaldado. Cuando un tipo de solicitud de cambio es muy comn, se debe solicitar la mejora al sistema para que provea dicha funcionalidad. 4.6.4 Soporte tcnico Tarea permanente que atiende tanto sucesos previstos como imprevistos que deben ser atendidos inmediatamente para que el sistema funcione correctamente. Los sucesos previstos se deben comunicar a los usuarios con anterioridad. Casos previstos que pueden alterar el sistema son: mantenimientos de equipos,

mantenimientos de sistemas elctricos de la compaa, instalacin de software, actualizacin de aplicaciones, instalacin de service pack, actualizacin de antivirus, etc. Cuando los usuarios saben que algn imprevisto puede ocurrir, no se alarmarn cuando ocurra, y la operacin del sistema volver a su cause normal cuando se indique la solucin. Los sucesos imprevistos deben comunicarse inmediatamente ocurran. Cuando los usuarios no conocen las causas de los problemas crean alarma y se confunden, adems congestionan el rea de soporte reportando el evento. 4.7 MEJORAS Todo sistema, como todo proceso, es dinmico y por ende es normal que los programas requieran de perfeccionamiento o ajustes. 4.7.1 Gestin de mejoras Las mejoras o cambios que requiera el programa deben ser solicitados como una nueva funcionalidad y se debe realiza todo el recorrido desde el anlisis de requerimientos hasta el paso a produccin. 4.7.2 Gestin de errores Los errores deben estar bien documentados y deben ser reportados con prontitud. Es importante la gestionar la solucin de los errores: solicitar el arreglo, preguntar permanentemente por el estado de la solucin, realizar pruebas cuando se disponga de la solucin, etc. GLOSARIO Desarrollador Programador, codificador. Persona que se encargar de implementar el diseo de un programa. Desarrollo de Software Son los pasos que se siguen para plasmar en un programa las necesidades de un usuario. Implantacin Paso a produccin de un programa o parte del mismo. Implementacin Programacin. Codificacin de cada una de los elementos de un programa. LICENCIA El licenciamiento de MDS 360 permite que cualquier persona, copie, distribuya, venda o modifique este documento siempre que mantenga el reconocimiento del autor. MDS 360 por Wilson Arguello es licenciado bajo Creative Commons Reconocimiento 3.0 Unported License para fuera de Colombia.

MDS 360 por Wilson Arguello es licenciado bajo Creative Commons Reconocimiento 2.5 Colombia License para Colombia.