Contenido

1 Modelos de procesos de software

2 Habilida des blandas, trabajo en equipo

En el Escenario anterior se abordaron las principales características de un proceso de

software, sin embargo, la ejecución específica del proceso de software difiere

significativam en te de acuerdo con las características de cada proyecto, entre las diferencias

más relevantes se encuentran las siguientes:

• Flujo general de las activida des, accion es y tareas, así como de las interdepen den cias entre ellas

• Grado en el que las acciones y tareas están definidas dentro de cada activida d estructural

• Grado en el que se identifican y requieren los productos del trabajo

• Forma en la que se aplican las activida des de aseguram iento de la calidad

• Manera en la que se realizan las activida des de seguimien to y control del proyecto

• Grado general de detalle y rigor con el que se describe el proceso

• Grado con el que el cliente y otros participantes se involucran con el proyecto

• Nivel de autonomía que se da al equipo de software

• Grado con el que son prescritos la organización y los roles del equipo (Pressman , 2010, 14)

De acuerdo con las necesidades de los diferentes proyectos se han definido distintos modelos

del proceso de software, también conocidos como “ciclos de vida del software”. Estos se

clasifican en dos:

2
 1. Modelos de procesos predictivos o tradicion ales: enfatizan la definición , la

identificación y la aplicación detallad a de las actividades y tareas del proceso. En

especificar muy bien los requerimien tos y el camin o a seguir antes de comen zar y

ceñirse a dicho camin o fielmen te documentando todo. Si estas metodologías no

se usan con un criterio que defina que

adaptacion es son necesarias, puede resultar en un proceso demasiado burocrático

que genera complejidades innecesarias.

2. Modelos de procesos ágiles: su énfasis está en la maniobra bilida d y la adapta bilida d,

son mucho más flexibles que los modelos tradicion ales por lo que se adaptan con más

facilidad a las condiciones cambiantes.

Este tema nos enfocaremos en los modelos de procesos prescriptivos o tradicion ales y en él

se ve con más detalles las características de los modelos de procesos ágiles y las

metodologías que lo aplican.

3
 Modelo en Cascada

proceso de software en el tiempo. Este es el primer modelo de procesos formalmente

definido y es conocido como el ciclo de vida clásico. De acuerdo con diferentes autores

se pueden encontrar variacion es en el número

de etapas a desarrollar y los nombres asignados a los mismos, sin embargo, su característica

principal es que aplica el flujo de procesos lineal, es decir que es necesario lograr todos los

objetivos de una actividad para continuar con la ejecución de la siguiente. De acuerdo

con Pressman (2010) Las principales etapas de este modelo son las siguientes:

• Comunicación: en dónde se busca definir con detalle el alcance y los

requerimientos del proyecto, otros autores la nombran como etapa de análisis y

definición de requerimien tos.

• Planeación : en esta etapa se define el plan de proyecto, es decir, cuáles son las

actividades que se van a desarrollar y el tiempo y demás recursos.

• Modela do: en esta etapa y a partir de los requerimien tos identificados de manera

previa, se define la arquitectura y la estructura general interna del software a

implem en tar, en otras aproxim acion es esta etapa se conoce la etapa de diseño y

también se puede encontrar dividida en: diseño prelimin ar en donde se definen la

arquitectura de alto nivel y diseño detallado en donde se incrementa el nivel de

especificid ad de los modelos desarrollad os.

• Construcción : en esta etapa se implem en tan las unidades de código que

reflejen el diseño definido con anteriorid ad. Cada una de ellas es probada para

garantizar que cumple con la especificación del diseño, esta etapa es también
4
 conocida como etapa de implementación o codificación.

• Despliegu e: es la etapa en que el software es puesto en producción , incluye

también la capacitación de los usuarios y las actividad es de soporte y

manten imien to. Esta etapa es también conocida como: etapa de

implantación, operación y mantenimiento o funcionamiento y

mantenimiento.

inicio del proyecto estimación diseño código pruebas entrega

Modelo de cascada

Figura 1. Modelo en Cascada

Este modelo presenta las siguientes ventajas:

• Dado que las etapas están claramen te definidas, se facilita su planeación , seguimiento

y control ayudan do a prevenir que se sobrepasen las fechas de entrega y los costes

esperados.

• En el caso de proyecto donde los requerimientos están bien definidos y hay poca

probabilid ad de que se presenten cambios en la especificación hay bajos riesgos.

• Este modelo muestra los pasos que son intuitivos cuando se está desarrollan do software.

5
Algunas de sus desventajas son las siguientes:

• Es difícil responder a los cambios de los requerimientos del cliente ya que cualquier

