Metodología de Desarrollo de Software

Las más utilizadas son: La Programación Extrema (XP), Scrum y el Proceso Unificado de Software (RUP).

¿Qué es una metodología de desarrollo de software?

Una metodología de desarrollo de software no es mas que una serie de pasos que se realizan de forma rigurosa tal que su resultado a partir de unos requisitos nuevos o modificados sea un software nuevo o modificado. Se puede ver como una caja negra, como muestra la siguiente imagen:

Metodología: 

Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.

Técnica:

Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o varias.

Herramienta:

Para realizar una técnica, podemos apoyarnos en las herramientas software que automatizan su aplicación.

 Metodologías tradicionales y metodologías ágiles

Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales o Pesadas. 

Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.

Entre las metodologías tradicionales o pesadas podemos citar:

• RUP (Rational Unified Procces)

• MSF (Microsoft Solution Framework)

• Win-Win Spiral Model

• Iconix

Pero sin dudas adaptarse a la agitada sociedad actual implica ser “ágil”, es decir, tener la capacidad de proveer respuestas rápidas y ser adaptables al cambio. Ambas cualidades siempre han sido deseables, pero en el entorno de negocio actual resultan indispensables. Este requerimiento de agilidad en las empresas, gobiernos y cualquier otra organización provoca que el software también deba ser desarrollado de manera ágil.

Las necesidades de un cliente pueden sufrir cambios importantes del momento de contratación de un software al momento de su entrega; y es mucho más importante satisfacer estas últimas que las primeras. Esto requiere procesos de software diferentes que en lugar de rechazar los cambios sean capaces de incorporarlos.

Los procesos ágiles son una buena elección cuando se trabaja con requisitos desconocidos o variables. Si no existen requisitos estables, no existe una gran posibilidad de tener un diseño estable y de seguir un proceso totalmente planificado, que no vaya a variar ni en tiempo ni en dinero. En estas situaciones, un proceso adaptativo será mucho más efectivo que un proceso predictivo. Por otra parte, los procesos de desarrollo adaptativos también facilitan la generación rápida de prototipos y de versiones previos a la entrega final, lo cual agradará al cliente.

Las metodologías ágiles proporcionan una serie de pautas y principios junto a técnicas pragmáticas que puede que no curen todos los males pero harán la entrega del proyecto menos complicada y más satisfactoria tanto para los clientes como para los equipos de entrega. En la figura 1 se muestran los principios que rigen el desarrollo ágil.

 Principios del Manifiesto Ágil

Entre las metodologías ágiles más destacadas hasta el momento se pueden nombrar:

• XP (Extreme Programming)

• Scrum

• Crystal Clear

• DSDM (Dynamic Systems Developmemt Method)

• FDD (Feature Driven Development)

• ASD (Adaptive Software Development)

• XBreed

• Extreme Modeling

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (RUP)

Está dirigido por Casos de Usos:  Los casos de uso reflejan lo que los usuarios futuros necesitan y desean. A partir de aquí los casos de uso guían el proceso de desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo).

Centrado en la arquitectura:  La arquitectura muestra la visión común del sistema completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo, se describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que facilitan comprenderlo, desarrollarlo y producirlo económicamente.

Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software, plantea la implementación del proyecto a realizar en Iteraciones (iteración por iteración), con lo cual se tienen varias ventajas; tener pequeños avances del proyectos que son entregables al cliente el cual puede probar mientras se está desarrollando otra iteración del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad.

PROGRAMACIÓN EXTREMA O XP (EXTREME PROGRAMMING)

La Programación Extrema surge ideada por Kent Beck, como proceso de creación de software diferente al convencional. En palabras de Beck: “XP es una metodología ligera, eficiente, con bajo riesgo, flexible, predecible y divertida para desarrollar software”. 

3P 

Paradigma 3P es una metodología de desarrollo de software nacida al calor de la experiencia acumulada del grupo de investigación y desarrollo Atis, debido a la insuficiente capacidad de respuesta a los clientes utilizando las metodologías tradicionales. 

Resumen puntos clave :

RUP 

Pesado 

Dividido en cuatro fases, que se dividen en iteraciones 

Los artefactos son el objetivo de cada actividad 

Se basa en roles 

UML 

Muy organizativo 

Mucha documentación 

XP 

Ligero 

Cercano al desarrollo 

Se basa en UserStories 

Fuerte comunicación con el cliente 

El código fuente pertenece a todos 

Programación por parejas 

Solo el mínimo de organización 

Pobre en cuanto a documentación

3P 

Ágil 

Cercano al desarrollo, pero sin olvidar el diseño 

Se basa en 3 principios: Personal, Problema, Proceso 

Gran interacción con el cliente 

Logra alcanzar un control y organización del proceso 

Logra un equilibrio en cuanto a la generación de documentación

Scrum

Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa. Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.

¿Cuándo se utiliza?
Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema.

Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades. 

REFERENCIAS:

