Procesos de software

PROCESOS 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.  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.(Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)




Objetivos:

 ºEntender qué es el proceso de desarrollo de software
 º Cuáles son los componentes que debe considerar un proceso de desarrollo de software
 º Modelos de proceso de desarrollo de software
 º Calidad del proceso de desarrollo de software

Actividades para el desarrollo de software

Planificación

Es importante a la hora de elaborar un producto de software tener los requisitos o el análisis de los requisitos. Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo.  (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

Implementación, pruebas y documentación

La implementacion es donde los ingenieros de software programan el código que esta relacionado con las demandas, es en esta etapa donde se realizan las pruebas de caja blanca y caja negra.
Las pruebas, en esta etapa es donde se detectan los errores lo mas antes posibles.
La documentacion, del diseño interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Prácticamente es como un con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto.  (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

Despliegue y mantenimiento

El despliegue  comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción.
El mantenimiento o mejora del software, Esto quiere decir que cuando un software se encuentra con problemas pude requerir mas tiempo que cuando lo elaboramos inicialmente, es posible que se cambie el código del diseño actual del proyecto con el fin de solucionar el problema y así haya una mejor funcionalidad. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

Modelos de Desarrollo de Software

Los modelos de desarrollo del software son una representación abstracta de una manera en particular, representa un enfoque común, que puede ser modificado o adaptado de acuerdo a las necesidades del cliente. Existen tres paradigmas:
1. Paradigma tradicional:
Es uno de los paradigmas más antiguo, se inventó durante la creación del método estructurado.y unas de las ventajas de este paradigma es el mayor control en cuanto ala programación, y al tener este control se reducen el riesgo de exceso de los gastos. Y las desventajas es que el usuario no participa en el proceso, no se hace de forma secuencial y si el usuario olvida aclarar pautas esto es un sobrecostos en el proyecto. también esta claro que en este proceso se deben tener las pautas bien definidas porque la modificación de estas atrasaría todo el ciclo de vida del proyecto. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)
2. Paradigma orientado a objetos: 

 Este paradigma se refiere al concepto de clase, el análisis de requisitos y el diseño. y tiene las siguientes características:
  • 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. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)
3. Paradigma de desarrollo ágil:


Es un paradigma de las Metodologías del desarrollo basado en procesos ágiles. Estos se enfocan 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 de cascada

El modelo en cascadas es el que define las siguientes etapas:

*Especificación de requisitos
*diseño del software
*implementacion del software
*integracion
*pruebas
*despliegue
*mantenimiento

Hay que tener en cuenta que cuando finaliza una fase y sigue la otra hay que tomar las medidas necesarias y chequear los errores antes de que se inicie la otra fase. En este modelo no es aconsejable revisar o modificar las fases que ya se hayan completado. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

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 bohenm, 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 interacciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
  1. 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.
  2. Análisis de riesgos:  para evaluar como identificar y eliminar el riesgo.
  3. la implementación del proyecto y su pertinente verificación.
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
  1. El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.
  2. Si la implementación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo.
  3. Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último, se evalúan los resultados y se inicia el diseño de la siguiente fase. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

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. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

Desarrollo ágil

El desarrollo ágil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista más ligero y más centrado en las personas que en el caso de las soluciones tradicionales. Los procesos ágiles utilizan retroalimentación en lugar de planificación, como principal mecanismo de control. La retroalimentación se canaliza por medio de pruebas periódicas y frecuentes versiones del software. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)
Hay muchas variantes de los procesos ágiles:
  • En el caso de la programación extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un día o en una semana, en lugar de los meses o años de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Después se programa el código, que será completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabrían como mejorar el conjunto de pruebas necesario. El diseño y la arquitectura emergen a partir de la refactorzacion del código, y se da después de programar. El diseño lo realizan los propios desarrolladores del código. El sistema, incompleto, pero funcional se despliega para su demostración a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de más importancia. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

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.​ Sin dedicar tiempo de forma explícita para el diseño, los programadores comienzan de forma inmediata a producir codigo. Antes o después comienza la fase de pruebas  y los  errores que se encuentran han de eliminarse antes de poder entregar el software.

Orientado a la Reutilización

La reutilización de software es un proceso donde se recurre al uso de activos de software en las especificaciones de análisis, diseños, implementación y pruebas de una aplicación o sistemas de software.

La reutilización tiene ciertos Indicadores por ejemplo:
1. Entre el 40% y 60% de una aplicación es re-utilizable en otra.
2. Aproximadamente el 0% de una aplicación administrativa es re-utilizable.
3. Aproximadamente el 75% de las funciones son comunes a más de un programa.
4. Solo el 15% del código encontrado en muchos sistemas es único y novedoso a una aplicación especifica.
El rango general de uso recurrente esta entre el 15% y 85%. (Revertidos los cambios de 181.233.197.20 (disc.) a la última edición de CEM-bot)

Conclusión:
Los procesos que se llevan a cabo en el proceso de desarrollo de un software como tal son esas etapas que se llevan en cuenta y de hacer paso a paso cada una de ellas para llevar consigo mismo un buen producto y como también tener en cuenta las pautas que se llevan a cabo durante el respectivo procedimiento.


Información del LINK: https://es.wikipedia.org/wiki/Proceso_para_el_desarrollo_de_software



Comentarios

Entradas populares de este blog

Matriz de Planificacion

Enfoque sistemico para desarrollo agil