Directriz: Discriminadores del proceso
En esta directriz se describen los factores que afectan a la forma en que se personaliza un proceso para un proyecto.
Relaciones
Descripción principal

Visión general

Sobre el proceso de desarrollo de software influyen los factores siguientes:

  • Factores de dominio como el dominio de la aplicación, el proceso empresarial al que hay que dar soporte, la comunidad de usuarios y las ofertas disponibles de los competidores.
  • Factores del ciclo vital como el plazo de comercialización, la vida prevista para ese software y los releases futuros planificados.
  • Factores técnicos como el lenguaje de programación, las herramientas de desarrollo, la base de datos, las infraestructuras de componentes y los sistemas de software existentes.
  • Factores de la empresa.

Estos factores no tienen todos la misma importancia. En las secciones siguientes se describen algunos de los factores principales, los que tendrán un efecto más probable sobre la forma global del proceso de desarrollo, y la manera en que se implementarán el proceso y las herramientas en la empresa de desarrollo.

El contexto empresarial describe el contexto en el que se desarrolla el software.  Existen distintos tipos de contextos empresariales que afectan a la forma en que se puede personalizar mejor el proceso. A continuación, se proporcionan ejemplos de contextos empresariales:

  • Trabajo contratado en el que el desarrollador produce software para una especificación del cliente determinado y sólo para él.
  • Desarrollo especulativo o comercial en el que el desarrollador produce el software y carga con el coste de su comercialización.
  • Proyecto internos en los que el cliente y el desarrollador se encuentran en la misma empresa.

Hay muchas situaciones intermedias; por ejemplo, aquéllas en las que sólo se subcontrata parte del desarrollo del software, aquéllas en las que la dispersión geográfica es un factor adicional, etc. El número total de interesados distintos es un buen indicador del contexto empresarial.

El contexto empresarial afecta al nivel de ceremonia, al nivel de formalidad y la rigidez del proceso. Cuantos más interesados (compradores, subcontratistas, cuerpos reguladores, etc.) estén implicados, más fácil será que el proyecto produzca evidencias formales, como documentos, informes y prototipos, para los principales objetivos del proyecto.

El tamaño del esfuerzo de desarrollo de software

El tamaño del esfuerzo de desarrollo de software según han definido algunas métricas, como las líneas de código fuente (SLOC), las instrucciones de código fuente entregado o los puntos de funciones, el número de personas y meses o sencillamente el coste.

El tamaño del esfuerzo afectará al nivel de la ceremonia, al nivel de formalidad a la rigidez del proceso. Cuanto más grande sea el proyecto, más grande será el equipo de desarrollo y, con independencia del contexto empresarial, más formalidad y visibilidad deberán tener los distintos equipos y responsables respecto a los requisitos, las interfaces y los indicadores de progreso. Las cuestiones de comunicación de los proyectos de gran tamaño se agravan aún más en los equipos dispersados geográficamente.

El grado de novedad se basa en los precedentes de este esfuerzo de software relativos a la empresa de desarrollo y, en particular, en si el desarrollo se encuentra en un segundo ciclo o en un ciclo subsiguiente. Esto incluye la madurez de la empresa y de su proceso, sus activos, su conjunto de habilidades actual y cuestiones como el ensamblaje y la formación de un equipo, la adquisición de herramientas y otros recursos.

El grado de novedad de un proyecto afecta al proceso de una forma totalmente distinta. Un nuevo proyecto, el primero de este tipo, afecta de forma significativa a la configuración dinámica: las fases inicial y de elaboración serán más largas, y pueden extenderse durante varias iteraciones. Asimismo se dedicará más énfasis a obtener y capturar requisitos, a modelar los guiones de uso, a la arquitectura y a mitigar el riesgo. Para un proyecto que es un ciclo en la evolución a partir de un sistema anterior, la gestión de cambios es más importante y la incorporación del código heredado implica algunos retos tecnológicos.

La novedad no es sólo relativa al sistema que se está desarrollando, sino que también se refiere a la madurez de las empresas que se encargan puesto que la introducción de nuevas técnicas o herramientas afecta al proceso. En particular, la introducción del propio Rational Unified Process (RUP) en una empresa debe realizarse escalonadamente en pasos cuidadosos. Una empresa seguirá presentando cierta inercia antes la adopción de un nuevo proceso y la estrategia de adopción debe intentar una transición suave entre las prácticas existentes y las nuevas.