Alianza Ágil. Disponible en: http://www.agilealliance.org

Alistair Desarrollo de Software Ágil. Disponible en: http://www.amazon.com/exec/ obidos/ASIN/0201699699/programacione-20.

https://pid.dsic.upv.es/C1/Material/Documentos%20Disponibles/Introducci%C3%B3n%20Proceso %20de%20Desarrollo%20de%20SW.doc

www.softeng.es › ... › Empresa › Metodologías de trabajo

DOCUMENTACIÓN DURANTE EL DESARROLLO DEL SOFTWARE

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.



Dos estrategias de desarrollo: Ciclo de vida Estructurado y Orientación a Objetos.

Documentación y Desarrollo de Software

En general se habla mucho de la documentación, pero no se la hace, no se le asigna presupuesto, no se la mantiene y casi nunca está al día en los proyectos de desarrollo de software.

Lo importante es la disponibilidad de la documentación que se necesita en el momento en que se la necesita. 

Muchas veces se hace porque hay que hacerla y se escribe, con pocas ganas, largos textos, a la vez que se está convencido de estar haciendo un trabajo inútil. A veces se peca por exceso y otras por defecto. Ocurre mucho en la Web y con productos RAD. En ocasiones se olvida que el mantenimiento también debe llegar a la documentación.

La documentación se suele clasificar en función de las personas o grupos a los cuales está dirigida:

· Documentación para los desarrolladores

· Documentación para los usuarios

· Documentación para los administradores o soporte técnico

La documentación para desarrolladores es aquélla que se utiliza para el propio desarrollo del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas. Obviamente, cuanto más complejo es el sistema, más importante es la documentación.

En este sentido, todas las fases de un desarrollo deben documentarse: requerimientos, análisis, diseño, programación, pruebas, etc.. Una herramienta muy útil en este sentido es una notación estándar de modelado, de modo que mediante ciertos diagramas se puedan comunicar ideas entre grupos de trabajo.

Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un caso particular es el de UML, que analizamos en otra obra. De todas maneras, los diagramas son muy útiles, pero siempre y cuando se mantengan actualizados, por lo que más vale calidad que cantidad. La documentación para desarrolladores a menudo es llamada modelo, pues es una simplificación de la realidad para comprender mejor el sistema como un todo. Otro aspecto a tener en cuenta cuando se documenta o modela, es el del nivel de detalle.

Así como cuando construimos planos de un edificio podemos hacer planos generales, de arquitectura, de instalaciones y demás, también al documentar el software debemos cuidar el nivel de detalle y hacer diagramas diferentes en función del usuario de la documentación, concentrándonos en un aspecto a la vez.

De toda la documentación para los desarrolladores, nos interesa especialmente en esta obra aquella que se utiliza para documentar la programación, y en particular hemos analizado la que se usa para documentar desarrollos orientados a objetos en el capítulo respectivo. La documentación para usuarios es todo aquello que necesita el usuario para la instalación, aprendizaje y uso del producto. Puede consistir en guías de instalación

       - usuario
       - manuales de referencia
       - guías de mensajes

En el caso de los usuarios que son programadores, verbigracia los clientes de nuestras clases, esta documentación se debe acompañar con ejemplos de uso recomendados o de muestra y una reseña de efectos no evidentes de las bibliotecas.

Más allá de todo esto, debemos tener en cuenta que la estadística demuestra que los usuarios no leen los manuales a menos que nos les quede otra opción. Las razones pueden ser varias, pero un análisis de la realidad muestra que se recurre a los manuales solamente cuando se produce un error o se desconoce cómo lograr algo muy puntual, y recién cuando la ayuda en línea no satisface las necesidades del usuario. Por lo tanto, si bien es cierto que debemos realizar manuales, la existencia de un buen manual nunca nos libera de hacer un producto amigable para el usuario, que incluso contenga ayuda en línea. Es incluso deseable proveer un software tutorial que guíe al usuario en el uso del sistema, con apoyo multimedial, y que puede llegar a ser un curso online.

Buena parte de la documentación para los usuarios puede empezar a generarse desde que comienza el estudio de requisitos del sistema. Esto está bastante en consonancia con las ideas de extreme programming y con metodologías basadas en casos de uso.

La documentación para administradores o soporte técnico, a veces llamada manual de operaciones, contiene toda la información sobre el sistema terminado que no hace al uso por un usuario final. Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación. Como esto no es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad y demás nunca se puede descartar, en general el manual de operaciones es un documento que va engrosándose con el tiempo.


- Diagrama de contexto:

- Glosario:

Es una descripción de términos que hacen al negocio, cuya comprensión es necesaria por parte 

de diseñadores y programadores, y tiene la forma de un diccionario, poniendo los términos y sus significados. Esto a veces no es necesario, ya sea porque los términos son lo suficientemente corrientes o porque ya hubieran sido explicados en otros documentos.

- Diagrama de Gantt del proyecto: (en el proyect)

