BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA

Transcripción

1 BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA Contenido Una metodología para el desarrollo de software debe ser un instrumento que permita gestionar un proceso dado, existen hoy en día diferentes metodologías las cuales no son en forma absoluta comparable, es decir, no existe en forma absoluta una metodología mejor a otra sino que la metodología debe estar alineadas a la cultura de la organización, tamaño y complejidad del proyecto, así como al ciclo de vida del producto que pretende desarrollar. En el presente documento se explica muy brevemente los aspectos que involucra el proceso de desarrollo de software y la metodología adoptada, a partir de un proyecto particular, ante determinadas condiciones y cultura de la organización. Contenido... 1 Introducción al desarrollo de Software... 2 Metodología para Proyectos de Desarrollo de Software... 3 Necesidades planteadas... 3 Metodología adoptada... 4 Ciclo de vida... 6 Características que posee la metodología... 7 Página 1 de 7

2 Introducción al desarrollo de Software Existen distintos tipos de software, desde software embebido en hardware, sistemas operativos, compiladores, etc. Sin querer generar una clasificación, el presente documento se enfoca en el desarrollo de software de aplicación. Consideremos como software de aplicación aquel que permite a los usuarios llevar a cabo una o varias tareas específicas, en cualquier campo de actividad susceptible de ser automatizado o asistido 1. Igualmente muchos principios y lineamientos aquí expuestos son aplicables a otros tipos de software. La construcción del software puede involucrar elementos de una gran complejidad, lo que en muchos casos no es tan evidente. Las potencialidades existentes en lo que respecta a las tecnologías de información y comunicación han potenciado que se puedan construir soluciones para atacar problemas cada vez más complejos. La complejidad inherente a cualquier desarrollo de software generalmente esta asociada a los siguientes aspectos: Complejidad del dominio del problema: cuando se va a desarrollar un software para un dominio específico se debe lograr entender el problema, conceptualizando el mismo y realizando las abstracciones necesarias. Dentro de esta actividad se debe poder obtener los requisitos para la construcción del software. La elicitación de estos requisitos genera un gran desafío; en general los mismos están en permanente competencia entre ellos y en muchos casos son opuestos. A su vez existe una dificultad en poder lograr que los usuarios de la futura aplicación puedan exponer en forma clara sus necesidades. Dinámica de las personas: Por otro lado existe una situación que es constante en cualquier proceso, el cambio. Ya sea por la dinámica de la problemática o la mejor comprensión por parte de las parte de la solución necesaria, el cambio es un elemento presente en cualquier proceso de desarrollo. Este genera nuevas necesidades que deben ser atendidas en una forma adecuada. Gestión de los equipos: al tratarse de problemáticas complejas es requerido poder coordinar el trabajo de los miembros del equipo del proyecto. Al aumentar la complejidad del proyecto se requiere en muchos casos de disponer de mayores recursos por lo que su gestión y coordinación es una problemática a atender. La complejidad tecnológica: la tecnología posee una dinámica no igualable en otras áreas de trabajo. El hecho de generar código, aplicar los mejores patrones de diseño, herramientas para la generación de código, utilizar tecnología actual pero testeada, son aspectos que deben ser considerados durante el proceso de desarrollo. A su vez hay un aspectos muy importante a considerar, 1 Página 2 de 7

3 estas tecnologías aplicadas deben estar alineadas a satisfacer las necesidades (requisitos) específicos del dominio. La dificultad propia del desarrollo de software, y su impacto en el negocio, han puesto de manifiesto las ventajas y en muchos casos la necesidad - de aplicar una metodología formal para llevar a cabo los proyectos de este tipo. El objetivo es convertir el desarrollo de software en un proceso formal, con resultados predecibles, que permitan obtener un producto final de alta calidad, que satisfaga las necesidades y expectativas del cliente. Atrás dejamos el modo de trabajar artesanal, que a menudo requiere de esfuerzos heroicos para llegar a buen puerto, con los consecuentes desfases de fechas y coste, y el más que probable desgaste personal del equipo de proyecto 2. El proceso formal para la construcción de un producto de software requiere llevar adelante las siguientes actividades: Análisis y especificación de los requisitos: Extraer los requisitos de un producto de software es la primera etapa para crearlo. Diseño y arquitectura de la solución: Se refiere a determinar como funcionará de forma general. Consiste en incorporar consideraciones de la implementación tecnológica. Programación: en base al diseño propuesto realizar la codificación para satisfacer los requisitos de la solución. Prueba: Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. En la actualidad existen numerosos estándares y metodologías en los cuales nos podemos basar y que explicitan las consideraciones a tener en su implementación. Independientemente del marco, modelo o estándar elegido como referencia, la implantación de una metodología de desarrollo de software en una organización plantea diversos retos. Metodología para Proyectos de Desarrollo de Software Necesidades planteadas Dada las características de los proyectos que se desarrollan donde los mismos son de innovación tecnológica en áreas donde el uso de las tecnologías de la información y las comunicaciones no son ampliamente utilizadas. Se requirió disponer de una metodología que permita: Adaptar el proceso: El proceso de construcción de la solución debía adaptarse a las características propias del proyecto y de la organización. El tamaño de cada proyecto, su tipo y las regulaciones que lo condicionen, influyen. 2 Página 3 de 7

