Modelos de proceso de desarrollo de software

Page 1

FACULTAD DE INGENIERÍA ESCUELA INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

III PROGRAMA DE PROFESIONALIZACIÓN EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

MODELOS DE PROCESO DE DESARROLLO DE SOFTWARE

AUTOR:

Víctor Calderón Callao

ASESORAS:

Simona Parraguez Carrasco Jury Yesenia Aquino Trujillo

Chiclayo, enero 2010


DEDICATORIA

A mi esposa, Katherine. A mis hijos, Víctor André y Diego Joaquín, por comprender mi ausencia en el recreo, en el juego y en los paseos familiares. A partir de ahora las cosas volverán a ser como antes.


AGRADECIMIENTO Mi mรกs profundo agradecimiento a todas aquellas personas que me ayudaron en la realizaciรณn de este

breve

trabajo

monogrรกfico.

Colegas,

profesores, amigos, familia. Muchas gracias por su genuino desprendimiento.


ÍNDICE

DEDICATORIA AGRADECIMIENTO ÍNDICE ÍNTRODUCCIÓN

CAPÍTULO I: ASPECTOS GENERALES DE LA INGENIERÍA DEL SOFTWARE 1.1. 1.2. 1.3. 1.4. 1.5.

DEFINICIÓN DE INGENIERÍA DEFINICIÓN DE SOFTWARE DEFINICIÓN DE SISTEMA DEFINICIÓN DE INGENIERÍA DEL SOFTWARE ANALOGÍA PARA ENTENDER LA INGENIERÍA DEL SOFTWARE

1 1 2 3 4

CAPÍTULO II: MODELOS DE PROCESO DE DESARROLLO DEL SOFTWARE 2.1. 2.2. 2.3. 2.4. 2.5.

¿QUÉ SE ENTIENDE POR PROCESO? CICLO DE VIDA DEL SOFTWARE MODELO DE CASCADA MODELO DE PROTOTIPOS MODELOS EVOLUTIVOS O ITERATIVOS

7 7 8 10 12

2.5.1. MODELO INCREMENTAL 2.5.2. MODELO DE ESPIRAL

12 14

CONCLUSIONES

REFERENCIAS BIBLIOGRÁFICAS


INTRODUCCIÓN

El presente, es un modesto trabajo monográfico titulado: MODELOS DE PROCESO DE DESARROLLO DE SOFTWARE. Todo diseño de software comienza con un proceso de ingeniería del software. Es por ello que uno de los problemas más importantes con los que se enfrentan los ingenieros y los programadores en el momento de desarrollar un software, es la falta de marcos teóricos comunes que puedan ser usados por todas las personas que participan en el desarrollo del proyecto informático. Es que es una tarea difícil, puesto que la construcción del software está en función de las necesidades o requerimientos de los múltiples y diversos futuros usuarios, así como de la envergadura del proyecto. Existen modelos de diseño de software según las características y necesidades del proyecto. De ahí que surge la necesidad de entender dichos modelos y precisar sus características principales, así como las desventajas que se pueden presentar.

Es, pues, objetivo de este trabajo de investigación bibliográfica: 

Comprender el significado de la ingeniería del software, como disciplina fundamental del proceso de desarrollo de software.

Reconocer los diferentes criterios de algunos modelos de desarrollo de software para la elaboración de proyectos..

Diferenciar los modelos de software a estudiar y su pertinente aplicación en los futuros proyectos.

El presente trabajo se estructura de la siguiente manera: En el capítulo I, aspectos generales de la ingeniería del software, se tratan temas que constituyen el marco teórico de la presente monografía, base para poder entender las definiciones que se presentarán en el desarrollo de la misma. En el capítulo II, Modelos de proceso de desarrollo de software, se explica cada uno de los modelos a tratar, así como sus principales características que las diferencian.


CAPÍTULO I ASPECTOS GENERALES DE LA INGENIERÍA DEL SOFTWARE


1.1. DEFINICIÓN DE INGENIERÍA

Existen ciertos términos que son de uso diario y que necesitamos reforzar en sus significados dadas las aplicaciones y trascendencia de

los mismos.

