BUENAS PRÁCTICAS PARA EL DESARROLLO DE SOFTWARE
Juan David Giraldo Giraldo Andres Eduardo Lopez Ramirez Andres Mauricio Sabogal Borrello
UNIVERSIDAD DEL QUINDÍO FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN ARMENIA 2013
TABLA DE CONTENIDO
Buena Prรกctica Extreme Programming (XP) Open Unified Process (OpenUP) Rational Unified Process (RUP) Buenas Prรกcticas de Desarrollo de Software Integraciรณn Continua Small Releases Pair Programming Refactoring Test Driven Development Develop Software Iteratively Use Component Architectures Verify Software Quality Control Changes to software Visually Model Software Risk-Value Lifecycle Release Planning Concurrent Testing Evolutionary Architecture Evolutionary Design Production Release Documentation and Training Justificaciรณn Resumen Corto de Hoja de Vida Sitios Web de Referencia Usos de Google Drive Referencias Bibliogrรกficas
Descripción del Tema En el presente trabajo se hará referencia a las buenas prácticas propuestas por tres metodologías de desarrollo de software que son muy utilizadas en la actualidad: Extreme Programming, Open Unifed Process y Rational Unified Process. A continuación se presenta la definición de Buena Práctica, y una pequeña contextualización de cada una de las metodologías mencionadas anteriormente.
Buena Práctica: Una buena práctica es un método bien definido que contribuye al éxito de una determinada actividad dentro del proceso de desarrollo de software, y que ha sido probada a través de la experiencia e investigación [1].
Extreme Programming (XP) XP es un método de desarrollo ágil de software, optimizado para equipos pequeños y medianos. Este método promueve la rápida retroalimentación y la adaptación al cambio continuo. Está basado en la simplicidad, comunicación, retroalimentación y valor [2].
Figura 1: Proceso de desarrollo planteado por Extreme Programming [3].
Open Unified Process (OpenUP) El Open Unified Process en proceso ligero que aplica un enfoque iterativo e incremental dentro de un ciclo de vida estructurado. Está enmarcado en la filosofía ágil, enfocándose en el desarrollo de software colaborativo. Es un proceso de baja formalidad, independiente de herramientas y puede ser utilizado en gran variedad de proyectos [4].
Figura 2: Proceso de desarrollo planteado por OpenUP [4].
Rational Unified Process (RUP) IBM Rational Unified Process es un framework de procesos que provee prácticas para la implementación de software y de sistemas, y una efectiva gestión de proyectos. El RUP promueve el desarrollo iterativo y organiza el ciclo de vida en cuatro fases, compuestas por una o varias iteraciones [5].
Buenas Prácticas de Desarrollo de Software Las buenas prácticas son un conjunto de prácticas definidas por un proceso o una metodología para obtener mejores resultados cuando se desarrolla software. A continuación se hace una recopilación de buenas prácticas definidas por procesos y metodologías, que abarcan las etapas de requisitos, análisis, diseño, implementación, pruebas y despliegue.
Integración Continua La integración continua es una práctica de desarrollo de software que les permite a los miembros de un equipo integrar su trabajo, comúnmente mínimo una vez al día. Cada integración es
verificada por pruebas automatizadas que permiten detectar errores de integración. Este enfoque reduce los problemas que se pueden presentar a la hora de la integración [6].
Small Releases Lanzar versiones del software de forma continua permite que haya una retroalimentación. La interacción constante del usuario con el software permite encontrar errores. Obtener retroalimentación de forma temprana mejora la calidad del producto. Se recomienda ciclos de lanzamiento de tres a cuatro meses [7].
Pair Programming El código es producido por dos programadores sentados en el mismo computador. Esta práctica asegura que el código es revisado por al menos otro programador y da como resultado mejor diseño, mejores pruebas y mejor código [7].
Refactoring Práctica para el mejoramiento del diseño de un sistema sin cambiar su comportamiento. La idea es que una vez terminada una funcionalidad o pieza de código, sea revisada con el fin de mejorar la calidad del código. Esta técnica permite a los programadores mantener un buen diseño o mejorar el diseño de un sistema existente [7].
Test Driven Development Las pruebas no se hacen al final cuando se tiene todo el código construido. La idea es escribir pruebas que especifiquen una pequeña parte de una funcionalidad y posteriormente escribir el código necesario para pasar la prueba. Reduce el tiempo necesario para hacer integraciones, aumenta la productividad a la hora de corregir errores y aumenta la calidad del software [7].
Develop Software Iteratively El ciclo de vida del proyecto esta compuesto de varias iteraciones, en la cual se realizan una serie de actividades de modelado de negocio, requisitos, análisis y diseño, implementación, pruebas y despliegue, dependiendo del estado actual del proyecto. El principal beneficio es la mitigación temprana de los riesgos [8].
Use Component Architectures Una arquitectura de componentes es aquella que está basada en el uso de componentes reemplazables e independientes, que ayudan a reducir la complejidad y permiten la reutilización
[8].
Verify Software Quality Es importante evaluar la calidad de los artefactos producidos a lo largo del ciclo de vida. A medida que el software es producido, debe ser sujeto a diferentes pruebas en escenarios importantes para proveer un entendimiento del diseño y eliminar defectos a nivel de arquitectura de forma temprana [8].
Control Changes to software Mantener una relación de trazabilidad entre los elementos de las múltiples versiones del software, para evaluar y gestionar el impacto de los cambios que se realizan. Esto permite descubrir de forma activa posibles problemas que se puedan presentar [8].
Visually Model Software Un modelo es una vista simplificada que muestra las partes esenciales de un sistema desde un determinado punto de vista. Permite alcanzar niveles de abstracción y provee comunicación para el equipo encargado de realizar el diseño. Además elimina la ambigüedad a la hora de realizar la implementación [8].
Risk-Value Lifecycle El ciclo de vida esta dividido en cuatro fases: Inicio, Elaboración, Construcción y Transición. Esto permite que se puedan definir hitos para cada fase, con el fin de evaluar si los objetivos se están cumpliendo de manera adecuada. Direccionar las metas y los riesgos en cada fase le da la oportunidad al equipo de encontrar un balance entre reducción de riesgos y la creación de valor [9].
Release Planning Comprende una planeación de alto nivel para el alcance total del proyecto, y una planeación de bajo nivel para las próximas iteraciones. Mejora la precisión de la planeación, la predicción de los recursos necesarios y el cumplimiento de las fechas establecidas [9].
Concurrent Testing Su objetivo es realizar pruebas a lo largo de una iteración. Esto evita que las pruebas se hagan al
final de cada iteración. Requiere alto grado de integración y buena comunicación entre desarrolladores y testers. Las pruebas se hacen a nivel de componentes, funcionalidades y subsistemas [9].
Evolutionary Architecture Describe cómo se construye y se mejora la arquitectura del software de forma incremental, a medida que se descubren problemas de arquitectura durante el desarrollo. La prioridad es mitigar riesgos técnicos [9].
Evolutionary Design El diseño se formula de forma incremental a medida que se implementa el software. En cada revisión que se le hace al diseño, se hacen cambios, se refina y se refactoriza la solución [9].
Production Release Debido al gran impacto que puede causar el lanzamiento del producto al negocio, se debe asegurar que la aplicación está preparada de forma apropiada para ser lanzada a producción sin ninguna consecuencia. Es necesario preparar una versión base y verificar que la integración con el ambiente de producción sea exitosa [9].
Documentation and Training Se deben documentar aspectos fundamentales del producto y se debe proveer material de entrenamiento para las personas que van a usar dicho producto. La documentación es importante para los stakeholders, las personas que vayan a hacer uso de las características del sistema, y para las personas que lo van a mantener disponible y en funcionamiento [9].
Justificación En el ámbito del desarrollo de software se han definido una serie de prácticas que son utilizadas en las diferentes etapas de los procesos, con el fin de obtener buenos resultados en las actividades que se llevan a cabo. En la actualidad muchas empresas que se dedican a la fabricación de software no siguen buenas prácticas en el proceso de desarrollo. En consecuencia se tienen procesos de baja calidad, lo que impacta de forma directa a las aplicaciones y a la organización. Es por esto que en el presente trabajo se estudian referentes de ingeniería y desarrollo de software para extraer las buenas prácticas que estos plantean.
Resumen Corto de Hoja de Vida
Sitios Web de Referencia
● Martin Fowler http://martinfowler.com/En este sitio web se puede encontrar información sobre metodologías ágiles, diseño de software y otros temas relacionados con la ingeniería de software. ● Microsoft Security Development Lifecycle http://www.microsoft.com/security/sdl/default.aspx En este sitio web se puede encontrar información sobre el ciclo de vida de seguridad propuesto por Microsoft. El objetivo de este ciclo de vida es introducir prácticas para el aseguramiento de la seguridad en el proceso de desarrollo de software. ● OpenSAMM http://www.opensamm.org/ En este sitio web se puede encontrar información sobre el OpenSAMM. Este es un modelo de madurez, que propone una serie de prácticas que se deben aplicar en las etapas del proceso de desarrollo de software, con el fin de construir aplicaciones segura. ● OWASP https://www.owasp.org/index.php/Main_Page Este sitio web corresponde a una comunidad libre y abierta sobre seguridad en aplicaciones.Aquí se pueden encontrar documentos, herramientas, guías, listas de chequeo y otros materiales que pueden ayudar a las organizaciones a mejorar su capacidad de producir código seguro.
Usos de Google Drive Andres Mauricio Sabogal Borrello ●
Es una herramienta que sirve para gestionar documentos y artefactos relacionados
con el proceso de desarrollo de software, de tal forma que todos los integrantes del equipo de desarrollo puedan acceder a esta información en cualquier momento. Ayuda a que el proceso de desarrollo sea transparente. ●
Puede ayudar en la sincronización de equipos de trabajo distribuidos, ya que permite compartir archivos y trabajar sobre ellos de forma colaborativa en tiempo real.
Andres Eduardo Lopez Ramirez ●
Google Drive es una herramienta que permite la elaboración, modificación, anexos, visualización, y envío de
documentos de manera colaborativa; Además estos
documentos son almacenados en la nube independientemente si tiene permisos para las funciones nombradas anteriormente. ●
Eficiente para elaboración de los documentos en proyectos equipos de trabajo, envío, recepción y modificación de los mismos.
Juan David Giraldo Giraldo ● Drive es una herramienta que nos sirve para almacenar información de diferentes partes con tan solo tener internet sin necesidad de cargar esta información en una memoria usb, además de la disponibilidad de nuestros datos nos permite la creacion y manipulacion de diversos tipos de documentos por una sola persona o en forma colectiva. ● Es una herramienta de muy fácil acceso, ya que para acceder a ella tan solo basta con tener una cuenta gmail.
Referencias Bibliográficas [1]. Margaret Rouse. Best Practice. Sitio Web. Fecha de actualización: Febrero 2007. Disponibilidad y acceso: http://searchsoftwarequality.techtarget.com/definition/best-practice. [2]. Extreme Programming. Sitio Web. Disponibilidad y acceso: http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php.
[3]. Extreme Programming. Sitio Web. Disponibilidad y acceso: http://www.extremeprogramming.org/map/project.html [4]. OpenUp. Sitio Web. Disponibilidad y acceso: http://epf.eclipse.org/wikis/openup/ [5]. IBM Rational Unified Process (RUP): Proven best practices for software and systems delivery. Sitio Web. Disponibilidad y acceso: http://www-01.ibm.com/software/rational/rup/ [6]. Martin Fowler. Continuous Integration.ArtĂculo. 1 Mayo 2006. Disponibilidad y acceso: http://martinfowler.com/articles/continuousIntegration.html [7]. Extreme Programming. Sitio Web. Disponibilidad y acceso: http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.php [8]. Rational Unified Process: Best Practices for Software Development Teams. ArtĂculo. Noviembre 2001. Disponibilidad y acceso: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpracti ces_TP026B.pdf [9]. OpenUp. Sitio Web. Disponibilidad y acceso: http://epf.eclipse.org/wikis/openup/ Se utilizaron normas ICONTEC para la portada.