desarrollo de un proyecto de software

1. Una vez finalizado el desarrollo significativo: Mantenimiento

1.1. Es probable que surjan nuevas normas a medida que nuevas tecnologías y las necesidades de los usuarios cambian. El sitio equipo de desarrollo de software debe completar cada etapa del ciclo de vida del desarrollo de software para abordar el nuevo cambio para cumplir con estas normas.

1.2. En general, se refiere al hecho de que los programas informáticos requieren actualizaciones periódicas, que deben gestionarse para que su propuesta de valor siga siendo válida.

2. Mantenimiento correctivo

2.1. El término "mantenimiento correctivo" se refiere a la eliminación de fallos del software para mejorar su rendimiento. Los comentarios de los usuarios son el método más común para detectar estos problemas.

2.1.1. Mantenimiento perfectivo

2.1.1.1. Constantemente se desarrollan y modifican nuevos requisitos. El programa debe actualizarse para adaptarse a estos cambios y seguir siendo competitivo y vital. Ésa es la lógica que subyace en el mantenimiento perfectivo.

3. Modelo de ciclo de vida de desarrollo de software

3.1. Un modelo de ciclo de vida del software es una representación gráfica del proceso de desarrollo del software. Los modelos y actividades del ciclo de vida del software (SDLC) son los mismos para todos los modelos, aunque el enfoque sea diferente.

4. Modelo en cascada

4.1. El modelo de cascada es el primer enfoque aplicado en el SDLC. También se le conoce como el modelo secuencial lineal. En este enfoque, el resultado de una fase sirve de entrada para la siguiente. La siguiente fase sólo se planifica cuando se ha completado la actual.

4.2. El primer paso es reunir y analizar los requisitos. Una vez congelados los requisitos, comienza el desarrollo del diseño del sistema. El documento SRS producido es el resultado de la fase de requisitos y sirve como entrada para el diseño del sistema en este método.

4.3. 2. Los documentos que guían la siguiente fase, como la arquitectura y el diseño, se generan en la implementación y codificación del software de diseño del sistema.

4.4. En la etapa de implementación, se completa la codificación y el software creado es la entrada para la siguiente fase, la de pruebas.

4.5. El código desarrollado se comprueba a fondo en la fase de pruebas para encontrar cualquier error en el software. Los defectos se registran en el sistema de seguimiento de defectos y se vuelven a probar una vez solucionados. Las pruebas de regresión, la invalidación de las pruebas y la notificación de los errores continúan hasta que el software está en estado de funcionamiento.

4.6. El código terminado se presenta al cliente para que lo apruebe en la fase de despliegue, tras lo cual se pone en producción.

4.7. Los desarrolladores que entran en mantenimiento son responsables de cualquier problema en el entorno de producción.

5. Modelo en forma de V

5.1. El modelo en forma de V también se conoce como modelo de verificación y validación. La verificación y la validación están estrechamente vinculadas; el desarrollo y las pruebas se realizan en paralelo. El modelo en forma de V y el modelo en cascada son idénticos, salvo que la planificación y ejecución de las pruebas del modelo en forma de V comienzan antes.

6. Modelo prototipo

6.1. El modelo prototipo es aquel en el que el prototipo se crea antes que el software final. Los modelos prototipo tienen menos capacidades funcionales y un rendimiento inferior al del software. Los prototipos se crean utilizando maniquíes. Se trata de una herramienta eficaz para comprender las demandas de los clientes. Se crean prototipos antes del software definitivo para obtener la opinión crítica de los clientes. Se obtienen los comentarios del cliente, y el prototipo vuelve a ser revisado por el consumidor para realizar cualquier modificación. El procedimiento continúa entonces hasta que el cliente lo acepta.

6.2. Una vez completado el análisis de necesidades, se realiza un diseño rápido y se proporciona al cliente el prototipo para su evaluación. Los comentarios del cliente y el perfeccionamiento de los requisitos se utilizan para modificar el prototipo y, a continuación, se presenta al cliente para que lo revise.