Definitivamente que uno de esos términos es el de Ingeniería. Mucho se ha escrito al respecto y muchos le han dado la connotación del área del saber en el que se desarrolla. Según Sánchez [1] “La Ingeniería es una disciplina que pretende proporcionar métodos robustos, técnicas adecuadas y herramientas eficientes para crear soluciones reales a problemas del ámbito en el que se considere dicha ingeniería. Y por soluciones reales, debe entenderse que sean factibles, es decir, que puedan desarrollarse con los recursos de que dispone en plazo temporal aceptable” Sobrevilla [2] sostiene que la “Ingeniería es la profesión en la que el conocimiento de las ciencias matemáticas y naturales adquiridas mediante el estudio, la experiencia y la práctica, se emplea con buen juicio a fin de desarrollar modos en que se puedan utilizar, de manera óptima los materiales y las fuerzas de la naturaleza en beneficio de la humanidad, en el contextos de restricciones

éticas, físicas económicas, ambientales, humanas, políticas,

legales y culturales” De las definiciones anteriores se puede afirmar que la Ingeniería en general es la disciplina o profesión que valiéndose de las ciencias matemáticas y naturales, busca la solución más adecuada a problemas que se puedan presentar en su entorno, utilizando para este fin un conjunto de métodos, técnicas y herramientas que la respaldan en su objetivo.

1.2. DEFINICIÓN DE SOFTWARE Suele entenderse por software como la aplicación de un programa que satisface la necesidad o los requerimientos de un usuario, es más, muchas personas conviven con el sinónimo de software-programa, pero es necesario aclarar esta situación para ubicarnos correctamente en el tema que estamos tratando. Somerville [3] manifiesta que se suele pensar que software es un determinado grupo de programas que se ejecutan en una computadora, la verdad es que no se está muy lejos de ello, es correcto, pero también constituye 1


una definición muy limitada, pues el software implica, además, documentos y la configuración de datos que hacen posible que los programas funcionen adecuadamente. De esto se desprenden los elementos que constituyen un software: un grupo de programas, archivos que hacen posible que estos programas se

ejecuten,

documentos

que

describen

la

estructura

y

funcionamiento del sistema y enlaces que hacen posible la actualización de dicho sistema. Una definición interesante de software, es la brindada por los esposos Laudon [4] quienes expresan que “el software es el conjunto de instrucciones detalladas que controlan la operación de un sistema de cómputo. Sin el software, el hardware de las computadoras no podría realizar las tareas que se asocian con las computadoras” De las definiciones presentadas podemos comprender que software es el conjunto de instrucciones que hacen posible el buen funcionamiento de todo un sistema. Estas instrucciones van dirigidas a un grupo de programas y acompañadas por archivos, documentaciones y enlaces a actualizaciones que hacen posible su funcionamiento más eficaz a favor del usuario. Con esto se amplía más nuestro marco teórico respecto al significado de software que constituye una parte importante en el presente trabajo monográfico.

1.3. DEFINICIÓN DE SISTEMA No es una idea nueva hablar de sistemas, pues desde tiempos remotos, el ser humano necesitó agruparse para consolidar su fuerza y su posición en su medio y así conseguir objetivos comunes como alimentarse, vestirse, cultivar la tierra, organizarse, etc. En las palabras de Cortés [5]: “Un Sistema es una unidad compuesta por partes interrelacionadas, dinámicas y cambiantes, en busca del cumplimiento de una misión. Además, cada una de esas partes tiene su razón de ser y, si alguna de ellas falla, el sistema se ve afectado. De esta definición se desprende la dependencia biunívoca de las partes que constituyen el sistema, así como la vital importancia de las mismas para el correcto funcionamiento del todo.

2


Otra definición importante y que tiene que ver ya con la parte informática es la que nos presentan Troya y Vallecillo [6] cuando afirman que “Entendemos por sistema a un conjunto de mecanismos y herramientas

que permiten la

creación e interconexión de componentes de software, junto con una colección de servicios para facilitar las labores de los componentes que residen y se ejecutan en él” A partir de estas dos definiciones, así como de otras que podamos encontrar, podemos afirmar que todos están de acuerdo en que es un conjunto de

partes

debidamente

ordenadas

y

coordinadas

y

que

interactúan

acertadamente para conseguir no uno, sino más de un objetivo.