Tipo de aplicación

Existen distintos tipos de aplicaciones, por ejemplo, los sistemas de tiempo real incorporado, los sistemas de información distribuida, los sistemas de telecomunicaciones, las herramientas CASE (ingeniería de software asistida por ordenador), etc. El tipo de aplicación afectará al proceso, especialmente con respecto a las restricciones específicas que puede imponer el dominio sobre el desarrollo, como la seguridad, el rendimiento, la internacionalización, las restricciones de memoria, etc.

El tipo de aplicación puede afectar al proceso si la aplicación es clave para la misión; por ejemplo, el sistema de control de vuelo de un avión. Un sistema clave para la misión precisa un nivel más alto de ceremonia en general, tanto para el rastreo de los requisitos como para garantizar la calidad del producto. Una aplicación clave para la misión también precisa que se empleen más recursos en las pruebas.

El tipo de desarrollo, o el dominio de destino, suscitan cuestiones de proceso como las siguientes:

  • Técnicas y herramientas para dar soporte a tareas específicas; por ejemplo la generación automática de código para máquinas con un estado finito.
  • Procedimientos de certificación; por ejemplo, para la instrumentación médica.
  • Compatibilidad con los estándares; por ejemplo para cuestiones fiscales o de contabilidad y para los equipos de telecomunicaciones.

Tipo de desarrollo

Hay varios tipos de desarrollo, entre otros:

  • Trabajo contratado, en el que se desarrolla un producto para un cliente determinado. Tiene más interesados que gestionar y con los que negociar cuando lleva a cabo un trabajo contratado. Suelen ser necesarios más productos externos, formales, porque los clientes, o sus representantes, desean supervisar los progresos y mantenerse informados. Asegúrese de que los productos de trabajo que revise el cliente sean fáciles de entender. A veces, existe la necesidad de marcarse un objetivo a partir del cual, el proyecto puede ofrecer un precio fijo sobre el resto del proyecto. En tal caso, puede precisar un nuevo objetivo o ajustar los existentes. En otros casos, es posible que deba ajustarse al modelo de ciclo vital que esté utilizando el cliente con otros objetivos y fases.
  • Desarrollo especulativo, en el que se desarrolla un producto para su comercialización masiva. En el desarrollo especulativo, es un gestor de marketing (de producto) de la propia empresa el que actúa como cliente. En este tipo de desarrollo, los plazos de comercialización suelen ser más importantes que la funcionalidad y se precisan menos revisiones formales.
  • Desarrollo interno, en el que se desarrolla un producto que se entrega a otro departamento de la empresa. Es posible que deba ajustarse a otro modelo de ciclo vital si va a realizar entregas a un proyecto que no utilice RUP. Puede ser más técnico cuando describa los productos de trabajo porque la mayoría de productos de trabajo los revisarán compañeros.
  • Estudios previos, en los que no se suele desarrollar un producto. La finalidad de un proyecto de estudio previo es descubrir si el posible construir un producto. Un proyecto de estudio previo no tiene los mismos objetivos que un proyecto habitual.

El proceso de desarrollo actual

En la mayoría de los casos, no se sustituye el proceso de desarrollo de software que está en vigor actualmente en la empresa porque, en la mayoría de los casos, va a implementar el nuevo proceso de desarrollo paso a paso, centrándose primero en las áreas más críticas y de mayor importancia. Una parte del proceso de desarrollo de software actual puede continuar existiendo durante un cierto tiempo, incluso de forma permanente.

Problemas y motivos de raíz

Los problemas que se identifican y priorizan para el proyecto tienen influencia en aquellas áreas del proceso en las que se concentra al principio del proceso de implementación. Es importante tener en cuenta que, si no hay una forma establecida de trabajar en la empresa, puede tener muy poco sentido buscar los problemas. Consulte el apartado Concepto: Implementación de un proceso en un proyecto. Por el contrario, debe identificar los motivos de raíz de los problemas. Para eliminar los problemas, debe atajar los motivos de raíz mejorando el proceso, introduciendo herramientas para automatizar los procesos y formando personal.  

