Creación de software: ¿cómo evaluar su diseño y ser más productivo?

La evaluación y el cálculo de costes del diseño de software, en particular el tamaño, el esfuerzo, el coste y el tiempo implicados, suele ser fuente de animados debates por parte de los evaluadores de software. Los jefes de proyecto suelen ser los responsables de esta actividad.

El desarrollo de software implica una serie de actividades que requieren conocimientos especializados, sobre todo en los siguientes ámbitosSe trata de la recopilación, el análisis y la gestión de requisitos; el diseño, la codificación y la verificación y validación independientes (IV&V) del software; la implementación, el despliegue, la instalación y la puesta en marcha. Cada una de estas actividades es llevada a cabo por una persona cualificada, que utiliza diversas herramientas de distintos grados de complejidad.

Ver todos los software Editor de software

¿Qué es la productividad? Definición

La productividad se define como la tasa de producción para unos insumos dados. La productividad se expresa como "tantas unidades de producción por día" o "tantas unidades de producción por hora". La productividad también se define como la relación entre las entradas y las salidas.

En el contexto de este artículo, la productividad se refiere a la tasa de producción de una unidad de salida utilizando un conjunto de entradas, durante un período de tiempo determinado.

Problemas para evaluar el tamaño del software

En la industria informática actual, existen varias unidades para medir el tamaño de un programa informático. Estas unidades incluyen, por ejemplo, puntos de función, puntos de caso de uso (UCP), puntos de objeto, puntos de funcionalidad, puntos de Internet, puntos de prueba, análisis de puntos de función (FPA), líneas de código (LOC), etc. No existe una medida establecida para convertir el tamaño del software en ninguna de estas unidades.

Curiosamente, en estas mediciones, el tamaño del software se ajusta (aumenta o disminuye) en función de factores como la complejidad. Sin embargo, el tamaño es un carácter inmutable. Por ejemplo, un kilo de queso no pesa más o menos si la persona que lo pesa tiene más o menos experiencia en el pesaje, o si la balanza es mecánica o electrónica. Pongamos otro ejemplo: un kilómetro sigue siendo un kilómetro, tanto si es una persona joven como si es una persona mayor la que recorre esa distancia, o si la distancia se mide en una autopista o en una calle concurrida.

Sin embargo, cambia la velocidad a la que se obtienen los resultados. Si tomamos los ejemplos anteriores, la persona mayor recorrerá sin duda el kilómetro más despacio que la joven. Es más, el kilómetro se recorre más rápidamente en autopista que en ciudad.

Además, no hay acuerdo sobre cómo contar las LOC. ¿Hay que contar las proposiciones lógicas o físicas? ¿Y cómo tratar la documentación en línea? ¿Hay que tenerla en cuenta o no?

Estos son algunos de los principales problemas asociados a la evaluación del tamaño de un programa informático.

Preocupación por la productividad

El sector de la edición de programas informáticos está obsesionado con la posibilidad de establecer un índice de productividad único y empírico que abarque todas las actividades.

Se ha intentado definir la productividad como 10 horas-persona por punto de función, mientras que preLa unidad persona-hora por punto de función puede variar de 2 a 135 en función del tamaño del producto, el equipo y otros factores. "Definir la productividad" significa asignar una cifra que represente el esfuerzo necesario, expresado en horas-persona, para desarrollar una unidad de tamaño de software, de modo que el tamaño del software (en puntos de función) pueda convertirse en esfuerzo de desarrollo (en horas-persona). A veces se eligen intervalos, por ejemplo de quince a treinta horas por PCU. Otras veces, se crean fórmulas empíricas a partir de un conjunto de factores, como en el caso del "modelo de costes constructivos" (COCOMO).

El problema de estas medidas de productividad es que combinan todas las actividades -análisis de requisitos, diseño, revisión, pruebas, etc.- en una única medida. - en una única medida. Sin embargo, las competencias necesarias para estas tareas son diferentes, al igual que las herramientas utilizadas y las entradas y salidas. Agruparlas bajo el epígrafe de "desarrollo de software" y dar una medida única de productividad sólo puede proporcionar una estimación muy aproximada, y nunca exacta.

Diseñar software mejor y más rápido: ¿cómo ser más productivo?

El desarrollo de software implica las siguientes actividades