1.4. DEFINICIÓN DE INGENIERÍA DEL SOFTWARE Hasta aquí ya hemos analizado algunos términos imprescindibles en su significado y que nos permitirán entender y clarificar el contexto en el que se desenvuelve y desarrolla la ingeniería del software. Precisamente aquí es donde se quiere llegar, definir la Ingeniería del Software, saber qué dicen los expertos y producir una definición propia a partir de sus saberes. De esta forma, encontramos la definición que brindan Naur y Randell [7] quienes sostienen que “la Ingeniería del Software es el establecimiento y uso de principios de ingeniería, orientados a obtener software económico, que sea fiable y funcione de manera eficiente sobre máquinas reales. Esta definición perfila a la ingeniería del software hacia el uso adecuado del producto final el cual evidentemente es un software que responda a las necesidades de los usuarios y que satisfaga el trabajo realizado por los ingenieros y desarrolladores. Todo ingeniero de software es consciente de lo efectivo que debe ser su producto final y, aún más. La ingeniería del software tiene, además, otras implicancias tal como se manifestó en la Computing Curricula 2005: The overview report [8]: “Software Engineering

es la disciplina del desarrollo y

mantenimiento de sistemas software que se comportan de manera confiable y eficiente, son factibles de desarrollar y mantener, y satisfacen todos los requerimientos que los clientes hayan definido para ellos. Más recientemente ha evolucionado en respuesta a factores como el creciente impacto de grandes y

3


costosos sistemas de software en un amplio rango de situaciones y el incremento de la importancia del software en aplicaciones de seguridad crítica”. Como complemento de la primera definición, esta segunda hace referencia, además, en el mantenimiento y la importancia de su uso sobretodo en situaciones que tienen que ver con la seguridad crítica, es decir, con aquellas situaciones que ponen en peligro la seguridad de una nación o con situaciones que atenten directamente contra la salud de las personas. Interesante es la definición que Cortés [5] comparte con nosotros sobre ingeniería del software al señalar que “es el conjunto de métodos, procedimientos y herramientas que buscan construir un software de alta calidad, efectiva,

lo cual por asuntos de costos, imagen y satisfacción de nuestros

clientes, es crucial en nuestros tiempos. Dentro de ese proceso de construcción de sistemas (que a la postre debe reflejarse en un software), el análisis juega un papel importante”. Esta última definición hace hincapié en los métodos, procedimientos y herramientas. Los métodos, que corresponden al cómo se va a construir el software, el cual incluye a la planificación y estimación de proyectos, análisis de los requisitos del sistema y del software, arquitectura de programas, prueba, mantenimiento, documentación entre otros. Las herramientas suministran soporte automático o semiautomático para los métodos y, por último, los procedimientos relacionan a los métodos y a las herramientas facilitando el desarrollo adecuado del software [9] Es decir, llamamos ingeniería del software al conjunto ordenado y sistematizado de métodos, herramienta y procedimientos que hacen posible el buen desarrollo y posterior uso del software, de tal forma que esté presto a mejoras exigidas por el entorno.

1.5. ANALOGÍA PARA ENTENDER LA INGENIERÍA DEL SOFTWARE Quizá para la persona común y corriente no esté clara la idea de ingeniería del software. Entonces urge la necesidad de hacerla más accesible a todos los que de alguna u otra manera se interesen en el tema. Por ello se estima conveniente considerar la siguiente analogía: Supongamos que se quiere construir una casa. Nos aseguraríamos que el planeamiento, diseño y construcción sigan el mejor método posible. Bastarán 4


unos pedidos, como clientes que es, para que se ponga en marcha al proyecto. Los requerimientos serían, por ejemplo, que esa construcción sea antisísmica, que tenga amplias ventanas, que tenga una distribución de tal tipo, que tenga ciertos ornamentos, etc. El proyecto lo dejamos en manos de expertos en el campo (ingenieros, arquitectos, maestros de obras, artesanos, albañiles, electricistas, etc.), pues no podríamos supervisar todo lo que implica la obra. Para eso están dichos expertos, que son los encargados de seguir las metodologías, de cumplir con los procedimientos y de utilizar las herramientas de construcción adecuadas. Ahora, pongámonos en la condición del ingeniero o arquitecto a cargo del proyecto. Nos manejaríamos así: 

Por un lado, atenderíamos las demandas del cliente que es quien pone el dinero y el que describirá los requerimientos que debe tener la construcción.

Por otro lado, nos comunicaríamos con colegas para poder intercambiar posibles soluciones a los problemas planteados en los requerimientos del cliente, así como comunicar a otros (maestros de obras, albañiles, etc.) cómo debe llevarse a cabo esa solución.

Por último, utilizaríamos nuestro conocimiento teórico y práctico, así como en un enfoque metodológico dado, probado y seguido por varios colegas, para esbozar y concretar de la mejor forma, la solución que se pide[5]. Rescatamos, entonces la idea práctica de cómo se suceden los procesos