cambio afecta a todo el proyecto y en el mundo real es muy difícil encontrar un

proyecto en donde se pueda asegurar que los requerimien tos se pueden identificar y

no van a sufrir variacion es.

• Pasar por cada etapa de manera estrictamente secuencial puede hacer que se pierda

tiempo en el proceso ya que parte del equipo puede estar esperan do a que otros

terminen determin ada etapa para poder continuar a la siguiente.

• Las revisiones de proyectos de gran complejidad son muy difíciles.

• Entre más tarde se detecte un error más costoso resulta su corrección.

• El usuario no podrá tener una versión funcional sino hasta en las etapas finales del proceso.

1.1. Modelo de Procesos Incremental

La Figura 2, Modelo de procesos incremental, presenta las actividades y el desarrollo en el

tiempo del modelo de procesos incremen tal, el cual combin a el flujo de procesos lineal y

6
paralelo para dar respuesta adecu ada a proyectos donde no es posible esperar a tener

toda la especificación de requerimientos del sistema y se tienen que tener partes

funcionales del sistema rápidamen te e ir amplian do esta funcionalida d en entregas

posteriores. La primera entrega será el producto que correspon de a las funcionalidades

básicas o mínimas requeridas que se van a ir complem en tan d o con cada incremento.

Incremento # n
Funcionalidad y caracterí st ica s del software

Modelado Incremento # 2
n-ésimo
Construcción

Calendario del proyecto

Figura 2. Modelo de procesos incremental

7
Las características fundamentales de este modelo son las que se explican a continuación:

• Se ajusta a entornos de alta incertidu m bre donde los requerimien tos no se

conocen en su totalidad al inicio del proyecto o hay un alto riesgo de que

sufran modificaciones.

• El sistema se crea por compon entes que luego se integran para formar el sistema.

• El sistema se divide en entregas sucesivas que se van entregan d o e integran d o a

medida que se desarrollan y no un gran sistema con una única fecha de entrega.

Las principales ventajas de este modelo son que se explican a continuación .

• Se acortan los tiempos de entrega y el usuario ve algo que puede valorar del

sistema con más frecuencia.

• El usuario participa más en el desarrollo de proyecto ya que las etapas en las que más

particip a que son las etapas de comunicación y despliegu e están ocurriendo de

manera iterativa.

• Al tener alguna funcionalida d más rápidamente el usuario percibe un retorno de la

inversión más rápidamente.

• Al reducir la complejida d del sistema el más fácil gestion ar los riesgos

8
 • Es más fácil gestion ar los cambios en los requerimientos ya que se pueden aumentar o

modificar en cada versión.

• Reduce costos, si algo sale mal solo volvemos a la antigu a versión y continuamos

desde ese punto, no tenemos que comenzar todo el proceso de nuevo.

Este modelo presenta las siguientes desventajas.

• Al no tener una especificación de requerimien tos inicial se hace más difícil estimar el

coste total del proyecto.

• Este modelo incrementa la complejidad en la gestión del proyecto, por lo que se

requiere gestores experimentados.

• Difícil de aplicar a sistemas transaccion ales que tienden a ser integrados y a

operar como un todo.

• La interacción constante de los usuarios para retroalim en tar puede hacer

que se avance lentamente.

• La participación constante de los usuarios finales puede agregar costos o reducir la

productivid ad de la empresa.

9
 1.2. Modelo de procesos por prototipos

Este modelo de procesos, más que modificar las activida des o su flujo, agrega al modelo

de cascada o incremental la posibilidad de modelar el producto final verifican do algunas

características antes de construirlo. La Figura 3. Modelo de procesos de prototipo

presenta esta aproximación sobre

el modelo de procesos en cascada, incluye la generación de prototip os al finalizar la etapa

de comunica cion es, y durante la etapa de modelado incluyen do un prototipo del diseño de

alto nivel y un prototipo del diseño detallado. Los prototipos tienen dos funcionalidades.

10
 • El cliente ve el producto (en una versión no funcional) y refina sus requisitos.

• El ingeniero compren de mejor lo que va a hacer.

Actividades Ejecución de actividades

Comunicación

Prototipo
Identificación de
requerimientos

Planeación

Estimación
Programación
Seguimiento

Prototipo de diseño detallado

Construcción

Código
Modelado

Diseño
Despliegue
Entrega
Asistencia
Retroalimentación

Tiempo

Figura 3. Modelo de procesos de prototipo

11
Las principales características de este modelo se señalan a continuación.

• Reduce el riesgo de construir productos que no satisfagan las necesida des de los usuarios.

• Reduce costos y aumenta la probabilidad de éxito.