Debe hacerse el plan de trabajo del proyecto en forma de Diagrama de Gantt o similar, que luego 

se irá actualizando al final de cada etapa.

- Modelo de comportamiento:

Define el comportamiento del sistema para manejarse con éxito en el ambiente. 

Ese comportamiento se establece tomando como unidad cada una de los estímulos de la Lista de Eventos ya comentada.

- Diagrama de Entidad – Relación

Describe la distribución de datos en un sistema. Es fundamental en sistemas centrados en datos. No es necesario si el sistema tiene poco o ningún acceso a bases de datos, como algunos sitios web.

- Modelo del procesador:

Es lo que permite pasar del modelo de análisis a los distintos componentes de hardware, con sus comunicaciones. Habrá que incluir un diagrama de hardware, en el cual se muestre el hardware sobre el que se implementará el sistema, y una justificación de la elección del entorno tecnológico, en la cual se explican las consideraciones que se hicieron para elegir dicho hardware.

- Modelo de implantación de programas

Organización jerárquica de módulos en una tarea. Se realiza con un Diagrama estructurado.A continuación hay un diagrama estructurado de ejemplo:

- Diagrama de Flujo de Datos (DFD):

Es un diagrama que muestra los procesos y los flujos de datos entre los mismos. Se lo llama también diagrama de burbujas. Es fundamental cuando las funciones o procesos son más importantes que los datos.

- Interfaces de usuario

Se especifican con prototipos de las interfaces de usuario y reportes. Éstas pueden consistir en dibujos o bocetos que muestren cómo van a ser las interfaces, aun cuando luego estos sean modificados luego.

- Esquema de la Base de Datos

A continuación se muestra uno:

CALIDAD DEL DESARROLLO DEL SOFTWARE

Es el grado en que un software cumple con los requisitos especificados, (eficiencia, flexibilidad, corrección, mantenimiento, seguridad e integridad.

Factores que determinan la Calidad el Software :

• Corrección. ¿Hace lo que quiero?
• Fiabilidad. ¿Lo hace de forma fiable todo el tiempo?
• Eficiencia. ¿Se ejecutará en mi hardware lo mejor que pueda?
• Seguridad (Integridad). ¿Es seguro?
• Facilidad de uso. ¿Está diseñado para ser usado?

MODELOS DE CALIDAD DE SOFTWARE

Algunos modelos para la gestión de la calidad del software:

CMMI: Integración de modelos de madurez de capacidades o Capability maturity model integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

Norma ISO/IEC 12007: Diseñada por la International Organization for Standardization Orientado al proceso del ciclo de vida del software.

Metrica3: Diseñada por el Ministerio de Administración Pública de España para la planificación, desarrollo y mantenimiento de sistemas informáticos para la gestión de actividades del ciclo de vida de los proyectos software dentro de las administraciones publicas.

ISO 15504: Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software Integración de modelos de madurez de capacidades o Capability maturity model integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

La ISO 9000: 2000 contiene las definiciones de los términos que se utilizan en las otras dos normas. Es decir que si alguien necesita conocer qué se entiende por "sistema de gestión de la calidad", "no conformidad", "producto", por ejemplo, debe referirse a esta norma.

La ISO 9001:2000 es la norma que contiene los requisitos que debe cumplir una organización para la implementación de un SGC(Sistema de Garantía de Calidad).

ISO 12207

Esta norma esta orientada a los procesos de ciclo de vida del software de la organización ISO. Establece un proceso de ciclo de vida para el software que incluye procesos y actividades que se aplican desde la definición de requisitos, pasando por la adquisición y configuración de los servicios del sistema, hasta la finalización de su uso.

ISO (La Organización Internacional para la Estandarización). 

Es la agencia especializada en estandarización, con el objeto de promover la estandarización internacional, de tal manera que se facilitara el intercambio internacional de bienes y servicios casi como el desarrollo científico y tecnológico.

¿Cuáles son los beneficios 

de Normas Internacionales

 ISO?

Normas Internacionales ISO garantizar que los productos y servicios sean seguros, fiables y de buena calidad. Para las empresas, que son herramientas estratégicas que reducen los costos al minimizar los residuos y los errores y aumentar la productividad. Ellos ayudan a las empresas a acceder a nuevos mercados, nivelar el campo de juego para los países en desarrollo y facilitar el comercio global libre y justo.

Norma iso 9000-3:  Tienen como objetivo proveer las especificaciones de cómo aplicar la ISO 9001 al desarrollo del software, implementación y mantenimiento.

BENEFICIOS:

      - Mejor documentación de los sistemas. Cambio cultural positivo.

      - Incremento en la eficiencia y productividad. Mayor percepción de calidad.

      - Se amplía la satisfacción del cliente.

      - Se reducen las auditorias de calidad de los clientes.

      - Agiliza el tiempo de desarrollo de un sistema.

REFERENCIAS BIBLIOGRAFICAS:

http://modelosdegestiondelacalidad.blogspot.com/