Modelos Para El Desarrollo De Proyectos De Software
Enviado por davidesd7 • 24 de Noviembre de 2013 • 2.048 Palabras (9 Páginas) • 393 Visitas
Modelos para el desarrollo de proyectos de software
Un modelo para el desarrollo de proyectos de software es el que describe las fases o pasos principales, y nos ayuda a administrar el progreso del desarrollo del software, además que sirve para elegir el mejor modelo que exista para entonces poder desarrollarlo.
A continuación te presentamos algunos de los modelos más importantes para el desarrollo de software.
a) Modelo de cascada
Este modelo es un proceso secuenciado por etapas que permite el desarrollo de software. Es el más utilizado, conocido y recomendado por la mayoría de los desarrolladores de software. Es de fácil utilidad -en ciertas circunstancias-, pues se puede realizar y aplicar en un periodo breve de tiempo, además de su funcionalidad para proyectos que no requieren estar en contacto continuo con el cliente, es decir, los requisitos se plantean desde un inicio y no se pueden modificar una vez iniciado el proyecto, así como para proyectos que no sean muy complejos. Para este modelo es necesario terminar cada una de las etapas, pues es seriado, de lo contrario sería imposible su realización. Una ventaja más de este modelo es que permite tener un registro de los avances.
Este modelo consta de:
• La ingeniería de requisitos o fase de requerimientos: son las necesidades que el cliente desea satisfacer a través del proyecto de software.
• Análisis: revisar que el proyecto de software esté cumpliendo los requerimientos.
• Diseño: estructuración y modelado de dichos requerimientos.
• Desarrollo: programación o codificación del modelo seleccionado.
• Pruebas: evaluación del proyecto de software.
• Implementación: mejora continua.
• Mantenimiento: servicio de revisión continua al software.
A continuación se presenta el gráfico de dicho modelo.
b) Modelo del espiral
Es un modelo pensado para proyectos de mediano plazo e intermedia complejidad, características que lo hace requerir de más tiempo para su realización.
Consta de cuatro cuadrantes: en cada uno de ellos existen las debidas fases para el desarrollo del software, y en las que se te solicita realices una actividad. Se inicia de adentro hacia fuera, siguiendo el sentido de las manecillas del reloj.
Principia estableciendo la comunicación con el cliente y la debida revisión de los requerimientos solicitados por el mismo. Se diseña el primer prototipo, el cual deberá adecuarse a lo indicado en los requerimientos. Se plantea al cliente y, por lo general, se reajusta según las observaciones. Posteriormente, se analizan los riesgos. Se culmina con las pruebas e implementación del servicio del sistema de software. De este modo, el ciclo se repite, pero en un nivel superior, donde se incrementa la complejidad.
Una de las ventajas de este modelo es que en cada prototipo se pueden agregar otros requerimientos o bien eliminarlos, con la finalidad de aumentar la eficiencia del servicio de software, como se observa en la siguiente figura.
c) Modelo incremental
Este modelo es quizá muy parecido al modelo de cascada: consta de cuatro etapas, y cada etapa de cuatro fases, las cuales son:
• Análisis
• Diseño
• Código
• Pruebas
Estas fases se entregan de manera parcial al cumplir con las cuatro etapas de cada fase. En este modelo -al igual que los anteriores- se inicia con un análisis de requerimientos. Posteriormente se diseña el sistema, de manera similar al de un prototipo del modelo de espiral. En la tercera fase se realiza la programación y generación del código. Y por último, se llevan a cabo las pruebas para verificar si cumple con los requerimientos que se establecieron desde el principio. Concluida esta primera etapa, el producto de la prueba es sometido a las mismas fases, pero en una segunda etapa. Este ciclo continúa hasta terminar la cuarta etapa.
Todo esto con la finalidad de atender a las necesidades y requerimientos del cliente. Por tanto, puedes apreciar que se requiere un poco más de tiempo y trabajo. Observa la siguiente figura:
2.2 Manejo de riesgos
Es la prevención de situaciones no deseadas, las cuales pueden presentarse durante el desarrollo de un proyecto de software, y para lo cual se lleva un registro en un documento llamado “Plan de manejo de riesgos”.
Por ejemplo: la deserción de un miembro del equipo por cuestiones laborales o de salud.
Las categorías de riesgo las podemos clasificar de la siguiente forma:
Riesgos del proyecto:
Éstos afectan la calendarización y los recursos del proyecto. Un ejemplo podría ser la pérdida de un programador experimentado.
Riesgos del producto:
Estos afectan la calidad o el rendimiento del software que se está desarrollando. Un ejemplo puede ser: que la utilidad en una herramienta de programación o software que queramos emplear sea de menor calidad que el esperado.
Riesgos del negocio:
Estos afectan a la organización que desarrolla el proyecto de software, por ejemplo, que la competencia introduzca un nuevo producto al mercado es un riesgo para el negocio.
Por supuesto, estos tipos de riesgos no son exclusivos entre sí. Si un programador experto abandona el proyecto, esto es un riesgo para el proyecto (debido a que la entrega del sistema se puede retrasar), para el producto (debido a que un nuevo programador no es un experto y puede cometer muchos errores), y para el negocio, pues se puede perder al cliente.
Observa que se te proporciona la manera de llenar los rubros:
a) Riesgos. Es una breve descripción de una situación, así como la fecha en que sucedió.
Este rubro abarca siete campos:
1. Número de riesgo: escrito con número.
2. La descripción del riesgo: enunciado que explica la situación.
3. Fecha: ubicación temporal en que ocurre el evento.
4. Posibles consecuencias: qué es lo que puede ocurrir cuando se presente el riesgo.
5. Posible riesgo (PR): la probabilidad que ocurra el riesgo en un porcentaje de 0.00 al 100%.
6. Impacto del riesgo (IMP): porcentaje de las consecuencias de los componentes, donde 100% implica rehacer todo. De este modo, (E) es el que se va ha obtener y nos indica el % del nivel de riesgo del proyecto de software.
Por lo tanto:
E = PR *IMP
7. Estrategia de contingencia.
Esta numeración es de acuerdo a la plantilla-plan manejo de riesgos de Excel.
Ejemplo:
b) Plan de contención
Consta de:
1. Estrategias: Define la manera en que se tratarán los riesgos para que no suceda o. si llegaran a suceder,
...