• Actividades de preparación del proyecto, como estudios de viabilidad, presupuesto financiero y validación del proyecto (aprobación financiera y técnica, y "lanzamiento del proyecto").
• actividades de lanzamiento del proyecto, como la identificación del gestor del proyecto, la creación de un equipo de proyecto y la configuración del entorno de desarrollo planificación del proyecto; establecimiento de diversos protocolos, como acuerdos de nivel de servicio y procedimientos de información sobre los avances; formación sobre el proyecto
• actividades de ingeniería de software, como análisis de requisitos de usuario, análisis de requisitos de software, diseño de software, codificación y pruebas unitariasdiferentes tipos de pruebas de integración, funcionales, negativas, de sistema y de aceptación; preparación de documentación
• actividades de despliegue, incluida la instalación de hardware y sistemas; creación de bases de datos; instalación de software de aplicacióninstalación del software de aplicación; pruebas piloto; formación de usuarios; fase paralela y despliegue real
• actividades de cierre del proyecto, incluida la documentación de buenas y malas prácticas; análisis del proyecto (fin del proyecto); archivo de expedientes; publicación de recursos; liberación del gestor del proyecto de sus obligaciones; inicio del mantenimiento del software.

Cuando hablamos de las "reglas básicas" del sector (procedimientos aceptados y de sentido común) en materia de productividad, resulta difícil determinar qué actividades se incluyen en el índice de productividad. Nadie apostaría por medir la productividad, aunque sea una norma básica del sector.

Veamos la naturaleza de estas actividades:

1. Análisis de requisitos: comprender y documentar lo que el usuario necesita, desea y espera para que los diseñadores de software comprendan plenamente y puedan diseñar un sistema en estricta conformidad con los requisitos establecidos. La dependencia de factores externos es elevada.
2. Diseño de software: considerar las diferentes opciones disponibles para el hardware, el software del sistema y la plataforma de desarrollo; llegar a la elección óptima para cada uno; diseñar una arquitectura que cumpla los requisitos establecidos y las expectativas del cliente. La arquitectura debe ser compatible con las tecnologías actuales y el diseño debe documentarse de forma que los programadores lo entiendan y entreguen un producto que cumpla las especificaciones originales del usuario. Existen varias alternativas y, dado que el diseño de software es una actividad importante y estratégica, los errores pueden tener graves consecuencias.
3. Codificación: desarrollo de código de software que se ajuste al diseño y contenga el menor número de errores posible (es muy fácil dejar errores sin querer).
4. Revisión del código: estudiar el código escrito por otro programador, descifrar su funcionalidad e intentar predecir los errores que el cliente podría encontrar al utilizar el software.
5. Pruebas: intentar descubrir cualquier fallo que pueda quedar en el software. Sin embargo, es imposible encontrar casi todos los defectos. Es más, probar el software en su totalidad es una actividad poco práctica.

Como la naturaleza de estas actividades es tan diferente, es obvio que la productividad de cada una de ellas no es uniforme (y, por tanto, no puede describirse con la misma cifra). El ritmo de trabajo difiere para cada una de estas actividades.

No dependen de la cantidad de código producido, sino de otros factores, como :

1. los requisitos, que dependen de la eficacia y claridad de su fuente (usuarios o documentación)
2. el diseño, que depende de la complejidad del proceso, las alternativas disponibles y las restricciones bajo las que debe diseñarse la funcionalidad
3. la revisión del código, que depende del estilo de codificación
4. la comprobación, que depende de cómo esté escrito el código (cuantos más errores haya, más tiempo se necesitará para probar y volver a probar)
5. la propia codificación, que depende de la calidad del diseño.

En consecuencia, debemos establecer cifras de productividad diferentes para cada una de estas actividades.

Intentemos establecer un paralelismo para la industria, por ejemplo con la perforación. Las actividades que hay que realizar son: 1) preparar la máquina; 2) preparar las herramientas; 3) cargar el trabajo; 4) perforar el agujero; 5) desbarbar el agujero; 6) limpiar; 7) entregar la chapa para la siguiente operación.

Si se perforan varios agujeros, el tiempo "por agujero" disminuye, porque las actividades de configuración son actividades puntuales.

Por lo tanto, si consideramos la codificación de una unidad, por ejemplo, las actividades a realizar podrían ser: 1) recibir las instrucciones; 2) estudiar el documento de diseño; 3) codificar la unidad; 4) probar y depurar la unidad para la funcionalidad específica; 5) probar y depurar la unidad para cualquier uso; 6) probar y depurar la unidad para cualquier uso; 7) probar y depurar la unidad para cualquier uso.6) eliminar el código innecesario de la unidad; 7) realizar pruebas de regresión de la unidad; 8) transferir la unidad a la etapa siguiente.

Del mismo modo, podemos proponer microactividades para cada fase de desarrollo de software.