Ejemplos de problemas comunes

A continuación, se incluyen algunos ejemplos de algunos problemas comunes:

  • Incapacidad para gestionar el ámbito; habitualmente, la empresa intenta hacer más de lo que terminan haciendo.
  • Incapacidad para capturar los requisitos; tienen dificultades para especificar los requisitos.
  • Incapacidad para gestionar de cambios de requisitos.
  • Incapacidad para gestionar los requisitos; los requisitos no llegan al producto final.
  • Incapacidad para realizar cálculos; suelen ser demasiado optimistas acerca de su capacidad para entregar de acuerdo con la planificación.
  • Defecto de diseño; cumplen adecuadamente los requisitos, pero no realizan buenos diseños de sistemas. ¿Qué tipo de problemas de diseño tienen? ¿Son los sistemas difíciles de mantener y mejorar? ¿Tienen problemas de rendimiento, problemas de utilización, problemas de capacidad, etc.?
  • Incapacidad para producir productos de calidad; el producto tiene demasiados defectos que pueden deberse a la falta de pruebas, pero suele estar relacionado con la incapacidad para capturar y gestionar requisitos, así como a deficiencias de diseño.
  • Rendimiento del software inaceptable.
  • Baja utilización.
  • Conflicto entre desarrolladores; existe falta de control respecto a la propiedad y la gestión de la configuración, de forma que los desarrolladores realizan cambios que entran en conflicto y el trabajo se pierde.
  • Descubrimiento tardío de los problemas. 
  • Problemas al pasar de los guiones de uso al diseño.
Ejemplos de motivos de raíz

Un problema suele ser un síntoma de que algo no es correcto. Deben identificarse los motivos de raíz de los problemas. A continuación, se incluyen algunos ejemplos de algunos motivos de raíz comunes:  

  • Gestión insuficiente de requisitos
  • Comunicaciones ambiguas e imprecisas
  • Arquitectura frágil
  • Complejidad abrumadora
  • Incoherencias que no se detectan entre los requisitos, los diseños y las implementaciones.
  • Pruebas insuficientes
  • Valoración subjetiva del estado del proyecto
  • Reducción del riesgo postergada debido al desarrollo de cascada
  • Propagación de cambios sin control
  • Automatización insuficiente
  • Ninguna forma sistemática de construir interfaces de usuario
  • Ninguna forma establecida para ir de los guiones de uso a un diseño

Factores de la empresa

La implementación del proceso en una empresa, depende de factores propios de la empresa como su capacidad para el cambio, su estructura organizativa, su cultura en los ámbitos de gestión y organización del proyecto, sus competencias y habilidades disponibles, su experiencia previa y sus actitudes actuales.

Los factores de la empresa también afectan a la forma en que se configura el proceso. Por ejemplo, si el personal de la empresa ha utilizado anteriormente una descripción de procesos de desarrollo de software, entonces será más fácil empezar a utilizar RUP. Por otra parte, si el personal no ha utilizado nunca una descripción de procesos de desarrollo de software, puede decidir la limitación del ámbito de la descripción del proceso. También puede asignar un esfuerzo suplementario en hacer la descripción sea más fácil de comprender y de utilizar, asegurándose de que incluya (o haga referencia) a la información que proporcionará un valor mayor.

Si algunas áreas son nuevas para la mayoría del personal, el desarrollo de las mejores directrices posibles facilitará la transición. Por ejemplo, si el lenguaje de programación es nuevo para la mayoría del personal, debe tener unas directrices de programación y de diseño que sean muy buenas para ayudar a su aprendizaje.

Actitudes

Las actitudes negativas entre el personal de una empresa ante el cambio a una tecnología nueva, un proceso nuevo o unas herramientas nuevas es posiblemente la mayor amenaza respecto a una implementación satisfactoria del proceso y de las herramientas. Un exceso de entusiasmo hacia el proceso también puede ser un problema, porque puede provocar que el personal se centre en exceso en el proceso.

