Modelos de desarrollo
Desarrollo por etapas
La ingeniería del software es el proceso formal de desarrollo de software en el que las necesidades del usuario se traducen en requerimientos, estos se transforman en diseño que se implementa en código que se prueba, documenta y se certifica para su uso operativo. Según la definición del IEEE la ingeniería del software se define como “la aplicación de un método sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, esto es, la aplicación de la ingeniería al software”.
Esta consiste en etapas principales: 1. Análisis de requerimientos: En esta etapa se obtiene toda la información necesaria para llevar acabo el software por ejemplo: información de la empresa, que tipo de software será, a quienes va dirigido, porque se necesita entre otras cosas mas quizá lo más importante de esta etapa es que requisitos debe cumplir el software para ser de calidad (cumpla con las expectativas). 2. Especificación: En esta etapa se elabora un plan de gestión y se detalla profundamente el software. Algunas de las cosas que se generan en este punto son: Documento de Especificación de requisitos, documento de Aseguramiento de la calidad, Métricas de software, casos de uso, etc. 3. Diseño y arquitectura: Determinar cómo funcionara de forma general sin entrar en detalles incorporando consideraciones de implementación tecnológica, como el hardware la red, etc. Suele ir muy entre lazada con la etapa anterior inclusive a veces se toma como una sola etapa ya que una podría depender de la otra. 4. Programación: En esta parte se obtiene la primera parte “tangible” del proyecto, sin embargo no necesariamente es la parte más difícil o que más tiempo debe llevar, ya que si de etapas anteriores no se logra correctamente la documentación previa, es muy probable que en esta etapa se dificulten las operaciones y se termine gastando muchos recursos en corregirlos. 5. Pruebas: Consiste en comprobar que el software responda correctamente a las especificaciones indicadas previamente, en algunas otras metodologías de desarrollo como la basada en prototipos se suele hacer en varias ocasiones. 6. Documentación: En términos generales se crea un manual técnico y un manual de usuario, además de estos entregables se suele anexar documentos creados en otras etapas (previamente ordenados). 7. Mantenimiento: En esta etapa se realizan principalmente un mantenimiento correctivo y se intenta agregar algunas funciones extras al software.
Desarrollo Estructurado
El desarrollo estructurado comenzó con la programación, sin embargo fue a mediados de los años 70, empezaron a surgir las técnicas estructuradas, se empezó a construir programas de una forma artesanal con métodos de ingeniería. El desarrollo estructurado permitio facilitar la comprensión de programas, nomas para la aplicación de estructuras de datos y de control. En el diseño estructurado se caracteriza lo siguiente: * Mayor nivel de abstracción(independencia del lenguaje de programacion). * Elemento básico de diseño: modulo. * Modularidad que permite medir la calidad de los programas. * Representa los procesos, flujos y estructura de datos, de una manera jerarquica y descendente. * Ven el sistema como entradas-procesos-salidas. * Se concentran en la parte del proceso * Se lee en porciones, independiente de las especificaciones.
Aunque en este se permita tener buen proceso y estructura de un programa, tiene inconveniente como: * Leer todas las especificaciones para entender el problema * Se repetía la misma información en partes diferentes del documento. * El enfoque de requisitos se interpretaba diferente por cada usuario. * Cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas.

Desarrollo Orientado a Objetos
El desarrollo orientado a objetos (OO) trata los procesos y datos de forma conjunta. Este comienza en los años 80 con los lenguajes OO en los que se daba énfasis a la abstracción de datos para los que se adjuntaba un conjunto de operaciones, Por otra parte los conceptos de técnicas estructuradas han servido de base para muchas de las metodologías OO.
La orientación a objetos empieza con los lenguajes OO; en estos lenguajes los problemas del mundo real se representan como un conjunto de objetos para los que se adjuntan un conjunto de operaciones. Ej. C++, Java, etc.
En la metodología OO el sistema se organiza una colección de objetos que interactúan entre si y que contiene tanto estructuras de datos como un comportamiento:
Los principios del modelo OO se enlistan a continuación * Abstracción * Encapsulación * Modularidad * Jerarquía o Herencia * Tipificación * Concurrencia * Persistencia
“Si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es Orientado a Objetos” (Booch, 1998).
RAD
El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo iterativo 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.

Principios básicos:

* Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión. * Intenta reducir los riesgos inherentes del proyecto partiéndolo en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo. * Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promueve la participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos. * Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia es de menor importancia. * Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite. * En general incluye Joint application development (JAD), donde los usuarios están intensamente participando en el diseño del sistema, ya sea a través de la creación de consenso estructurado en talleres, o por vía electrónica. * La participación activa de los usuarios es imprescindible. * Iterativamente realiza la producción de software, en lugar de enfocarse en un prototipo. * Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento (CMS, 2008).
Desarrollo Concurrente
El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente, permite que un equipo de software represente elementos iterativos y concurrentes de cualquiera de los modelo. Por ejemplo, la actividad de modelado definida para el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de software: hacer prototipos, análisis y diseño.
La actividad (modelado) puede estar en algún estado, en un momento dado. En forma similar, es posible representar de manera análoga otras actividades, acciones o tareas (por ejemplo, comunicación o construcción). Todas las actividades de ingeniería de software existen de manera concurrente, pero se hallan en diferentes estados.
Por ejemplo, la actividad de comunicación termina su primera iteración al principio de un proyecto y existe en el estado de cambios en espera. La actividad de modelado (que existía en estado inactivo mientras concluía la comunicación inicial, ahora hace una transición al estado en desarrollo. Sin embargo, si el cliente indica que deben hacerse cambios en los requerimientos, la actividad de modelado pasa del estado en desarrollo al de cambios en espera.
El modelado concurrente define una serie de eventos que desencadenan transiciones de un estado a otro para cada una de las actividades, acciones o tareas de la ingeniería de software.
Por ejemplo, durante las primeras etapas del diseño (acción importante de la ingeniería de software que ocurre durante la actividad de modelado), no se detecta una inconsistencia en el modelo de requerimientos. Esto genera el evento corrección del modelo de análisis, que disparará la acción de análisis de requerimientos del estado terminado al de cambios en espera.
El modelado concurrente es aplicable a todos los tipos de desarrollo de software y proporciona un panorama apropiado del estado actual del proyecto. En lugar de confinar las actividades, acciones y tareas de la ingeniería de software a una secuencia de eventos, define una red del proceso. Cada actividad, acción o tarea de la red existe simultáneamente con otras actividades, acciones o tareas. Los eventos generados en cierto punto de la red del proceso desencadenan transiciones entre los estados (Pressman, 2010).
Problemas al no usar modelos (Ejemplos)
Therac-25: un diseño de interacción mortal
Normalmente hablamos de diseño de interacción relativo a interfaces de servicios web o de herramientas de productividad, donde los errores se traducen en pérdida de tiempo, impaciencia del usuario y, a veces, derroche de dinero. Pero el diseño de interacción es crítico cuando un error de concepto puede matar a una persona.
Es el caso de las aplicaciones y maquinarias médicas. En 1982 salió al mercado médico una máquina llamada Therac-25 que proporcionaba tratamiento tanto de radiación como de rayos X, según fuese necesario. Costaba cerca de un millón de dólares. La mayoría de las veces, el Therac-25 se comportó bien y administró correctamente el tratamiento a las pacientes con cáncer. Pero en 6 ocasiones, algo falló. El enfermero u operario de turno cometió un error al inicio del tratamiento, accionó los mecanismos de corrección del software de la máquina y rectificó el rumbo. En teoría, porque a pesar de que la interfaz indicaba que todo iba bien, en realidad los pacientes estaban recibiendo hasta 125 veces más radiación que lo normal.
3 de esos pacientes murieron. El problema fue que los desarrolladores cometieron dos errores fundamentales: no pudieron prever el error humano y se negaron a hacer pruebas antes de comercializar el aparato. Como el sistema estaba concebido por programadores, que conocían perfectamente el funcionamiento y nunca se les ocurrió pensar en usuarios que podían equivocarse, pensaron que era infalible. Y como no se trataba de un diseño centrado en el usuario, no hicieron los test de usuarios de rigor.
En resumen: nadie se preocupó de diseñar un sistema de recuperación en errores de operación. Nadie previó rutinas de fallos. Nadie quizo hacer test con usuarios. Tres personas perdieron la vida por ello y otros tres quedaron gravemente afectados.
El caso del Therac-25 puede sonar demasiado fatalista, pero es un excelente ejemplo de la importancia de diseñar sistemas de interacción pensando en el usuario y hacer las pruebas necesarias (MUÑOZ).
Bibliografía
Booch, G. (1998). Software Architecture and the UML.
CMS. (27 de Marzo de 2008). SELECTING A DEVELOPMENT APPROACH. Centers for medicare.
Pressman, R. (2010). Ingenieria De Software un enfoque Practico. McGRAW-HILL.