en el desarrollo de software desde la perspectiva del usuario y del diseñador. Es la tarea de la ingeniería del sistema asegurar la correcta utilización de procesos que aseguren una solución eficiente ante la problemática presentada. Al igual que una casa, edificio o artefacto a construir, los responsables de ello tratarán de hacer un trabajo que encuentre resistencia, fiabilidad, robustez, compatibilidad, etc que aseguren que dicho producto es de calidad. Esta es pues, la labor de la ingeniería de sistemas.

5


CAPÍTULO II MODELOS DE PROCESO DE DESARROLLO DE SOFTWARE


2.1.

¿QUÉ SE ENTIENDE POR PROCESO? Como acción preliminar al desarrollo de este capítulo y para mayor entendimiento del mismo, es necesario entender lo que significa la palabra proceso, pues ello clarificará el vasto universo que constituye los modelos de proceso de software. Entendemos por proceso al conjunto secuencial y ordenado de pasos o tareas para lograr un producto final deseado. Este conjunto en referencia involucra a una serie de herramientas, técnicas, actividades, restricciones y recursos que producen un resultado o salida esperada. Si la salida implica la construcción de un producto, entonces de denomina ciclo de vida, de la cual se hablará más adelante [10]. Por otro lado los esposos Landon [4] señalan que los procesos “implican la transformación de los flujos de datos de entrada en flujos de salida de datos en un diagrama de flujo”. De lo señalado en las definiciones anteriores, podemos afirmar que los procesos direccionan la transformación de datos en resultados deseados cumpliendo, para ello, con condiciones que hacen posible su transformación.

2.2.

CICLO DE VIDA DEL SOFTWARE

Anteriormente ya se había manifestado que cuando los procesos implican la construcción de productos, estos recibían la denominación de Ciclo de Vida. Veamos qué más se dice al respecto. La norma IEEE 1074 define el ciclo de vida de software como una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software, mientras que la norma ISO 12207 – 1 entiende por modelo de ciclo de vida un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso [11].

6


Figura 1. Tomado de Forouzan, Behrouz A. 2003. Introducción a la ciencia de la computación: de la manipulación de datos a la teoría de la computación. México D.F: International Thomson Editores, S.A, p.196

Entonces el proceso de desarrollo de software suele llamarse ciclo de vida de software porque describe la vida de un producto de software desde su concepción, su implementación, entrega, utilización, mantenimiento hasta que se deje de utilizar. Lo que sí debe quedar claro es que a pesar de los diferentes modelos de desarrollo de software que existen, todos ellos tienen fases comunes que los caracterizan: análisis, diseño, implementación y pruebas [12].

Figura 2. Fases de desarrollo del sistema. Tomado de Behrouz Forouzan. Introducción a la ciencia de la computación

Existen varias formas de realizar este proceso de software. A través de los años se han planteado y ejecutado propuestas que han sido valoradas, criticadas y aceptadas en función de su adecuación al producto final. 7


Rescatamos los siguientes modelos de desarrollo de software: 2.3.

MODELO DE CASCADA Este es uno de los primeros modelos de diseño de software presentados a la comunidad informática. Veamos que se dice de él al respecto. En este modelo el proceso de desarrollo fluye en forma lineal y sumativa. Esto significa que una fase no puede iniciarse hasta que se ha completado la fase anterior o lo que es lo mismo, el producto de cada una de las fases es la entrada de la siguiente fase [12]. Al principio

fue

bien

recibido

y

aceptado

por

la

comunidad

desarrolladora considerando que el mismo Departamento de Defensa de los Estados Unidos lo uso por varios años, es que entre sus características se encuentra su simplicidad para explicarlo a todos aquellos que no se encuentran familiarizados con el desarrollo de software. Además, deja en claro los productos intermedios a conseguir de tal manera que se pueda empezar con la siguiente etapa [10]. Desgraciadamente, el modelo de cascada no describe con precisión la forma verdadera de desarrollo de software. El mundo real de la creación de programas no procede uniformemente desde el primero al último paso sino que más bien, en cualquier etapa, es típica la necesidad de dar un paso o dos atrás antes de seguir progresando [13]. Este modelo, entonces, es demasiado vertical como para meditar y observar en retrospectiva el trabajo realizado. Ya se estimará que los errores observados hasta la utilización del producto dejan pérdidas que podrían tener repercusiones fatales en seguridad y salud. A continuación se detalla cada una de ellas [3]: Análisis y definición de requerimientos. A partir de las consultas con los potenciales usuarios se definen a detalle los servicios, restricciones y metas del sistema. Diseño del sistema y del software. Se establece una arquitectura completa del sistema. El proceso de diseño del sistema divide los requerimientos en diseños de hardware o software. El diseño de software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.

