Proceso para el Desarrollo de Software
En Ingeniería del Software, un modelo de proceso de desarrollo de software puede verse como una manera de dividir el trabajo en distintas actividades (o el ciclo de vida del producto en distintas fases) con la intención de lograr la mejor gestión y el mejor resultado para el proyecto. Estos modelos pueden incluir la definición previa de entregables específicos y otros artefactos que son creados y completados por el equipo para diseñar, codificar, probar y mantener el software en cuestión.
¿Que queremos decir con proceso de desarrollo de Software?
El Proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral.
Fases para el Proceso de Desarrollo del Software
- Análisis de requisitos: Extraer los requisitos de un producto de software es la primera etapa para crearlo. se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software. La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines
- Diseño y arquitectura: Se refiere a determinar como funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.
- Programación: Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no es necesariamente la porción más larga. La complejidad y la duración de esta etapa está intimamente ligada al o a los lenguajes de programación utilizados.
-
Pruebas: Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral,para así llegar al objetivo. Se considera una buena practica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un area de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un area de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en que condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.
- Documentación: Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
- Mantenimiento: Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.
Pruebas: Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral,para así llegar al objetivo. Se considera una buena practica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un area de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un area de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en que condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.
Modelos de Desarrollo de Software
Los modelos de desarrollo de software son una representación abstracta de una manera en particular. Realmente no representa cómo se debe desarrollar el software, sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado. Existen tres paradigmas de los modelos de desarrollo de software:
- Paradigma Tradicional: Es uno de los paradigmas más antiguo, se inventó durante la creación del método estructurado. Si se elige un proyecto, el método varia en etapas.2 Como todo modelo, existen sus pros y contras al usar este paradigma:
Si se aplica este paradigma, unos de los principales problemas , es que las etapas realizadas no son autónomas de las siguientes, creando una dependencia estructural y en el acaso de un error atrasaría todo el proyecto. Se tiene que tener pautas bien definidas, y que no se incurra a modificación porque implicaría en que el software no cumpla con su ciclo de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia.
2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programación orientada a objetos; por lo tanto, se refiere al concepto de clase, el análisis de requisitos y el diseño. El modelo o paradigma orientado a objetos posee dos características principales, las cuales son:
* Permite la re-utilización de software.
*Facilita el desarrollo de herramientas informáticas de apoyo al desarrollo, el cual es simple al implementarla en una notación orientado a objetos llamado UML
3. Paradigma de Desarrollo Ágil: Es un paradigma de las Metodologías De Desarrollo basado en procesos ágiles. Estos intentan evitar los tediosos caminos de las metodologías tradicionales enfocándose en las personas y los resultados. Usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incorporando los cambios continuamente.
- Modelo en cascada: El modelo en cascada es un enfoque secuencial de desarrollo en el cual el trabajo fluye de manera secuencial ("como una cascada") a través de las distintas fases:
- Modelo de espiral: La principal característica del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala. La espiral se visualiza como un proceso que pasa a través de algunas interaciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
*Especificación de requisitos
*Diseño de software
*Implementación
*Pruebas
*Integración
*Despliegue
*Mantenimiento
El modelo en cascada es un enfoque, casi utópico, de la Ingeniería tradicional aplicado a la Ingenieria de Software. Un modelo en cascada estricto desaprueba la revisión y repetición de etapas anterior una vez estas se han completado. Sin embargo existe un enfoque más flexible (realista) que permite realizar arreglos y cambios en etapas ya completadas e incluso solapar actividades de fases consecutivas para evitar la rigidez del flujo de trabajo.
- crear planes con el propósito de identificar los objetivos del software, seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
- Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
- la implementación del proyecto: implementación del desarrollo del software y su pertinente verificación.
Desarrollo mediante prototipos
Este es un enfoque del desarrollo de software que se basa en la creación de prototipos (software con funcionalidad parcial, incompleta). Se suele usar como parte de otros modelos de proceso más tradicionales.
Los principios básicos son:
* Reducir los riesgos inherentes del proyecto estableciendo el desarrollo en fragmentos mas pequeños y logrando, en un entorno propenso a cambios, que estos tengan menor impacto.
* El usuario involucrado durante el desarrollo (probando prototipos) incrementa la aceptación de la implementación del producto final.
* Pequeños prototipos con modificaciones son mostrados al cliente y sirve para confirmar que se han comprendido sus requisitos.
Desarrollo iterativo e incremental
El desarrollo iterativo recomienda la construcción de secciones reducidas de software que irán ganando en tamaño para facilitar así la detección de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes que no saben cómo definir lo que quieren
Codificación y corrección
El desarrollo de codificación y corrección (en inglés "Code and fix") es, más que una estrategia predeterminada, el resultado de una falta de experiencia o presión que se ejerce sobre los desarrolladores para cumplir con una fecha de entrega.7 Sin dedicar tiempo de forma explícita para el diseño, los programadores comienzan de forma inmediata a producir código. Antes o después comienza la fase de pruebas de software (a menudo de forma tardía) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software.
Video informativo sobre los Modelos de Desarrollo de Software
