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, disminuir el impacto que tendría en el desarrollo del software.

2. Responsable: Nombre de la persona responsable de aplicar la estrategia.

Ejemplo:

c) Plan de contingencia

Implica hacer un seguimiento del riesgo y un plan de acciones a realizar si ocurre el riesgo.

Ejemplo:

De esta forma, tu archivo de manejo de riesgos quedaría de la siguiente manera:

2.3 Viabilidad del proyecto

En cualquier parte del mundo y cualquier persona que pretenda iniciar un negocio, empresa o cualquier tipo de proyecto, debe cuestionar la viabilidad de éste, según el entorno y las circunstancias donde se desea ejecutar.

Algunas circunstancias a considerar, las puedes encontrar al contestar las siguientes preguntas:

Tu proyecto…

1. ¿Cubre una necesidad?2. ¿Tiene competencia en el mismo giro que pretendes incursionarlo?3. ¿Tiene bien detectado el mercado?4. ¿Le afecta la paridad del dólar?5. ¿Ofrece un plus o es novedoso?

Lo anterior es con la finalidad de contemplar las posibilidades de éxito en la realización del proyecto.

¿Y cómo lo puedes saber?

En la actualidad existen diversas técnicas para detectar la situación en la que se encuentra el mercado en el cual queremos introducir nuestro producto o servicio, como son:

Encuestas Estudios de casos Cuestionarios Estudios de mercado Estudios socioeconómicos

Para ello te invitamos a revisar los siguientes puntos, los cuales te darán una idea del impacto que puede tener el proyecto y poder llegar a una conclusión.

Para que un proyecto tenga la posibilidad de realizarse es necesario que se consideren los siguientes rubros:

Atendiendo a estos rubros, entre otros, nos ayudará a deliberar si nuestro proyecto (de software): puede ser fructífero por un corto o largo período o de índole temporal; si vamos a depender siempre de publicidad; si sólo es aplicable en algunas regiones del país; si la comunidad necesita nuestro producto, etc.

2.4 Métodos de control

¿Te ha sucedido que en ocasiones tienes que realizar un trabajo escolar y por alguna razón el tiempo no te alcanza, que incluso tienes ubicadas las acciones en las que te tomará más tiempo concluirlas? O por el contrario, habrás experimentado que hay ocasiones en las que tienes suficiente tiempo que hasta puedes darte el lujo de ir a una fiesta y entregar el documento en la fecha establecida, sin preocupaciones ni presión de algún tipo. Con este ejemplo se pueden implementar los métodos de control y aplicarlos para cualquier actividad.

Los métodos de control son una serie de pasos que tenemos que seguir para llegar a nuestro objetivo, que en nuestro caso es realizar un proyecto de software para:

Recuerda que el tiempo para realizar tu proyecto es aproximadamente de dos meses, por lo que debes saber administrarlo adecuadamente. Para ello vamos a planear cada una de las actividades que llevarás a cabo, así como fijar las fechas de inicio y término de cada una de las actividades.

a) Gráfica de Gantt

Para llevar una buena administración de nuestro proyecto debemos llevar a cabo nuestra gráfica de Gantt. Ésta es la representación de las actividades a desarrollar durante todo el proceso del proyecto y la visualización de los respectivos tiempos en que se realizarán cada una de estas actividades.

Esto permitirá:

Ver la descripción de cada una de las actividades. Planificar las actividades del proyecto. Dar una base de cuándo termina e inicia cada una de las actividades. Asignar recursos. Comunicar las actividades del proyecto a los miembros del equipo. Coordinar y supervisar las actividades del proyecto.

Para realizar la gráfica de Gantt es necesario calendarizar las actividades. La calendarización del proyecto implica separar todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar dichas actividades. Por lo general, algunas de éstas se llevan a cabo en paralelo, lo que significa realizarlas al mismo tiempo por lo que se deben coordinar las actividades y organizar el trabajo, con la finalidad de que la mano de obra y tiempo se utilicen de forma óptima. Deben evitarse situaciones que retracen las actividades del proyecto entero.

El siguiente diagrama muestra los puntos importantes que deben considerarse para realizar la gráfica de Gantt.

Para la elaboración de esta gráfica necesitas abrir un documento en Project.

El llenado de este documento requiere lo siguiente:

a) En la primera columna llamada Id deberás manejar una clave para la actividad. Por ejemplo: A1 (A = actividad, 1 = número de la actividad). b) En la segunda columna llamada actividad, colocarás el nombre de la actividad.c) En la tercera columna duración, como su nombre lo indica, registrarás el tiempo total en días que tomará realizar la actividad.d) Cuarta columna comienzo: fecha de inicio de la actividad.e) Quinta columna predecesora: en el caso de que exista una actividad previa

indicarla con lo anotado en Id.f) Sexta columna fin: señalar la fecha de término para la actividad.

De manera paralela a todo esto, se irá registrando de manera automática en una gráfica de barras (en la otra parte de la tabla) los datos ingresados en los campos de las columnas arriba descritos.

Una vez que has realizado el llenado del documento con las actividades y posteriormente con los datos que arroja la gráfica, es momento de que los integrantes del equipo conozcan las actividades que deben de realizar en el tiempo establecido por la gráfica y el compromiso que tienen cada uno para el desarrollo del proyecto.

b) Camino crítico

El Camino crítico o Ruta crítica es una gráfica que representa el total de las actividades que se llevarán a cabo en el desarrollo de tu proyecto, así como la duración en días para realizarlas y la holgura de tiempo que tiene cada actividad. Esto nos permite tener un control del tiempo con el que contamos, así como las actividades que tenemos que realizar.

Conclusión

En este tema revisamos distintos modelos para el desarrollo de software, de los cuales, el modelo de cascada es el más adecuado para desarrolla tu software, sirviéndote de base y modelo para identificar y registrar los posibles riesgos que puedan presentarse en tu proyecto.

Revisaste la viabilidad y el manejo de métodos de control, así como la gráfica de Gantt y el camino crítico, mismos que te ayudaron a estimar los tiempos y tener un mejor control del desarrollo de tu software.

Por ello es importante tener presente que el ciclo de vida del desarrollo de software está en función del modelo adoptado, en este caso, el de cascada, el cual nos va a servir como referente para el desarrollo de las siguientes unidades temáticas.