• Exige disponer de las herramientas adecuad as para la elaboración de los prototipos.

• Incremen ta los riesgos de calidad y robustez en los diseños.

12
Principales ventajas de esta aproximación son las que se listan enseguida.

• Un prototipo es una buena forma de facilitar la comunica ción con el usuario final.

• El cliente se va familiarizan do con el nuevo producto.

• Se pueden desarrollar prototipos tanto de interfaz de usuario como de como de rendimiento.

Las desventajas más relevantes del modelo de procesos por prototip os son las que se listan a

continuación.

• La gestión de desarrollo puede hacerse lenta ya que se pueden hacer demasia das

iteracion es hacer que el usuario final este de acuerdo con el prototipo o se

pongan límites.

• Imposibilid ad de conocer a priori el tiempo de desarrollo.

• Dificultad para manejar las expectativas del usuario ya que la presentar una versión no

funcional o parcialm en te funcional al usuario final este puede subestimar el proceso de

desarrollo que debe realizarse para la construcción de un producto con la calidad

esperada.

13
 1.3. Modelo de procesos en espiral

Comunicación

Inicio

Modelado
Entrega

Figura 4. Modelo de procesos en espiral

14
La Figura 4. Modelo de procesos en espiral se basa en el flujo de procesos evolutivo e incluye

además la generación de prototipos en cada iteración . En este modelo, “el software se

desarrolla en una serie de entregas evolutivas. Durante las primeras iteracion es, lo que se

entrega puede ser un modelo o prototip o. En las iteracion es posteriores se producen versiones

cada vez más completas del sistema” (Pressman , 2010, 39). Las características principales de

este modelo son las siguientes.

• Cada ciclo empieza identifican d o los objetivos de la porción correspon diente, las

alternativas de solución y las restricciones que permitan definir un alcance detallado.

• Se formula una estrategia efectiva para resolver las fuentes de riesgos

(simulación , prototipado, etc.).

• Se plantea el próximo prototipo.

• Una vez resueltos los riesgos se sigue el ciclo en cascada.

• Cada ciclo se completa con una revisión que incluye todo el ciclo anterior

y el plan para el siguiente.

Las principales ventajas de este modelo son las siguientes.

• No necesita una definición completa de los requisitos para empezar a

implem en tar una iteración.

• Con la inclusión de los prototipos, desde la primera iteración se

empiezan a validar los requerimientos.

15
 • Solo se pone el riesgo el tiempo y recursos invertidos en generar cada iteración.

• Al verificar poder identificar los problem as más rápidam en te se reduce los riesgos y se

facilita el resolverlo s a tiempo.

• Toma las ventajas de los modelos de procesos anteriores.

Las desventajas de aplicar este modelo son las siguientes.

• El cliente debe participar constantem en te y esto puede generar

inconvenientes en la organización.

• La gestión de proyectos con este tipo de modelos es bastan te compleja por lo que

requiere de gestores experimentados para garantizar el éxito del proyecto.

16
Como se puede observar, cada uno de los modelos expuestos tiene sus particu larida des, sus

ventajas y sus desventajas; las cuales se harán más eviden tes de acuerdo con las

características del proyecto a desarrollar. Por esta razón, es muy importan te que el ingeniero

de software tenga clara las alternativas que puede utilizar y use su criterio para definir el mejor

modelo a aplicar, de acuerdo con las circunstan cias de cada proyecto. Si lo requiere, que se

atreva a diseñar su propio modelo de acuerdo con las necesidades.

2. Habilida des Blandas de un Ingeniero de software

Como se ve, en la primera parte del módulo el desarrollo del proceso de software, o

proceso de desarrollo de software, es bastan te complejo. Se hace aún más complejo

de acuerdo con la complejid ad del proyecto a desarrollar. Por esta razón, creo que

este es un buen momen to para poner la atención en las personas que ejecutan el

proceso. Es decir, en los ingenieros de software. Como también se verá, en el proceso

de software intervien en diversos roles con competen cias técnicas claramente

definidas. Sin embargo, en este momento lo invito a considerar cuáles son las

habilida des blandas que tiene que desarrollar un ingeniero de software para

desempeñ arse exitosam en te. Además, se empieza a aplicar en el desarrollo del

proyecto.

De acuerdo con González (2010), las siguientes son las habilidades más importan tes que debe

desarrollar un ingeniero de software:

• Búsqueda y clasificación de información: no solamente se habla de las competencias

técnicas de gestión de información estructurada, sino también de la capacida d de

17
 reconocer

la información que es relevante en otros dominios más allá de la ingeniería del software.

Generalmente, siempre que se construye un software nos enfrentamos a la necesida d de