8


Implementación y prueba de unidades. Se lleva a cabo el diseño del software como un conjunto de programas o unidades. La prueba de unidades implica que cada uno cumpla sus especificaciones. Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un solo sistema y de esta manera asegurar el cumplimiento de los requerimientos del software. Después de la prueba el sistema software se entrega al cliente. Funcionamiento y mantenimiento. Posiblemente esta es la fase más larga del ciclo de vida y consiste en la instalación y funcionamiento del sistema. Es de resaltar que el mantenimiento incluye la corrección de errores aún no descubiertos en etapas anteriores, la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubran nuevos requerimientos.

DEFINICIÓN DE REQUERIMIENTOS DISEÑO DEL SISTEMA Y DEL SOFTWARE IMPLEMENTACIÓN Y PRUEBA DE UNIDADES INTEGRACIÓN Y PRUEBA DEL SISTEMA FUNCIONAMIENTO Y MANTENIMIENTO Fig. 3. Modelo de cascada. Tomado de Somerville, Ian. 2005: Ingeniería del Software. Madrid: Pearson Educación S.A, p.62.

2.4.

MODELO DE PROTOTIPOS Anteriormente hemos visto las ventajas, pero también las limitaciones del modelo de cascada. Esto llevó a proponer modelos que superaran estos obstáculos, sobretodo que permitiera concretar los requisitos, algunos de los cuales conservaban la línea clásica del modelo ya mencionado. La mejora inmediata se presenta mediante el modelo de prototipos, algo así como la 9


construcción de un software provisional que da prioridad a la rapidez y la facilidad de modificación antes que a la eficiencia en el funcionamiento. Pressman [14] manifiesta que todo cliente que necesite de un sistema de software exige ciertas características funcionales en el producto final, pero desconoce los requerimientos pormenorizados de la entrada, proceso o salida del mismo. Otra figura es que el desarrollador no está muy convencido de la eficacia de un algoritmo o de la interacción hombre – máquina. Así como estas situaciones hay muchas más que se pueden salvar mediante la aplicación de un modelo de prototipos en la elaboración de software (al prototipo también se le llama primer sistema). En este modelo el cliente determina unos requisitos previos con los cuales se construye un prototipo, con éste podrá decidir lo que realmente quiere y cómo lo quiere. Este mismo proceso podrá repetirse hasta conseguir un prototipo que se ajuste a las necesidades del cliente. Por su parte el desarrollador en este constante ejercicio comprenderá mejor lo que necesita hacer. Mediante este modelo la comunicación entre desarrollador y cliente está asegurada, pues el prototipo se constituye en una especie de maqueta lo que facilita evaluar el producto antes de construirlo definitivamente. Sin embrago, construir prototipos puede traer algunos inconvenientes: 

El cliente generalmente asume que el prototipo es el resultado final, por lo que exige rápidamente el producto sin detenerse a pensar en que hay que construirlo de tal forma que se ajuste a las normas de calidad establecidas.

Al revisar el producto en cada etapa de su construcción se podrían exigir demasiadas condiciones o requisitos, lo que representaría una construcción inacabable.

Fig. 4. Modelo de prototipos. Tomado de Ingeniería del software. Un enfoque práctico. Roger Pressman.

10


¿Cuándo es necesario utilizar el modelo de prototipo? Somerville [3] sostiene que este modelo es recomendable para sistemas pequeños o medianos de más o menos 500 000 líneas de código. Para sistemas grandes se presentan problemas agudos considerando, además, que diferentes equipos desarrollan diferentes partes del sistema. En todo caso, para proyectos muy grandes es recomendable un proceso mixto con las mejores características del modelo de cascada y del evolutivo [prototipo]. Las partes del sistema bien comprendidas se pueden especificar y desarrollar utilizando un proceso basado en el modelo de cascada. Las otras fases, como la interfaz del usuario, que son difíciles de especificar por adelantado, se deben desarrollar siempre utilizando el modelo de prototipos. Entonces, hasta aquí se puede precisar que este modelo de desarrollo de software tiene la ventaja de que las especificaciones se pueden dar de manera creciente, los usuarios entenderán mejor su problema el mismo que se verá en el sistema software final, Sin embargo, tiene el problema de corromper la estructura del software si los cambios son muy continuos, la cual se convertiría en una tarea kilométrica, difícil y costosa.