6.3. Una vez aprobado el prototipo, se convierte en una especificación para crear el software real. El producto de software primario se desarrolla con una metodología en cascada.

7. Modelo ágil

7.1. En las metodologías ágiles, un producto se divide en pequeños incrementos sucesivos. Los modelos iterativo e incremental se combinan para formar el enfoque ágil. Se trata de un enfoque flexible para el desarrollo de productos que hace hincapié en la flexibilidad más que en la necesidad.

7.2. La siguiente iteración se basa en la tecnología previamente implementada. No se crea como un proyecto completo de una sola vez. En términos de capacidades, cada versión mejora. En desarrollo ágilLas iteraciones se conocen como sprints. El propietario del producto valida el producto al final de cada sprint y, tras su aprobación, se envía al cliente. Cada sprint dura entre dos y cuatro semanas. Los comentarios de los clientes se tienen en cuenta y sus ideas y mejoras se abordan en el siguiente sprint. Cada sprint se somete a pruebas para reducir el peligro de cualquier error.

8. Conclusión: Cómo el enfoque SDLC mejora su proyecto de desarrollo de software

8.1. El proceso de desarrollo de software debe producir un producto de alta calidad que satisfaga las demandas de los usuarios. El enfoque del SDLC puede ayudarle a evitar fallos, retrasos o dificultades en el proceso de desarrollo, independientemente de lo grande o pequeño que sea el proyecto. Esta es una guía paso a paso que le ayudará a poner en práctica su idea de producto.

8.2. El SDLC comprende cinco pasos del desarrollo de softwareDesde la planificación y la recopilación de requisitos, pasando por el diseño, el desarrollo, las pruebas y la garantía de calidad, hasta la publicación y el mantenimiento. Cada etapa del SDL persigue un objetivo final que sirve de trampolín para futuras acciones. Considere las fases del SDLC como una búsqueda interminable para mejorar su producto y hacerlo más fuerte que la competencia o incluso superarlo.

8.3. El concepto general del SDLC es proporcionar un procedimiento estándar para un equipo de desarrollo de software. Sin embargo, el enfoque de desarrollo de software elegido determina cómo un equipo de desarrollo aborda estas fases. Los esfuerzos de desarrollo tienen más probabilidades de fracasar si no hay un camino bien definido y un sentido de la dirección.

9. Planificación y recopilación de requisitos. El cliente describe un problema que hay que resolver, lo que sirve de base para completar el resto de requisitos del software

9.1. Diseñar

9.1.1. Esta es la segunda etapa del ciclo de vida del desarrollo de software, que implica el desarrollo de la arquitectura, los prototipos y el diseño de la experiencia del usuario. He aquí un rápido resumen de lo que implica esta etapa:

9.1.2. Arquitectura de software: Se refiere al proceso de establecer una cadena ordenada de elementos en un programa de software para el control de calidad, la legibilidad y la accesibilidad. Se puede pensar en la arquitectura del software como el plano del equipo de desarrollo.

9.1.3. Prototipo: El equipo de interfaz de usuario/experiencia de usuario (UI/UX) del software crea una edición prototipo del programa para verificar su aspecto y el flujo de los elementos de diseño del software. Permite al equipo y a las partes interesadas imaginarse el aspecto visual del software.

10. Desarrollar

10.1. La siguiente etapa es la fase de codificación, en la que los desarrolladores de software trabajan para hacer realidad su idea. Los desarrolladores de software escriben KLOC (miles de líneas de código) en lenguajes de programación con los que están familiarizados. El objetivo del equipo de desarrollo es aumentar la velocidad de los desarrolladores manteniendo una alta calidad.

11. Pruebas y garantía de calidad