identificar lo que es relevante en su dominio de aplicación para poder construir una

solución que se haga cargo de las necesida des de ese dominio. Es decir, por ejemplo, si

vamos a construir un software que apoye los procesos contables de una organización ,

necesitaremos tener la habilid ad de aprender del dominio de la contabilidad.

• Capacidad de análisis: consiste en la capacidad de identificar los elementos que

componen un sistema hasta llegar a reconocer sus atributos y las relacion es que existen

entre ellos.

• Deducir, sintetizar, interpretar, analizar los fenómenos que observamos. Esta habilidad es muy

importan te a la hora de modelar y proponer solucion es a través de los diseños

propuestos.

18
• Habilidades comunicativas: una de las actividades básicas del proceso de ingeniería de

software es la comunicación , ya que a través de esta podemos entender las

necesidades de los clientes y los demás particip an tes en el desarrollo del software y

ofrecer nuestras propuestas de solución garantizan d o que nos hacemos entender. Sólo a

través de nuestras habilida des de comunicación podemos además coordin ar las

accion es requeridas para poder ejecutar el proceso de software. Por esta razón no

deberíam os subestimar nuestras habilidad es de: escuchar, leer, hablar y escribir además

de la comunicación no verbal. Es mi experien cia personal he visto fracasar proyectos de

software porque el ingeniero prefiere inferir sólo en su escritorio las necesidades de los

clientes en una postura un poco arrogante antes que escuchar y sostener

conversacion es con los clientes o usuarios.

• Redacción de informes y documentos: una habilidad comunicativa específica es la

redacción de informes y documentos, como lo mencionaba anteriormente, una

parte fundamental del software son los documen tos que lo describen, el ingeniero de

software debe estar en capacid ad de comunicar a través de informes y documen tos

cómo está integrado y compu esto el software y cómo se ha desarrollado el proceso de

construcción, teniendo en cuenta las competen cias técnicas e intereses de los distintos

públicos interesados en el software. No es lo mismo escribir un documento técnico

dirigido a otro ingeniero que escribir un informe dirigido al patrocin ador del proyecto o

un manual de funcionamien to dirigido al usuario final, la información , el nivel de detalle

y la forma de comunicación varían de uno a otro.

• Habilidades de creatividad: el ingeniero de software está llamado a proponer ideas y

enfoques con cierto grado de originalid ad, amplian do las miradas más allá de los
19
 espacios habitu ales y vislumbrar espacios de oportunid ad para generar posibles

cambios.

• Sensibilidad frente a los problemas del cliente: en algunas ocasiones vemos a las personas

adaptán d ose con dificultad al diseño de un software en lugar de que el software se

diseñe pensan do en las necesida des del cliente. Sin embarg o, los clientes de software

son cada vez más exigentes y si el ingeniero no es sensible a las necesida des de los

clientes para diseñar un software que se adapte a estas necesidades e incluso exceda sus

expectativas seguramente será un producto destinado a fracasar.

• Liderazgo: es la capacida d de influir en la forma de actuar de los integran tes de un

grupo de trabajo, logran do que este equipo se manten ga motivado y trabaje con

entusiasmo enfocado en lograr los objetivos propuestos.

• Toma de decisiones: durante el proceso de ingeniería de software nos encontramos

constantemente con la necesidad de elegir entre varias alternativas, cada una con

ventajas, desventajas y riesgos asociados, esta capacidad tiene que ver con elegir

una alternativa y comprometerse con esta posición gestionando la

incertidumbre.

• Gestión de conflictos: durante el proceso de ingeniería de software es común que se

presenten diferencias de opiniones que pueden convertirse en conflictos, con la

gestión de conflictos buscamos que comprender e intervenir en la resolución

pacífica no violenta de los conflictos.

20
• Trabajo en equipo: los equipos de desarrollo de software cada vez son más variados y

complejos y el éxito del proyecto depende en gran medida de la capacid ad de sus

integran tes para trabajar efectivamente en equipo. Esta más que una habilidad, es un

conjunto de habilid ades que promu even que cada integrante conoce su papel en el

equipo y se responsabiliza de cumplirlo coordin an do efectivamente las accion es

requeridas para el logro de los objetivos.

21
 Referencias

González-Morales, D., Moreno de Antonio, L. M. y Roda García, J. L. (2011). Teaching “soft”

skills in Software Engineering. En la conferencia IEEE Global Engineering Education Conferen ce

(EDUCON), Amman, Jordania. (pp. 630-637)

Pressman , R. (2010). Ingeniería del software. Un enfoque práctico. (pp. 26.55) México, D.F,

México: McGraw Hill

22
23