2.5.

MODELOS EVOLUTIVOS O ITERATIVOS Los modelos de desarrollo de software anteriormente estudiados se basan en la producción de un resultado final, por ejemplo para el modelo de cascada el producto final o sistema completo se considera concluido cuando se pasa verticalmente por todas las etapas que demanda este paradigma. Para el modelo de prototipos es necesario que tanto el cliente como el programador entiendan o clarifiquen totalmente los requisitos del futuro sistema [14]. Sin embargo, las exigencias del mercado y las condiciones respecto al tiempo de entrega condicionan muchas veces la calidad del producto a entregar. Se hace necesario, entonces que el sistema a presentar evolucione de acuerdo a los requerimientos y exigencia coyunturales. De aquí se desprende el uso de los modelos iterativos. Se entiende por iteración, de acuerdo a Carrero [15], a “la repetición de una secuencia de instrucciones o eventos. Por ejemplo, en un lazo de programa, una iteración se produce una vez a través de las instrucciones del lazo”. 11


Mariano y Miguel Mataix [16], consideran que se llama proceso iterativo al “proceso en el que se ejecutan repetidamente una serie de instrucciones, cada repetición aproximándose más al resultado deseado, hasta que se cumple una condición específica”. Queda, entonces, perfilado el modelo evolutivo como esa secuencia de etapas evolutivas y, por lo tanto, generadora de mejores resultados en cada una de ellas. Dos son los modelos que se desprenden de aquí: el modelo incremental y el modelo de espiral. De ellos se habla a continuación.

2.5.1

MODELO INCREMENTAL Tomando las referencias de Pressman [14], este modelo toma las características del modelo de cascada (pero las etapas en secuencia repetitiva) y del modelo de prototipos (pero sin desechar lo ya trabajado) para el desarrollo del software, aplicando una secuencia lineal mientras avanza el tiempo calendario. Cada incremento presentado constituye una versión preliminar del sistema a entregar (versión incompleta del producto final), pues en cada parte del proceso el sistema se va robusteciendo e incrementado. Con los incrementos podemos asegurar el uso de las principales funcionalidades del sistema desde el principio del desarrollo y, a la vez, especificar cambios en entregas posteriores. Claro que los cambios están en función de los requerimientos del cliente o futuro usuario quienes deben estar plenamente comprometidos con el sistema que se está desarrollando hasta alcanzar el resultado final. Sin embargo, este modelo tiene los siguientes problemas [3]: -

Como el sistema va mejorando en cada proceso de desarrollo, se hace difícil entregar la documentación debida, pues recordemos que los primeros requerimientos constituyen una versión incompleta del sistema final.

-

Dado que los incrementos se desarrollan a través del tiempo, los clientes pensarían dos veces antes de firmar un contrato que implique el pago del producto hasta que este quede totalmente

terminado,

el

presupuesto

sería

un

factor 12


determinante

para

futuros

conflictos

entre

las

partes

comprometidas. De igual manera, los desarrolladores no aceptarían un contrato fijo, pues los incrementos se pueden suscitar en laxos de tiempo relativamente largo.

Figura 5. Modelo incremental. Tomado de Pressman, Roger S. 2002. Ingeniería del Software. Un Enfoque Práctico. 5ta. Edición. Madrid: McGraw Hill / Interamericana de España, S.A.U, p. 24

2.5.2

MODELO DE ESPIRAL Consideramos importante el alcance de Sánchez [1] sobr e este modelo quien considera que este modelo unifica los modelos de cascada y de prototipos, claro está, sin perder la perspectiva evolutiva que la caracteriza. Se añade el análisis de riesgo como característica diferencial. En este modelo se fijan cuatro fases determinantes para el desarrollo del software. Cuando el sistema pasa por las cuatro fases, se dice que ha recorrido un ciclo. El ciclo es repetitivo hasta que se concluya con el sistema de software final. Las cuatro etapas de la que se hace referencia es explicada por Somerville [3] de la siguiente manera: “Cada ciclo de la espiral se divide en cuatro sectores:

13


