Estándares en el proceso de desarrollo de software

Estándares en el proceso de desarrollo de software

Para promover un nivel mayor en el área de ingeniería de software tenemos un conjunto de reglas que ya han usado otros como normas a seguir para que la programación sea mas fácil y eficiente para todos.

El estándar internacional que regula el método de selección, implementación ymonitoreo del ciclo de vida del software es ISO 12207.Durante décadas se ha perseguido la meta de encontrar procesos reproducibles ypredecibles que mejoren la productividad y la calidad. Algunas de estas solucionesintentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software.

 Otros aplican técnicas de gestión de proyectos para la creación del software.Sin una gestión del proyecto, los proyectos de software corren el riesgo de demorarse oconsumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos desoftware que no cumplen sus metas en términos de funcionalidad, costes o tiempo deentrega, una gestión de proyectos efectiva es algo que a menudo falta. Planificación.

La importante tarea a la hora de crear un producto de software es obtener losrequisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bienabstracta del resultado final, pero no sobre las funciones que debería cumplir elsoftware. 

Una vez que se hayan recopilado los requisitos del cliente, se debe realizar unanálisis del ámbito del desarrollo. Este documento se conoce como especificaciónfuncional.Implementación, pruebas y documentación.La implementación es parte del proceso en el que los ingenieros de software programanel código para el proyecto.

Las pruebas de software son parte esencial del proceso de desarrollo del software. Estaparte del proceso tiene la función de detectar los errores de software lo antes posible.La documentación del diseño interno del software con el objetivo de facilitar su mejora ysu mantenimiento se realiza a lo largo del proyecto. Esto puede incluir ladocumentación de un API, tanto interior como exterior.

Despliegue y mantenimiento.

El despliegue comienza cuando el código ha sido suficientemente probado, ha sidoaprobado para su liberación y ha sido distribuido en el entorno de producción.Entrenamiento y soporte para el software es de suma importancia y algo que muchosdesarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen alcambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.

El mantenimiento y mejora del software de un software con problemas recientementedesplegado puede requerir más tiempo que el desarrollo inicial del software. Es posibleque haya que incorporar código que no se ajusta al diseño original con el objetivo desolucionar un problema o ampliar la funcionalidad para un cliente. Si los costes demantenimiento son muy elevados puede que sea oportuno rediseñar el sistema parapoder contener los costes de mantenimiento.


Codificar y corregir.


Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
  • Escribir código.
  • Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento.
Este modelo tiene tres problemas principales:

  • Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.

  • Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario,  por lo que es rechazado o su reconstrucción es muy cara.

El código es difícil de reparar por su pobre preparación para probar y modificar.

Modelo en cascada.

El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso.

Desarrollo evolutivo.

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada interacción.

Existen dos tipos de desarrollo evolutivo:
  • Desarrollo Exploratorio:
  • Enfoque utilizando prototipos


Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:
  •  Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.
  •   Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.
  •  Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión.
Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

Desarrollo formal de sistemas.

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.  Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son:

 la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado.

 el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).
Observaciones sobre el desarrollo formal de sistemas:
  •  Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.

  •   Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.

  •  Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

Desarrollo basado en reutilización.

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase:
1.  Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
2.  Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).
3.  Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.
4.  Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.
Ventajas de este modelo:
  • Disminuye el costo y esfuerzo de desarrollo.
  • Reduce el tiempo de entrega.
  •   Disminuye los riesgos durante el desarrollo.

Desventajas de este modelo:
  •  Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.
  • Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.

Procesos iterativos:

A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:
  •    Desarrollo Incremental.
  • Desarrollo en Espiral.
Desarrollo incremental.

Sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema Es una combinación del Modelo de Cascada y Modelo Evolutivo.Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

    Desarrollo en espiral.

    El modelo de desarrollo en espiral. Es actualmente uno de los más conocidos y fue propuesto por Boehm .El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra.

    METODOLOGÍAS PARA DESARROLLO DE SOFTWARE. 

    Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.).

    Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc.

    Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.


    Rapid Application Development (RAD).

    El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo interativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.

    0 comentarios

    Tambahkan Komentar Anda