"Rediseño del desarrollo de Software"
6. Dirección de Cambio
Entendemos por dirección de cambio un conjunto de ideas que establecen la diferencia entre lo actualmente existente y el rediseño propuesto. Las ideas de cambio se obtuvieron del patrón utilizado, el análisis de la situación actual y las directrices proporcionadas por las normas CMM. Las ideas de cambio que se presentan a continuación tienen relación con la Anticipación, Mantención consolidada de estado, Prácticas de trabajo, Coordinación y Apoyo computacional.
6.1. Anticipación
Esta idea de cambio significó incorporar las actividades de Planificación de Desarrollo del Producto (Planificación de Proyectos - Normas CMM) y Control y Seguimiento (Seguimiento y Control de Proyectos - Normas CMM), ambas orientada a establecer futuros requerimientos que deberá satisfacer el proceso y a crear las condiciones para atenderlos satisfactoriamente, lo cual es la esencia de la anticipación.
6.1.1. Planificación
Para la planificación se propone usar la métrica de puntos de función descrita en el punto 4.2 que permite determinar el esfuerzo necesario de un desarrollo de software.
Sin embargo, es necesario encontrar una relación entre los puntos de función que son calculados previos al desarrollo (en la etapa de definición de requerimientos) y el esfuerzo que se debe realizar para llevar a cabo el proyecto de software.
Es importante estimar el esfuerzo porque representa el tamaño del software, principal manejador de los costos involucrados en el desarrollo.
6.1.1.1. Relación PF y Esfuerzo
Existen diversas formas de relacionar los puntos de función con el esfuerzo, algunas de ellas son:
Se propone encontrar la relación PF v/s Esfuerzo usando como nexo las líneas de código, es decir, calcular los PF para estimar el número de líneas de código y usar este resultado para estimar el esfuerzo.
Esta forma de obtener la relación entre PF y esfuerzo se propone sólo hasta tener un registro con información histórica de los proyectos, de tal forma que en un futuro sea posible crear un modelo que se adapte a la realidad de la empresa.
LENGUAJE |
NIVEL |
LDC / PF |
C |
2.5 |
128 |
Decision Support Default |
9 |
36 |
Ansi Basic |
5 |
64 |
C++ |
6 |
53 |
Java |
6 |
53 |
SQL |
25 |
13 |
PL/I |
4 |
80 |
4th Generation Default |
16 |
20 |
Ansi Cobol 74 |
3 |
107 |
Visual 4.0 |
11.00 |
29 |
Visual Basic 1 |
7.00 |
46 |
Visual Basic 2 |
7.50 |
43 |
Visual Basic 3 |
8.00 |
40 |
Visual Basic 4 |
9.00 |
36 |
Visual Basic 5 |
11.00 |
29 |
Visual Basic DOS |
8.00 |
40 |
Visual C++ |
9.50 |
34 |
Basic Assembly |
1 |
320 |
Tabla 6-1: Líneas de Código - Puntos de Función 9
La tabla 6-1 [Jones96] proporciona estimaciones informales del número medio de líneas de código requerido para construir un punto de función en diferentes lenguajes y niveles de programación.
Debe tenerse en cuenta que el propio artículo de Jones señala que la cantidad y calidad de los datos disponibles no permiten asegurar que el margen de error sea reducido, y también que la tabla no ha sido actualizada desde 1996, por lo que los valores deben tomarse con cierta cautela.
El lenguaje de programación utilizado en Synapsis es el Visual Basic nivel 5, esto indicaría que una LDC de Visual Basic proporciona aproximadamente 4.4 veces más de "funcionalidad" que una LDC de C. Interpretaciones de este tipo se pueden hacer fácilmente, como también decir que existe una relación lineal entre el nivel de un determinado lenguaje y las LDC necesarias para lograr un punto de función. Lo que no significa que exista una correlación lineal entre el nivel de lenguaje y la productividad, ya que esta última varía en relación con el tamaño del proyecto.
La tabla 6-2 entrega la productividad promedio por persona durante un mes. Esta nos dice que para un lenguaje de nivel 5, una persona puede programar 10 a 20 puntos de función al mes. Teniendo como referencia este rango de valores de productividad por persona al mes se procede a realizar el cálculo de PF por mes ajustado a la realidad de la empresa, que por supuesto debe encontrarse entre 10 y 20 PF por persona al mes. El racionamiento es el siguiente:
La tabla 6-1 nos dice que para Visual Basic nivel 5: 1 LDC = 29 PF
En Synapsis se tienen LDC por persona-mes = 400 (20 PF por día)
Por lo tanto, a Synapsis se le calcula una productividad de:
PRODUCTIVIDAD = PF/P-M (1)
PRODUCTIVIDAD = 14
Lo que permite relacionar el esfuerzo (persona-mes) con los puntos de función de la siguiente forma: PF/P-M = 14 (2)
NIVEL DE LENGUAJE |
PRODUCTIVIDAD PROMEDIO (persona/mes) |
| 1 - 3 | 5 - 10 PF |
| 4 - 8 | 10 - 20 PF |
| 9 - 15 | 16 - 23 PF |
| 16 - 23 | 15 - 30 PF |
| 25 - 55 | 30 - 50 PF |
| Sobre 55 | 40 - 100 PF |
Tabla 6-2: Productividad - Nivel de Lenguaje10
6.1.1.2. Estimación de Esfuerzo y Costos
El cálculo del esfuerzo se hace utilizando la relación obtenida en el punto anterior. Se reemplaza en la ecuación (2) el valor de PF obtenida a partir de los requerimientos y de la forma detallada en el punto 4. De esta manera se encuentra el esfuerzo necesario para llevar a cabo el proyecto de software. Para estimar el esfuerzo en cada etapa del proyecto se calcula el porcentaje del esfuerzo que le corresponde a cada una de ellas. Las etapas son dividas según el modelo de cascada11 que es el utilizado en Synapsis y los porcentajes asignados se obtienen de la experiencia.
Como se dijo anteriormente el esfuerzo es el elemento principal para estimar los costos, por lo que para calcular el costo total del proyecto simplemente se multiplica el esfuerzo estimado por el costo de persona-mes.
Estas estimaciones podrán ser realizadas, en primera instancia, ejecutando una planilla Excel destinada a este fin. La primera hoja (Figura 6-1) muestra las tablas que definen la complejidad de las funciones y en la segunda (Figura 6-2) se ingresan las variables que permiten hacer las estimaciones de esfuerzo y costo del proyecto.
salidas externas |
|||
datos /archivos |
1 a 5 |
6 a 19 |
> 20 |
0 ó 1 |
s |
s |
m |
2 a 3 |
s |
m |
c |
> = 4 |
m |
c |
c |
consulta (salida) |
|||
datos / archivos |
1 a 5 |
6 a 19 |
> 20 |
0 ó 1 |
s |
s |
m |
2 a 3 |
s |
m |
c |
> = 4 |
m |
c |
c |
interfaces externas |
|||
archivos / datos |
1 a 19 |
20 a 50 |
> = 51 |
0 ó 1 |
s |
s |
m |
2 a 3 |
s |
m |
c |
> = 4 |
m |
c |
c |
complejidad de funciones |
|||
entradas externas |
|||
datos /archivos |
1 a 4 |
5 a 15 |
> 15 |
0 ó 1 |
s |
s |
m |
2 |
s |
m |
c |
> = 3 |
m |
c |
c |
consulta (entrada) |
|||
datos / archivos |
1 a 4 |
5 a 15 |
> 15 |
0 ó 1 |
s |
s |
m |
2 |
s |
m |
c |
> = 3 |
m |
c |
c |
archivos lógicos internos |
|||
archivos / datos |
1 a 19 |
20 a 50 |
> = 51 |
0 ó 1 |
s |
s |
m |
2 a 3 |
s |
m |
c |
> = 4 |
m |
c |
c |
Figura 6-1: Hoja 1 - Complejidad de Funciones
Figura 6-2: Hoja 2 - Estimación de costo y esfuerzo
Se debe mencionar que la estimación del esfuerzo no incluye las etapas de puesta en marcha y mantenimiento del sistema [Varas95]. Sólo se considera la especificación de requerimientos, diseño, construcción y pruebas internas.
Por último, se propone tener un historial de PF y esfuerzo, con el fin de crear un modelo que se ajuste a los desarrollos de Synapsis, de la siguiente forma:
Encontrando el superíndice n linealizando la función y las constantes a y b con regresión lineal, previamente haciendo un cambio de variable de PFn a otra que no posea superíndice.
6.1.2. Seguimiento y Control de Proyectos
El seguimiento se hace a partir de la mantención de estado, permitiendo ésta conocer la situación real del proyecto. Para conocer el avance del proyecto se propone usar los siguientes índices de control, que abarcan el control de los recursos, de tiempos y de cumplimiento de actividades:
Avance según Esfuerzo
Su objetivo es indicar cuantas horas hombres se han consumido sobre las proyectadas.
Donde:
H. H. Insumidas :Horas insumidas reales registradas a la fecha que se realiza el cálculo del avance del proyecto.
H. H. Estimadas :Horas estimadas al comienzo del proyecto.
Avance según Tiempo
Su objetivo es indicar cuanto tiempo se ha consumido sobre el proyectado.
Donde:
Días Transcurridos :Días transcurridos desde el inicio de la actividad a la fecha en la cual se mide el avance (generalmente es la fecha actual).
Días Estimados :Días Estimados totales de la actividad a la que se quiere calcular el avance, calculados al inicio del proyecto.
Avance real según Hito
Su objetivo es mostrar el estado real del avance del proyecto según las tareas realizadas.
El avance de cada tarea va desde 0 (tarea no realizada) hasta 1 (tarea completa). Y el valor es informado por el jefe de proyecto. El peso se calcula inicialmente con las horas de esfuerzo asignadas a cada proyecto.
Avance estimado según Hito
Este indicador muestra el estado en que debiera encontrarse el proyecto a la fecha indicada.
El avance proyectado de cada tarea va de 0 (tarea no realizada) hasta 1 (tarea completa).
Existen además índices de gestión que evalúan el proyecto una vez finalizado.
Índices de Evaluación Final
6.2. Mantención consolidada de estado
La mantención consolidada de estado es el mecanismo más simple de coordinación donde todas las actividades del proceso tienen un conocimiento de lo que pasa con el resto del proceso, para así actuar en función del conjunto y no individualmente. Esta es una característica de los patrones que por supuesto se incluye en este trabajo y se detalla en el capítulo 7.
6.3. Prácticas de trabajo
Esta variable se encuentra en cada nueva propuesta de mejoras de actividades, en particular, en las variables anteriores de anticipación y mantención consolidada de estados, ya que apuntan a mecanismos formales de coordinación, lo cual hace necesario tener prácticas bien definidas.
A continuación se describirá dentro de esta idea de cambio la actividad de Definición de Requerimientos (Administración de Requerimientos - Norma CMM). En esta fase no es el propósito llegar a establecer las prácticas en detalle, sino enmarcarlas dentro de una posibilidad que proporcione coordinación en el proceso. El detalle corresponde al capítulo 7.
6.3.1. Definición de Requerimientos
Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha especificado y analizado pobremente, decepcionará al usuario y desprestigiará el desarrollo.
Los requerimientos bien establecidos permiten realizar un análisis adecuado del problema, identificar las soluciones más apropiadas y, por sobre todo, permiten delimitar la aplicación. La delimitación de la aplicación evita esfuerzos innecesarios, permite identificar claramente el objetivo y además permite obtener un consenso entre el cliente y el equipo de desarrollo. El proyecto de desarrollo de software debe ser exitoso y para ello debe conocerse claramente el objetivo final, es decir, el sistema que se desea construir. Si el objetivo final no está claramente definido, difícilmente se podrá cumplir con él.
Las nuevas prácticas de trabajo tienen que ver con la Definición de Requerimientos (Administración de Requerimientos - Normas CMM). Es fundamental definir bien los requerimientos y de una manera que se adapte y coordine con la actividad que le sigue (estimación de esfuerzo), ya que para efectos de estimación de esfuerzo, se desea poder obtener el tamaño de la aplicación a desarrollar en PF con sólo la especificación de requerimientos del software. Esta especificación debe ser tal que sea posible extraer de ella toda la información necesaria para realizar este cálculo.
La propuesta que se hace es dividir los requerimientos en requerimientos funcionales y requerimientos no funcionales, porque es a partir de los primeros que es posible obtener el cálculo de puntos de función, apareciendo en esta división las Entradas Externas, Salidas Externas, Consultas Externas y Archivos Lógicos Internos. El analista podrá visualizar desde los requerimientos funcionales conjuntos cohesionados de datos que con una probabilidad muy alta pasarán a formar parte de un archivo lógico interno.
De los requisitos no funcionales, obtenemos las características generales de la aplicación, que deben complementarse con una visión global y sistémica del software a desarrollar, para evaluar correctamente el grado de influencia de cada característica en la aplicación.
Se propone una representación llamada Caso de Uso, descrita en 4.3, para desprender las funciones transaccionales de la aplicación. Esta representación será desarrollada por la metodología OMT++ estándar y se muestra en la figura 6-3. El anexo N°6 muestra una aplicación práctica de caso de uso.
Además para complementar la definición de los requerimientos funcionales se describe en Anexo N°7 la forma de Elaborar un Documento de Definición de Requerimientos (DR), según el IEEE 830, que recogerá todo lo que el usuario defina como necesidad. Y en Anexo N°8 se describe un Checklist de Ayuda en la Definición de Requerimientos que contiene una lista con todos los posibles aspectos a considerar en la redacción de DR, permitiendo que el usuario que los define tenga una guía rápida de los mismos.
Es importante destacar que el documento de requerimientos no sólo consigue un consenso entre el cliente y el equipo de trabajo con respecto a lo que se desea, sino que un documento bien concebido provee las bases para la realización del diseño del software. Debido a que no necesariamente todos los integrantes del equipo de trabajo conocen el área de aplicación del sistema, el documento puede servir como una referencia para resolver dudas específicas de la aplicación o simplemente como una forma de informar al equipo de trabajo el proyecto que se va a desarrollar. Por otro lado, permite la incorporación de nuevos recursos (personal) para apoyar el proceso de desarrollo.
6.4. Coordinación
La coordinación ha estado presente en todas las variables presentadas anteriormente, por lo cual la coordinación se desprende como resultado de las medidas a tomar respecto a estas variables.
6.5. Apoyo Computacional
Este cambio surge como resultado de las decisiones tomadas respecto de las variables anteriores. Así, la Mantención consolidada de estado determina la infraestructura de datos que se requiere, Prácticas de trabajo establece las rutinas que usarán los datos anteriores y las partes de éstas que eventualmente pueden ser computarizadas.
En este caso lo ideal es que el apoyo computacional integre aplicaciones tradicionales existentes, usando una capa software que provea una interfaz estandarizada y amigable y una funcionalidad que facilite el trabajo de los usuarios. Es necesario acceder a los datos de las aplicaciones tradicionales para crear y procesar instancias de los documentos de la capa de coordinación, como por ejemplo del sistema SCP12 del cual es necesario extraer información relacionada a las actividades realizadas por los trabajadores de la empresa.
Para este fin, se propone la utilización de una base de datos relacional y además que se haga un programa que extraiga la información necesaria del SCP.
Caso de Uso Nº |
|
| Nombre Caso de Uso | |
| Versión | |
| Resumen | |
| Frecuencia | |
| Requerimientos de disponibilidad | |
| Actores: | |
| Precondiciones | |
| Descripción | |
| Excepciones | |
| Ilustración | |
| PostCondiciones | |
Figura 6-3: Caso de Uso
9 Fuente: Software Productivity Research http://www.spr.com/library/0langtbl.htm
10 Fuente: Software Productivity Research ttp://www.spr.com/library/0langtbl.htm
11 Ver Anexo N°5: Modelo Cascada
12 "sistema control de proyecto", sistema cuya finalidad es llevar un registro de las actividades que ha realizado diariamente el personal interno y externo de la empresa.