1. Definición de objetivos. Para esta fase del proyecto se definen los objetivos específicos. Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestión. Se identifican los riesgos del proyecto. Dependiendo de estos riesgos, se planean estrategias alternativas.

2. Evaluación y reducción de riesgos. Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto identificado. Se definen los pasos para reducir dichos riesgos.

3. Desarrollo y validación. Después de la evaluación de riesgo, se elige un modelo para el desarrollo del sistema.

4. Planificación. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. Si se debe continuar se desarrollan los planes para la siguiente fase del proyecto”.

Por su parte, Ortega [17] nos dice que las diferentes actividades que se presentan en este proceso – modelo de espiral – se ubican en un plano cartesiano, en cada cuadrante se ubica una clase particular de actividades: Planificación, análisis de riesgo, ingeniería y evaluación. De estas dos apreciaciones se puede establecer una somera relación, puesto que en la práctica significan lo mismo: Planificación = Definición de Objetivos Análisis de riesgo = Evaluación y reducción de riesgos Ingeniería = Desarrollo y validación Evaluación = Planificación Esto es, el proceso evolutivo de construcción del software empieza con la actividad de la planficación. Posteriormente se evaluarán los riesgos existentes. Si el riesgo de continuación del proyecto es muy grave, éste se detendrá. Si no, se sigue con la actividad de ingeniería, que construirá un producto sujeto a 14


evaluación por parte del cliente. De las observaciones de estos últimos se hará una nueva planificación, se estudiarán los nuevos riesgos, se hará el siguiente producto de ingeniería. Una vez que el cliente dé por aprobado el producto, se planificará la puesta en producción, se evaluarán los riesgos y se concluirá, en la actividad de ingeniería, con la puesta en producción de la aplicación. Pressman [14] considera que este modelo de desarrollo de software es el más realista, sobre todo para proyectos de gran complejidad. Sin embargo, anota los siguientes problemas: -

Es un paradigma o modelo relativamente nuevo, por lo que aún es muy prematuro evaluar su adaptabilidad al desarrollo de software.

-

Requiere de una gran habilidad para la identificación de riesgos. Si un riesgo no se detecta, el conjunto del proyecto puede verse afectado.

-

Tal vez sea difícil de convencer a los clientes del enfoque evolutivo del paradigma, dentro del cual es poco claro visualizar la finalización del proyecto.

PLANIFICACIÓN

ANÁLISIS DE RIESGOS

INGENIERÍA EVALUACIÓN DEL CLIENTE

Figura 6. Modelo de espiral

15


Como ya se dijo anteriormente, los proyectos cuya naturaleza es muy compleja o se tiene poca experiencia, el paradigma o modelo puede adecuarse bien, por su enfoque evolutivo, en el que se pasa siempre por actividades bien definidas, y el cual se puede amoldar a una labor explorativa.

La siguiente es una muestra estadística que refleja el papel de la ingeniería de sistemas y de la aplicación de modelos en el diseño de software. En 1984, Standish Group analizó a más de 350 empresas norteamericanas y 8 mil proyectos de desarrollo de software. Los resultados arrojaron que sólo el 16,2% y el 9% de pequeñas y grandes compañías respectivamente, finalizaban dentro de los costos y de los plazos establecidos. El 52,7% de los proyectos finalizaban excedidos ampliamente en el presupuesto (sobre el 189%) y con grandes retrasos de tiempo (más de 122%), a esto hay que agregar la merma en las características funcionales del producto. Por último, el 31,1% restante se cancelaban, esto equivale a una pérdida cuantitativa de 81 billones de dólares [18].

Ya al final del presente trabajo es necesaria la reflexión acerca del papel de la ingeniería de software, de la labor del ingeniero y de la importancia del ciclo de desarrollo de vida del software. Es precisamente este último el que se desarrolla a través de modelos, de los cuales ya hemos hablado, pero que a la larga llevan al producto que realmente se necesita. Se requiere un trabajo concienzudo respecto al sistema de software a elaborar, sino las pérdidas en el lento o dilatado trabajo pueden ser demasiados significativos.

16


CONCLUSIONES

La ingeniería del software constituye la más real e importante disciplina en la construcción, mantenimiento e implementación del software. Comprende todos los aspectos de la producción del software. Esto le permite ocupar un lugar especial y e importante, puesto que el software se encuentra en nuestras vidas y hace que ella sea más cómoda. La ingeniería del software se centra, pues, en el desarrollo de software de calidad que responda a las grandes necesidades de los usuarios.