11.1. Esta etapa del proceso de desarrollo de aplicaciones se ocupa de validar el código escrito en busca de fallos y otras anomalías. Es entonces cuando se realizan las pruebas y equipo de control de calidad colabora para verificar y notificar errores al equipo.

11.2. El equipo de pruebas puede utilizar métodos prácticos o pruebas automatizadas (en función de sus habilidades y del procedimiento establecido). En este caso, los probadores y el equipo trabajan juntos para garantizar una entrega de software sin problemas.

12. Despliegue

12.1. Después de crear el software, probarlo, modificarlo, volverlo a probar y certificarlo en condiciones de producción, pasa a desplegarse en el entorno de producción. Si se utiliza el Enfoque ágil del SDLCEl desarrollo y el despliegue pueden referirse a la introducción del MVP y otras características.

12.2. Sin embargo, cuando se trata de Waterfall, el despliegue se refiere a la introducción de un producto totalmente operativo en el mercado. Si los usuarios encuentran un problema con el programa, éste vuelve al equipo de software para que lo reconsidere y lo repare.

13. Modelo en espiral

13.1. La técnica iterativa y el prototipo están incluidos en el Modelo Espiral. Las etapas del modelo en espiral se utilizan en cada iteración. El modelo contiene bucles para indicar las fases del proceso del SDLC. El bucle más interno es para la recopilación y el análisis de los requisitos después de la planificación, el análisis de riesgos, el desarrollo y la evaluación en el proceso del SDLC. En los bucles posteriores, la estrategia consiste en diseñar y, a continuación, implementar y probar.

14. Modelo iterativo e incremental

14.1. El modelo iterativo e incremental divide el producto en piezas manejables. En las iteraciones, no es necesario hacer mucha planificación. Por ejemplo, se determina la característica implementada en esta iteración y se pone en marcha. Las fases de cada iteración incluyen el análisis de requisitos, el diseño, la codificación y las pruebas.

15. Modelo del Big Bang

15.1. En el modelo Big Bang no hay un procedimiento definido. El dinero y el esfuerzo se combinan como entradas, mientras que la solución surge como un producto terminado, que puede no ser lo que el cliente necesita. El modelo no requiere mucha preparación ni programación. El desarrollador analiza los requisitos y codifica el producto basándose en sus conocimientos. Sólo se realizan proyectos pequeños con este método. No hay un equipo de pruebas y no se realizan pruebas significativas, lo que puede contribuir al fracaso del proyecto.

16. ¿Por qué es importante el ciclo de vida del desarrollo de software?

16.1. ¿Por qué debería utilizar el ciclo de vida de desarrollo de software estándar? El SDLC es un marco de trabajo para el seguimiento y la medición del progreso en sus proyectos de desarrollo de software. Así es como añade valor a sus esfuerzos de desarrollo de software:

16.2. Tiempo de comercialización más rápido - El tiempo que se tarda en completar el proyecto y volver a las operaciones normales se reduce significativamente

16.3. Software de alta calidad - Los procesos se realizan normalmente en un orden sincrónico, lo que permite que haya pocos errores y anomalías

16.4. Facilita el control de la gestión - El modelo de ciclo de desarrollo de software proporciona a la gestión del proyecto un control que les ayuda a ver y seguir el progreso del desarrollo, independientemente de lo grande o pequeño que sea el proyecto

16.5. Coordina las actividades del equipo: como todos los miembros del equipo comprenden las fases del ciclo de vida del desarrollo de software, saben qué anticipar y cómo prepararse para lo que viene.

16.6. Rompe las barreras entre los equipos - Las fases del SDLC establecen una comunicación mutua entre los equipos de desarrollo al vincularlos con un procedimiento que requiere cooperación.

16.7. Una mejor visión de las responsabilidades y tareas - Cada fase del ciclo de desarrollo de software tiene un propósito claro. Como resultado, los equipos son conscientes de sus responsabilidades en el ciclo de vida del desarrollo de software.