Custom services
Spanish (pdf)
Article in xml format
Article references
Send this article by e-mail
Cited by SciELO 
Similars in
SciELO 
Permalink
INTRODUCCIÓN
El desarrollo de software ha sido históricamente cuestionado debido a problemas asociados a sus resultados finales, entre los que se encuentran que: los sistemas no responden a las expectativas de los usuarios, los programas fallan con cierta frecuencia, los costos del software son difíciles de prever y normalmente superan las estimaciones, la modificación del software es una tarea difícil y costosa, entre muchas otras como que: el software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente. Solo una pequeña parte de los proyectos de software desarrollados terminan dentro de plazos y costos, y cumplen los requerimientos acordados (Pressman, 1993).
Estos inconvenientes dieron origen al concepto de “crisis del software” que prácticamente surgió conjuntamente con la creación del software. Es un término informático acuñado en 1968, en la primera conferencia organizada por la OTAN (Organización del Tratado del Atlántico Norte) sobre desarrollo de software, y residía en la complejidad de construir sistemas de software, y también en los cambios constantes a los que debía someterse el software para adaptarse a las necesidades cambiantes de los usuarios y a las innovaciones tecnológicas (Naul-Rander, y otros, 1968).
En esta conferencia se pretendía acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer se necesitaba “establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre máquinas reales” (Peter, y otros, 1968). Sin embargo, dicho planteamiento además debía incluir otros aspectos, tales como: la mejora de la calidad del software, satisfacción del cliente, mediciones y métricas. A partir de aquí empieza a usarse el término Ingeniería del Software, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software (Pons-Giandini, y otros, 2010).
Una parte importante de la ingeniería de software es el desarrollo de metodologías y modelos. En la actualidad ha habido muchos esfuerzos que se han encaminado al estudio de los métodos y técnicas para lograr una mejor aplicación de las metodologías y lograr sistemas más eficientes y de mayor calidad con la documentación necesaria en perfecto orden y en el tiempo requerido (Rumbaugh-Jacobson, y otros, 2000). La experiencia ha demostrado que los proyectos exitosos son aquellos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar el proyecto, considerando válido destacar que aquellos procesos que no sigan estos lineamientos corren un alto riesgo de fracasar (Pons-Giandini, y otros, 2010).
Existen diferentes modelos y metodologías que han sido utilizados en los últimos años como herramientas de apoyo para el desarrollo del software. Teniendo en cuanta los elementos anteriores surge como interrogante ¿cuál modelo utilizar en el proceso de desarrollo de software de un proyecto? Seguidamente se hace referencia a varios autores que analizan el tema, todos con el objetivo de proponer alternativas viables a la hora de seleccionar un modelo para el desarrollo de software teniendo en cuenta las características del proyecto.
MÉTODOS O METODOLOGÍA COMPUTACIONAL
Sommerville define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto, un modelo de procesos del software es una abstracción de un proceso real (Sommerville, 2005).
Los modelos genéricos no son descripciones definitivas de procesos de software; son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software (Pons-Giandini, y otros, 2010). Algunos de los modelos más conocidos son:
Prototipo.
Desarrollo basado en componentes (reutilización).
Desarrollo en espiral.
Modelo RAD (Rapid Application Development).
Modelo en cascada.
Prototipo
Su objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los mismos. Este modelo inicia con la recolección de requerimientos del cliente, con base en estos se define el conjunto de objetivos para el software, se identifican los requisitos conocidos y con base en estos se desarrolla rápidamente un prototipo o maqueta que posteriormente evalúa el cliente utilizándolo y ayudando a refinar de nuevo los requisitos del software a desarrollar; este proceso se seguirá repitiendo hasta que el cliente quede satisfecho con el desarrollo del software (Salazar-Aguirre, y otros, 2011). La Figura 1 muestra cómo se realiza el modelo de construcción de prototipos, iniciando en el momento en que los analistas del sistema.
Ventajas
Genera una buena comunicación con los clientes.
Recomendado para proyectos de pequeño y mediano alcance.
Desventajas
Las planificaciones pudieran sufrir cambios.
Dificultades para mantener el sistema en proyectos grandes y en la respuesta a cambios en los requisitos del usuario.
Períodos de desarrollo largos.
Desarrollo basado en componentes (reutilización)
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.
Alto costo, si la adaptación de nuevos paquetes es costosa.
Dificultades para asegurar el versionamiento si los suministradores de componentes no mejoran continuamente sus productos.
Desarrollo en espiral
El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue propuesto por Barry Boehm en 1986. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Es decir, surge de un sistema inicial que se desarrolla rápidamente a partir de especificaciones abstractas. En la Figura 2 se muestran las fases que propone el modelo Desarrollo en espiral.
Cada ciclo de desarrollo se divide en cuatro fases:
Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.
Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará depende del riesgo identificado para esa fase.
Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto (Boehm, 1988).
Este modelo, a diferencia de los otros, toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.
Variaciones del desarrollo en espiral
Desarrollo incremental: Se va creando el sistema añadiendo pequeñas funcionalidades. Cada uno de los pequeños incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. Bajo este modelo se entrega software por partes funcionales más pequeñas, pero reutilizables, llamadas incrementos. Cada incremento se construye sobre aquel que ya fue entregado.
Desarrollo iterativo: El sistema se desarrolla como una secuencia de pasos e iteraciones una vez establecida la arquitectura global. Los usuarios pueden experimentar con los productos resultantes de cada iteración, y usualmente el equipo de desarrollo puede continuar con el trabajo mientras que los usuarios experimentan con el sistema. Cada iteración refina lo realizado en la iteración anterior (Boehm, 1988).
Ventajas
Buena comunicación con los clientes a partir de que combina las ventajas de prototipo y cascada.
Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.
Recomendado para proyectos de gran alcance.
Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.
Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.
Desventajas
Cada incremento debe ser pequeño para limitar el riesgo y debe aumentar la funcionalidad.
Es difícil establecer las correspondencias de los requisitos contra los incrementos y detectar las unidades o servicios genéricos para todo el sistema.
Dificultades para mantener las planificaciones, y concebir y graficar el sistema globalmente.
Modelo RAD
Desarrollo Rápido de Aplicaciones (por sus siglas en inglés) es un modelo de proceso de desarrollo de software relativamente corto (dura entre 60 y 90 días). Se utiliza la construcción de software basada en componentes, utilizando herramientas de software que permitan de forma ágil y efectiva realizar una aplicación con altos estándares de calidad. La Figura 3 muestra las etapas del modelo RAD. El Modelo RAD comprende las siguientes etapas:
Modelado de gestión: Se genera la información que conduce el proceso de gestión, se identifica a dónde va la información y quién la procesa.
Modelado de datos: Se definen los almacenes de datos y cómo se relacionan los almacenes entre sí.
Modelado del proceso: Se utiliza para añadir, modificar, suprimir o recuperar un objeto de datos.
Generación de aplicaciones: Se utiliza una herramienta de cuarta generación que permite crear el software y facilitar la construcción del programa.
Pruebas y entrega: El proceso de desarrollo finaliza realizando pruebas de calidad del software diseñado con la herramienta RAD, posteriormente se realiza la implementación de la aplicación (Salazar-Aguirre, 2011).
Ventajas
Los usuarios pueden revisar el sistema sistemáticamente.
Los entregables pueden ser fácilmente trasladados a otra plataforma.
El desarrollo se realiza a un nivel de abstracción mayor.
Visibilidad temprana y mayor flexibilidad.
Menor codificación manual y mayor involucramiento de los usuarios.
Posiblemente menos fallas y menor costo
Ciclos de desarrollo más pequeños.
Desventajas
Para proyectos grandes, aunque por escalas, requiere recursos humanos suficientes como para crear el número correcto de equipos.
Requiere clientes y desarrolladores comprometidos en las rápidas actividades. Si no hay compromiso los proyectos fracasaran.
Costo de herramientas integradas y equipo necesario.
Progreso más difícil de medir.
Menos eficiente y menor precisión científica.
Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales.
Modelo en cascada
Este modelo toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. La interacción entre fases puede observarse en la Figura 4.
El modelo en cascada consta de las siguientes fases:
Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.
Diseño de software: Se particiona en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.
Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.
Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.
Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.
Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas (Royce, 1988).
Ventajas
Permite estimar calendarios y presupuestos con mayor precisión.
Facilita un nivel de satisfacción del cliente más elevado que otros enfoques.
Es fácil de manejar los planes de proyectos.
Alto nivel de seguridad y confiabilidad.
Desventajas
Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.
Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.
Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.
Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.
Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.
RESULTADOS Y DISCUSIÓN
¿Qué modelo de proceso de desarrollo de software utilizar?
Cada proyecto de software requiere una forma particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios. En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la selección de un modelo de proceso, la medida utilizada indica el nivel de efectividad del modelo de proceso de acuerdo al criterio (Laboratorio Ing. Soft, 2002).
Aunque estos criterios son válidos para seleccionar un modelo de desarrollo de software, es muy importante tener en cuenta las características del software y del equipo de proyecto. En la Tabla 2 se muestra una comparación teniendo en cuenta criterios más representativos que servirán de referencia en la toma de decisión para adoptar un modelo de desarrollo (Saurith, y otros, 2010).
CONCLUSIONES
El estudio de los modelos para el proceso de desarrollo del software contribuyó a determinar que los modelos son actividades que están relacionadas con la especificación del software (el análisis y diseño), el desarrollo (codificación), la elaboración de pruebas que evidencien la calidad del software y la implementación del producto en su entorno real.
La comparación entre los modelos de desarrollo de software permitió definir un nivel de efectividad teniendo en cuenta algunos criterios de selección. Esta comparación será muy útil cuando se desee seleccionar un modelo, considerando además las características del software y del equipo de proyecto.