4 Equilibrar prioridades: Los requerimientos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. La metodología debe permitir realizar una adecuada gestión de los requerimientos que permita encontrar un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán gestionar los desacuerdos que surjan en el futuro. Elevar el nivel de abstracción: Este principio motiva el uso de conceptos reutilizables. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requerimientos. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Generar entregas tempranas: la metodología debe contemplar la gestión de iteraciones. Las cuales una vez finalizada deben permitir evaluar la opinión de los interesados, la estabilidad y calidad del producto, y realizar los ajustes que se consideren necesarios en la dirección del proyecto así como también de los riesgos involucrados. Enfocarse en la calidad: El control de calidad debe estar presente en todos los aspectos de la producción del producto. El aseguramiento de la calidad debe ser parte del proceso de desarrollo y no de encontrase en forma independiente. Metodología adoptada En base a estas necesidades se evaluaron distintas alternativas optando por la utilización y adaptación del Proceso Unificado de Rational (Rational Unified Process RUP). Este es un proceso de desarrollo de software y que junto con el Lenguaje Unificado de Modelado UML, constituye una metodología estándar para el análisis, implementación y documentación de sistemas orientados a objetos. Esta metodología fue adaptada a las características de la organización y se realizan ajustes en base a las características específicas de cada proyecto. El conjunto de disciplinas básico utilizado contempla: Gestión de requerimientos: se definió un plan de gestión de requerimientos que contempla: o realización de reuniones y entrevistas (preliminares y específicas) que son documentadas, o confección de un documento de visión a partir del proyecto base, ajustando y precisando las necesidades de alto nivel en base a lo relevado en las reuniones preliminares. Se focaliza en las necesidades de los stakeholders y los usuarios finales y en porque esas necesidades existen. o Realizar el análisis detallado, profundizando en cada una de las características obteniendo los requerimientos funcionales y no funcionales que deben ser atendidos. Página 4 de 7

5 o Confeccionar un glosario: dada la necesidad de trabajar en forma interdisciplinaria en prácticamente todo los proyectos es de vital importancia confeccionar un glosario o diccionario que permita unificar el lenguaje a utilizar en la ejecución del proyecto. Este glosario se realiza con la técnica de Léxico extendido del Lenguaje. o Confección del diagrama de casos de uso y determinación de los casos de uso: a través del conocimiento de los requerimientos funcionales comenzar la construcción del diagrama de casos de uso, determinación de actores del sistema y definir los atributos necesario que permitan ser utilizados para estimar el esfuerzo para la construcción de la solución. Análisis: a partir del diagrama de caso de usos confeccionado se comienza el refinamiento y especificación de cada uno. Se ajustan y revisan los atributos para cada uno de los casos de uso. Se confeccionan el modelo de datos preliminar definiendo las entidades y sus atributos. Diseño Preliminar: se construyen bocetos de interfaces de usuarios por grupos de interfaz y se define la arquitectura del sistema. Diseño Detallado: Esta actividad se basa en el diseño detallado de las clases y componentes como así también sus relaciones y dependencias. En esta actividad se contempla la construcción del Modelo de Clases, Modelo de iteración, interfaces del sistema, transiciones de Estados, diagramas de actividad. Los modelos y artefactos a construir como así también el nivel de detalle dependen de cada uno de los proyectos. Diseño de casos de prueba: se confeccionan los casos de prueba en base a la estrategia de testeo definida para el proyecto. Implementación: construir la solución requerida para el proyecto. Ejecución de las pruebas: se ejecutan cada uno de los casos de prueba diseñados con el objetivo de lograr una ejecución ordenada y coherente a los objetivos del proyecto logrando un producto de acuerdo a las necesidades planteadas. Gestión de los cambios: esta disciplina esta muy relacionada con la gestión de requerimientos y el objetivo es permitir evaluar los cambios y defectos de manera que permita conocer cual es el impacto que tienen los mismos sobre el proyecto y derivar en una evaluación del costo del mismo, la cual permita planificarlo o descartarlo según sea el caso. Página 5 de 7

6 Ciclo de vida La metodología adaptada contempla las siguientes disciplinas y fases: Por cada una de las 4 fases se definen la cantidad de iteraciones en base a la particularidad del proyecto. Se suele utilizar una iteración en la fase de Inicio y de Elaboración, varias iteraciones de construcción y transición. En la Figura se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto. Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades relacionadas a los requerimientos. En la fase de elaboración, las iteraciones se orientan al desarrollo de la línea base de la arquitectura, abarcan más los flujos de trabajo de refinamiento de los requerimientos, análisis, diseño y una parte de implementación orientado a la línea base de la arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones. Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto. En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Página 6 de 7

7 Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía. Características que posee la metodología Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software A su vez la misma se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Página 7 de 7