Para valorar las actitudes del personal respecto a la nueva tecnología, los nuevos procesos y herramientas, haga preguntas como las siguientes:

  • ¿Qué ventajas aprecia en la nueva tecnología? ¿Cree que esta nueva tecnología resolverá alguno de los problemas actuales? ¿Qué problemas aprecia en la nueva tecnología?
  • ¿Qué ventajas aprecia en el nuevo proceso? ¿Cree que este nuevo proceso resolverá alguno de los problemas actuales? ¿Qué problemas aprecia en el nuevo proceso?
  • ¿Qué ventajas aprecia en las nuevas herramientas? ¿Cree que estas nuevas herramientas resolverás alguno de los problemas actuales? ¿Qué problemas aprecia en las nuevas herramientas?

Para valorar la motivación del personal, busque respuestas a preguntas como las siguientes:

  • ¿Ven todos los miembros de la empresa la razón por la que se necesita un cambio?
  • ¿Son todos conscientes de lo que la competencia está haciendo y en cómo eso afecta a la empresa?
  • ¿Son todos conscientes de los cambios tecnológicos en el sector y de cómo afectan a la empresa?  

Entre los signos de una actitud negativa se encuentran afirmaciones como las siguientes:

  • "El proceso no ayuda, es un obstáculo."
  • "El proceso implica la producción de muchos documentos."
  • "El proceso es abrumador."

Algunas formas de abordar las actitudes negativas son las siguientes:

  • Motivar al personal apuntando a los problemas actuales.
  • Explicar que un proceso no dicta lo que se debe hacer. El proceso debe verse fundamentalmente como un "sistema de ayuda", en el que se consultan las guías, definiciones, etc.
  • Explicar que sólo se utilizan algunas partes pequeñas del proceso. Nadie llega a dominar la totalidad del proceso, y este no es el objetivo, en todo caso. Comparar el proceso con un estante de libros que va leyendo a medida que necesita información.
  • Ejecutar un proyecto piloto satisfactorio en el que muestre que el nuevo proceso y las nuevas herramientas funcionan. Incluir a uno o dos de los escépticos en el proyecto piloto.  

Algunos signos de un entusiasmo excesivo son los siguientes:

  • El personal confía totalmente en el proceso, hasta el punto que creen que resolverá todos sus problemas.
  • El proceso es la bala de plata o la fórmula mágica que, si lo seguimos, nos garantiza el éxito.
  • El equipo del proyecto desea emplear mucho tiempo y esfuerzo personalizando el proceso sin antes valorar los problemas relacionados con el proceso que precisan una solución.  

Algunas formas de abordar el exceso de entusiasmo son las siguientes:

  • Establezca expectativas. El proceso será de ayuda, pero no resuelve los problemas. Son las personas las que resuelven los problemas.
  • Convenza al personal para que no empleen demasiado tiempo en la personalización del proceso.
  • Haga que el personal se centre en el desarrollo de los producto de software.

Los distintos tipos de sistemas y sus proyectos pueden clasificarse en términos de la complejidad técnica del sistema y la complejidad de gestión. En la figura siguiente se ilustra un concepto de cómo pueden clasificarse los distintos sistemas. Por ejemplo, un pequeña aplicación de hojas de cálculo típica suele tener muy poca complejidad técnica y es fácil de gestionar. En el otro extremo encontramos un proyecto típico de Weapon Systems, que suele ser complejo técnicamente y complejo de gestionar.

Normalmente al aumentar el tamaño del sistema, la duración del proyecto o el contexto empresarial también aumenta la complejidad de gestión. El aumento de la novedad, en el dominio del problema o en el espacio de la solución, aumenta la complejidad técnica. Existe una interacción entre la complejidad de gestión y la complejidad técnica; muchos proyectos de gran tamaño son también técnicamente complejos. Esto tiene como resultado lo siguiente:

  • Una mayor complejidad de gestión que conduce a más ceremonia, incluidos más revisiones y objetivos formales y más productos de trabajo.
  • Una mayor complejidad técnica que conduce a la introducción de técnicas, roles y herramientas específicos y, por tanto, más tareas.

Diagrama descrito en el texto adjunto.

Los sistemas se clasifican en términos de complejidad técnica y complejidad de gestión.