Todo proyecto de desarrollo de software pasa por etapas bien definidas: análisis diseño, implementación y pruebas. Según el modo en que se organizan se definen diferentes modelos de ciclo de vida. Sin embargo, también hay que considerar el alcance que éste tendrá, así como su grado de complejidad en su arquitectura., herramientas con que se cuenta, experiencia, cultura organizacional, etc. Esto también determina la aplicación de uno u otro modelo.

Se puede observar dos grupos bien marcados de modelos de desarrollo de software: aquellos que se centran en el producto final (casada y prototipos) y aquellos que priorizan el proceso en la construcción del producto final (evolutivos o iterativos). No existe un modelo definitivo, por eso se dice que tampoco existe un software totalmente perfecto. Cada modelo de desarrollo de software es útil y cada uno de ellos es necesario para mejorar y enriquecer a la propuesta venidera. Por ejemplo los modelos evolutivos toman lo mejor de los modelos anteriores (cascada y de prototipos) para presentar una propuesta de desarrollo de software.


REFERENCIAS BIBLIOGRÁFICAS

[1] Sánchez, José. 2003. Ingeniería de proyectos informáticos: actividades y procedimientos. Castelló de la Plana: Universidad Jaume I, p.1. [2] Sobrevila, Marcelo. 2001: Estudio del vocablo Ingeniería. Buenos Aires: Consejo Federal de Decanos de Ingeniería de la República Argentina, p.4

[3]Somerville, Ian. 2005: Ingeniería del Software. Madrid: Pearson Educación S.A, p.62, 68-69. [4]Laudon, Kenneth C y Jane P. Laudon. 1996: Administración de los sistemas de información: Organización y tecnología. 3ra. edición. Naucalpan de Juárez: Prentice Hall Hispanoamericana, S.A, p. 226. [5] Cortés, Roberto. 2006. Introducción al Análisis de Sistemas y a la Ingeniería del Software. San José: Universidad Estatal a Distancia, p.13, XVII, p. 5. [6] Troya, José M y Antonio Vallecillo. 2000. Ingeniería del Software y Base de Datos: Tendencias Actuales. Cuenca: Ediciones de la Universidad de Castilla – La Mancha, p. 60. [7] Naur, Peter y Brian Randell citados por Barranco, Jesús. 2001: Metodología del análisis estructurado por sistemas. Madrid: Universidad Pontificia Comillas de Madrid, p.26. [8] Computing Curricula 2005: The overview report., citado por Colegio de Ingenieros del Perú. 2006: Denominaciones y perfiles de las carreras en ingeniería de sistemas, computación e informática. Lima, p.15. [9] Vivas W, Pedro y Emilio Lópes R. 2009. Cuerpo de profesores de enseñanza secundaria. Informática. Temario Vol.II. Madrid: editorial CEP S.L. [10] Pfleeger, Shari L.2002. Ingeniería del software. Teoría y práctica. Buenos Aires: Pearson Education S.A, p. 55 [11] Leyva, Esteban, José I. Prieto y María Sampalo. Sistemas y aplicaciones informáticas. Sevilla: editorial MAD. S.L, P. 71. [12] Forouzan, Behrouz A. 2003. Introducción a la ciencia de la computación: de la manipulación de datos a la teoría de la computación. México D.F: International Thomson Editores, S.A. [13] Braude, Eric J. 2003. Ingeniería de software: Una perspectiva orientada a objetos. México D.F: Alfaomega grupo editor. [14] Pressman, Roger S. 2002. Ingeniería del Software. Un Enfoque Práctico. 5ta. Edición. Madrid: McGraw Hill / Interamericana de España, S.A.U


[15] Carrero F, David. 2010. Diccionario informático. http://www.glosarium.com/term/824,14,xhtml . (Consultado en enero 28, 2010). [16] Mataix L, Mariano y Miguel Mataix H. 1999. Diccionario de electrónica, informática y energía nuclear. Inglés-español. Español-inglés. Madrid: ediciones Díaz de Santos. S.A, p. 312. [17] Ortega C, Manuel y Bravo R, José. 1997. Informática industrial. La Mancha: Publicaciones de la Universidad de Castilla. [18] Gacitúa B, Ricardo. 2003. Métodos de desarrollo de software: el desafío pendiente de la estandarización. Tehoria. Ciencia ,arte y humanidades.


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.