Cifras de productividad: ¿empíricas o basadas en un estudio metódico?

Cada una de las actividades anteriores tiene un porcentaje de éxito diferente. Es necesario establecer tiempos estándar para cada una de estas actividades. Una vez hecho esto, deben utilizarse técnicas de estudio del trabajo, como la estimación sintética o analítica, para estimar la duración total del encargo.

Tanto si se utilizan técnicas de estudio del tiempo para realizar estudios de productividad individuales como para recopilar datos empíricos, el desarrollo de software no es ni totalmente mecánico ni totalmente creativo. Tampoco es realista planificar actividades con un fuerte componente creativo; los métodos de estudio del trabajo tienen en cuenta este aspecto del desarrollo de software. Se está investigando mucho sobre la "productividad ejecutiva", y quizá en el futuro se disponga de métodos para "cronometrar" la productividad en el desarrollo de software. Por el momento, los datos empíricos parecen ser la solución elegida.

¿Dónde se obtienen los datos empíricos? La primera opción son los estudios sobre plazos de entrega que utilizan técnicas de ingeniería industrial. La otra forma, más fácil y fiable, es basarse en los datos históricos que proporcionan las hojas de tiempos.

La mayoría de los programas informáticos de gestión del tiempo que utiliza la industria están orientados a las nóminas y la facturación. No recogen datos al nivel más bajo para establecer tendencias de productividad. La mayoría de estos programas registran dos o tres niveles de datos, además de la fecha y la hora. Un proyecto siempre se registra en el primer nivel, y el segundo y el tercero pueden estar ocupados por un módulo y un componente, un componente y una actividad, o una combinación similar. Además de la fecha y hora de presencia del empleado, las hojas de presencia deben registrar cinco niveles de datos: el proyecto, el módulo, el componente, la fase de desarrollo y la tarea realizada. De este modo, se dispondría de datos para establecer medidas de productividad de forma empírica y realista.

Actualmente, las actividades de desarrollo de software se centran en la macroproductividad. Es necesario cambiar esta tendencia y pasar de la macroproductividad a la microproductividad. Para ello, tenemos que cambiar nuestro software de control horario y la profundidad de los datos que recopilamos.

Estudiar la productividad a nivel micro tiene las siguientes ventajas:

• Mejor previsibilidad del desarrollo de software
• Estimaciones de mejor calidad para mejorar la fijación de precios durante las fases de desarrollo y finalización del proyecto
• Establecimiento de objetivos más precisos a la hora de asignar tareas, lo que aumenta la confianza de los editores de software
• Estimaciones de costes más precisas

Ver todos los software Editor de software

Conclusión

Es importante entender la diferencia entre los términos productividad y capacidad. La productividad es la tasa de éxito de una microactividad; la capacidad es la tasa de éxito de una instalación (fábrica, organización, etc.), y en el diagrama de capacidad se incluyen varias actividades. A efectos de evaluación del software, hay que pasar de la macroproductividad (capacidad) a la productividad (de la microactividad). Se prefiere la recopilación de datos empíricos para obtener medidas de productividad de las distintas actividades de desarrollo de software, ya que las técnicas de estudio de tiempos y tareas no pueden ofrecer una imagen completa de la productividad.Se prefiere la recogida de datos empíricos para obtener medidas de productividad de las distintas actividades de desarrollo de software, ya que las técnicas de estudio de plazos y tareas no pueden ofrecer resultados satisfactorios cuando la misión presenta un alto grado de creatividad (como es el caso de la edición de software). Para recopilar datos empíricos, es necesario mejorar los programas informáticos de registro del tiempo. Recomendamos este procedimiento para calcular las cifras de productividad en todos los microniveles.

Sobre los autores

Murali Chemuturi es experto en ingeniería industrial en la Institución India de Ingeniería Industrial. Ha pasado más de treinta años en organizaciones profesionales, como ECIL, TCS, Metamor y Satyam. Trabajó primero en la industria manufacturera y luego en TI. Actualmente dirige Chemuturi Consultants y tiene especial interés en el software para la industria de desarrollo de software. Ha dirigido varios programas de formación en empresas sobre gestión de proyectos de software y evaluación de software.

Sarada Kaligotla ha cursado un máster en aplicaciones informáticas y es Profesional de Gestión de Proyectos (PMP) por el Project Management Institute (PMI) y Analista Certificada de Calidad de Software (CSQA) por el Quality Assurance Institute (QAI). Actualmente trabaja para Blue Cross Blue Shield en Massachusetts. Sarada tiene seis años de experiencia en la industria del software, así como en gestión de proyectos y desarrollo.