Está en la página 1de 221

El contenido de este libro no podrá se r reproducido, ni total ni parcialmente, sin el previo perm iso escrito del editor.

Todos los derechos reservados.

© Universidad de Alcalá Servicio de Publicaciones

Plaza de San Diego, s/n

28801

Alcalá de H enares

ISB N : 978-84-8138-794-0 Depósito Legal: M-56251-2008

Im presión y encuadernación: Im prenta de la UAH

ÍNDICE

PARTE I.- PLANIFICACIÓN DE PROYECTOS INFORMÁTICOS

Capítulo 1: Introducción

5

1.1 La empresa y su entorno

6

1.2

La ingeniería del software

10

1.3

La planificación y gestión en la ingeniería del software

13

Capítulo 2: Definiciones básicas

17

2.1 Lo que es un proyecto 19

2.2 Tipos de proyectos 22

2.3 Los procesos de Ingeniería del Software

24

2.4 Organización

del proyecto

25

2.5 El director de proyecto: su perfil y su identidad

27

2.6 Especificaciones del proyecto

31

2.7 El ciclo de vida de un producto informático 32

Capítulo 3: Factores de dimensión

37

3 .1 Esfuerzo total dedicado al software

39

3.2 Distribución del esfuerzo 41

3.3 Categorías

de

proyectos

de

sus “dimensiones”

ingeniería

del

software

según

43

3.4 Distribución del tiempo a lo largo del ciclo de vida de un

sistema informático 45

3.5 Estimación de recursos 46

Im preso en España

Capítulo 4: Factores de productividad

51

4.1 Métricas de productividad del software

51

4.2 Herramientas que mejoran la productividad 53

54

4.3 Los CASE

4.4 Productividad según el ciclo de vida 56

4.5 Disponibilidad de recursos 59

PLA N IFIC A C IÓ N Y ÜFiSTION DE SISTEM AS

Capítulo 5: Aspectos gerencialcs

63

5.1 El análisis previo y el control de la inversión

63

5.2 ¿Cuándo un proyecto es satisfactorio? 71

74

75

5.3 Los activos de la empresa

5.4 La información como activo estratégico

5.5 Necesidades

de

elaborar

proyectos

para

adecuar

los

sistemas de información a las tomas de decisiones en un mercando cambiante 76

Capítulo 6: Definición del problema y estrategias de solución

 

79

6.1 Objetivos a alcanzar

 

80

6.2 Especificaciones del producto

 

82

6.3 Los requerimientos de los interesados

 

84

6.4 Búsqueda de una estrategia de solución y su desarrollo

 

85

Capítulo 7: Fases de un proyecto

 

93

7.1 Estrategia de la empresa y sistemas de información

 

94

7.2 Estudio de la conveniencia y viabilidad

 

95

7.3 Estudio funcional del Sistema de Información y creación de

 
 

prototipos

96

7.4 Actividades de inicio del proyecto

 

97

7.5 Actividades de desarrollo, seguimiento y control

 

101

7.6 Actividades de finalización

 

103

7.7 Operación y mantenimiento

103

Capítulo 8: Hitos, documentos y revisiones

 

107

8.1 Ordenar las etapas

 

107

8.2 Relación de tareas

108

8.3 Dependencia entre tareas

109

8.4 Diagramas de Gantt

110

8.5 Los hitos y sus fechas límite

 

113

8.6

Diagramas de carga

115

8.7

La

documentación

técnica

como

herramienta

de

seguimiento de

la planificación

 

121

8.8

Revisiones y ajustes a la planificación

 

121

Capítulo 9: El método de costes

 

123

9.1

Modelos empíricos

124

9.2 Puntos función

 

126

9.3 Distribución porcentual del esfuerzo

 

133

9.4 Modelo COCOMO

 

134

9.5 Método de estimación de Putman

 

162

ÍN D IC E

m

9.6 Herramientas automáticas de estimación

163

9.7 Discusión final

166

Capítulo 10: Planificación del tiempo

169

10.1 De los gráficos de barras al análisis de red

170

10.2 Descripción del modelo gráfico

171

10.3 Reducción del tiempo mediante la reestructuración de la

177

10.4 El PERTyel CPM

183

10.5 Método ROY

195

10.6 Análisis de las redes como herramienta básica

199

Capítulo 11: Programación de Recursos

205

11.1

Holguras

de

las

actividades

y

planificación

de recursos:

¿Cómo

utilizar

las

fluctuaciones

totales,

libres

e

independientes en beneficio del proyecto?

205

11.2 Formalización de proyectos informáticos

212

11.3 Planificación del cash-flow

218

11.4 Retroalimentación

219

Capítulo 12: Análisis del riesgo: Seguridad

223

12.1 Estándares internos, externos y a medida

224

12.2 Identificación y control del riesgo

227

12.3 Estrategias y planes de contingencia

234

Capítulo 13: La comunicación técnica

241

13.1 Fundamentos de la comunicación técnica

243

13.2 Comunicaciones orales y escritas

244

13.3 Preparaciones de exposiciones orales y de materiales de soporte

245

13.4 La herramienta CASE y el software de planificación como medio de producir documentación técnica

246

13.5 Sistemas de

WorkJIow

252

13.6 Sistemas de Groupware

260

PARTE II. GESTIÓN DE PROYECTOS INFORMÁTICOS

Capítulo 14: La gestión de configuraciones

14.1 Concepto de gestión de configuraciones:

Su papel en

el

265

control de la evolución del software

266

14.2 Mantenimiento de la integridad del producto

271

14.3 Normalización de la gestión de la configuración

279

14.4 Establecimiento de líneas maestras

282

iv

PL A N IF IC A C IÓ N Y G E S T IÓ N D E SISTEM A S

Í N

D

I C

E

v

14.5 Tareas de la gestión de la configuración

286

A

1.6

Proceso

de

ejecución

4 1q

14.6 Módulos e

inlerfaces

306

A

1.7

Proceso de control

411

14.7 Elementos de diseño

311

A 1.8

Proceso

de

cierre

4 ]2

14.8 Plan de gestión de la configuración del software

318

A 1.9 Areas de conocimiento de la Gestión de Proyectos

412

14.9 Herramientas de control de configuraciones

320

A 1.10

Versión

2004

4 ]^

14.10 Rentabilidad de la gestión de la configuración

324

ANEXO II. Gestión de Provectos de la Administración Pública

Capítulo 15: La Garantía de Calidad

329

Española (METRICA)

15.1 Introducción a la Garantía de Calidad del Software

330

A2.1 Interfaz de Gestión de Proyectos de MÉTRICA Versión 3

423

15.2 Factores de calidad del software

333

A2.2 Eurométodo

424

15.3 Técnicas de calidad del software

336

A2.3

A2.4

A2.5

Actividades de Inicio del Proyecto (GPI)

425

15.4 Métricas de calidad del software

341

Actividades de Seguimiento y Control (GPS)

427

15.5 Estándares de calidad del software

343

Actividades de Finalización del Proyecto (GPF)

435

15.6 Plan de calidad del software

345

15.7 Modelo de Madurez

348

15.8 La documentación en la gestión de calidad del software

354

Capítulo 16: Organización y control de un proyecto

361

16.1 Estructura de los grupos de trabajo 362

16.2 Estructura del proyecto 364

367

16.3 Modelo de Madurez para la gestión del personal

16.4 Seguimiento y control 368

Capítulo 17: Proyectos especiales de Ingeniería del Software

371

17.1 Reingeniería del software 372

17.2 Repositorios 376

379

17.3 Reingeniería de procesos de negocio

17.4 Reutilización del software 381

17.5 Implantación de paquetes software estándar

386

Capítulo 18: Auditoria Informática

391

18.1 Tipos de auditoria. Auditoria informática

391

18.2 Sistemas de control interno en tecnologías de la información

393

18.3 Organización y fases de la auditoria informática

398

18.4 Clases de auditoria informática

400

ANEXO I Project Management Body of Knowledge (PM BO K )

403

A 1.1 Definiciones y conceptos

405

A 1.2 Fases y ciclo de vida

406

A 1.3 Procesos

406

A iniciación

1.4 Proceso de

408

A 1.5 Proceso de planificación

408

PLA N IFIC A C IÓ N Y «B S T IÓ N D E SISTEM AS

PRÓLOGO

El grupo de trabajo denominado "ACM-IEEE-CS Joint Curriculum Task Forcé" ha elaborado una serie de recomendaciones acerca de las materias troncales, específicamente informáticas, que deberían estar presentes en todo curriculum correspondientes a unos estudios universitarios de primer grado que se deben de complementar con otras de carácter matemático (álgebra, análisis, cálculo, matemática discreta, probabilidad y lógica matemática), físico, prácticas de laboratorio y otras materias de específicas de acuerdo con los diferentes contextos institucionales y objetivos pragmáticos.

Manifiesta el comunicado que "el curriculum se debe de completar con otras experiencias de tipo educacional que favorezcan el desarrollo de una capacidad para el pensamiento crítico, la resolución de problemas, métodos de investigación y el desarrollo profesional. Estas experiencias adicionales generalmente consisten en el trabajo en equipo, la comunicación y la familiarización con la profesión"'.

Este trabajo permitió establecer un punto de partida para situar el marco concreto y analizada la opinión de algunas sociedades prestigiosas que entienden que el desarrollo del software, y su utilización en el campo profesional, se debe de entender dentro de un marco en el cual la Planificación y Gestión de los Sistemas Informáticos debe de tener un peso importante como medida de los aspectos gerenciales de las organizaciones. En este sentido es preciso puntualizar otra serie de aspectos que permitan desarrollar y detallar el contenido del presente libro.

En esta breve descripción del contenido se apuntan los siguientes temas:

Planificación de un proyecto de programación. Comunicación técnica. Gestión de configuraciones. Control de Calidad. Organización y administración de un proyecto. Estos temas expuestos nos conducen a la idea general de que el

1ACM/IEED-CS Join Curriculum Task Force. Computer Curricula 1991. Ed. ACM Press,

1991.pp.78.

\

-,

2

PLA N IFIC A C IÓ N Y G ESTIÓ N DE SISTEM A S

objetivo que se persigue con la asignatura Planificación y Gestión de Sistemas Informáticos está orientada hacia la asimilación de conceptos informáticos tendente a su posterior utilización en el dimensionado, planificación y operación de un proyecto informático: El Desarrollo de Software de Calidad como proyecto.

La necesidad de esta materia podemos encontrarla en el hecho de la competitividad, la competencia ofrece al cliente mayores posibilidades de elección y precios más bajos. Por otra parte, la garantía que se ofrece al consumidor de obtener mercancías y servicios de calidad a los mejores precios, es que pueda contar con varios proveedores que compitan en el mismo negocio. La competencia libre y abierta es la piedra angular en la que descansa nuestro sistema de economía de mercado. Además las empresas o instituciones no siempre persiguen de una forma natural la competencia y el recorte de precios, pero su principal misión es conseguir los máximos beneficios para sus accionistas. La Informática no se puede quedar fuera de este juego: los cambios que se demandan del personal de proceso de datos son para mejorar la competitividad y los resultados de la compañía, y tales cambios también inciden en el propio departamento de informática.

Para muchos la política de competencia es una idea abstracta, sin embargo, los beneficios que nos reporta a todos son bien tangibles. Para demostrar esta tesis basta con mirar la mala calidad de los servicios ofrecidos por los sistemas de economía planificada. La competencia, obliga a los fabricantes, en nuestro caso de software y hardware, a mantener los precios más bajos posibles si no quieren correr el riesgo dé perder cotas de mercado. Además, un sistema de libre competencia sensibiliza a las empresas frente a las exigencias y deseos de los clientes (las empresas con ciertos monopolios ofrecen al consumidor lo que ellas quieren producir y no lo que ellos quieren que se produzca). La competencia también es un agente dinamizador estimulando a las empresas y organismos a invertir, investigar, innovar y fabricar mejores productos que sus rivales.

Es un hecho comprobado que los profesionales de centros de proceso de datos cuyas empresas se han visto obligadas a competir, están más capacitados para hacer frente a sus competidores y se han cultivado más en el manejo de las nuevas tecnologías.

Pero la competitividad no está cifrada únicamente en bajar los precios, sino además, en hacer las cosas mejor que los demás: ofrecer garantías de funcionamiento, tener los productos con unas tasas de mantenibilidad bajas, ofrecer una buena documentación técnica. Cuando Michael Hammer acuñó el

PR Ó LO G O

3

término reingeniería estaba posiblemente muy lejos de imaginar que en pocos

 

'

años este concepto iba a dejar una huella indeleble en la mayor parte de los procesos de desarrollo informático de empresas. La idea de Hammer se ha

(

asentado

fuertemente como sinónimo de procesos de adaptación y

optimización de viejas aplicaciones.

 

,

La calidad del software y las nuevas metodologías junto con la necesidad evidente de poseer una tecnología suficientemente potente para adaptar los

Por esta razón es por lo que el tipo de reingeniería que se está imponiendo

(

procesos rápidamente a las nuevas y crecientes necesidades de un mercado cada vez más competitivo, han popularizado la necesidad de la reingeniería de la informática y, tenemos que decir, que actualmente los resultados no están a

(

la altura de lo que se esperaba. Por el hecho de necesitar los resultados

(

^

rápidamente no se han instalado de forma global procesos de reingeniería con una metodología adecuada en casi ninguna empresa; normalmente se ha

'

recurrido a este tipo de soluciones cuando el propio sistema necesita, de forma urgente, una reparación, lo que hace que se haya producido un alto índice de fracasos en los proyectos emprendidos y no por ello se puede achacar toda la

(

culpa a deficiencias intrínsecas de este tipo de procesos sino a la falta de unas

<

buenas herramientas y metodologías suficientemente asentadas en la

,

organización de la empresa.

f

actualmente en las empresas (sobre lodo en España) es la reingeniería de

r

procesos, en base a la cual se estudian, se planifican y se redefinen los flujos de trabajo y metodologías internas de las empresas para conseguir maximizar la

(

^

eficiencia e, indirectamente, los resultados económicos. A partir de aquí se desvela la importancia que está tomando el papel que juegan los departamentos informáticos en la toma de decisiones empresariales, los viejos centros de proceso de datos se reestructuran y pasan a asumir un papel protagonista en la

1

gestión del cambio y en los procesos de planificación estratégica de empresa.

(

(

Por todo ello, en

la

lectura de este

libro, nos fijamos unos objetivos

(

específicos que se orientan a que el lector sea capaz de:

• Estudiar la viabilidad y la conveniencia de desarrollar algún producto informático.

1

• Planificar el desarrollo, con unos medios finitos, para lograr el mejor

1

resultado.

(

• Gestionar la realización de dicho producto controlando y evaluando los

(

resultados producidos.

(

• Dimensionar un sistema informático adecuado a unas necesidades (lo que significa no despilfarrar los medios).

PLA N IFIC A C IÓ N Y GESTIÓ N DE SISTEM A S

• Medir cuales son las prestaciones que dicho sistema informático le está ofreciendo.

• Detectar los posibles "cuellos de botella", si los hubiese, así como sus causas.

• Evaluar y determinar los métodos alternativos o las modificaciones oportunas para conseguir, si fuera posible, un modo de explotación que mejore el rendimiento del sistema.

En resumen, dirigir un Proyecto de Informática de una envergadura creciente, en función de la experiencia que se vaya adquiriendo y adecuar los recursos a la consecución de los fines, en las mejores condiciones posibles.

La organización de la obra se ha agrupado en capítulos repartidos dentro dos grandes módulos:

• Planificación de Proyectos Informáticos.

• Gestión de Proyectos Informáticos

Se entiende que la materia de PLANIFICACIÓN Y GESTIÓN DE SISTEMAS debe girar entorno a estos dos grandes temas, para ello, dentro del primer módulo y después de hacer una amplia introducción a la planificación, se va a pasar a estudiar las "técnicas de representación" y la gestión de tales proyectos. Finalmente nos ha parecido conveniente añadir dos anexos para explicar dos de las metodologías de gestión de proyectos más utilizadas en nuestro entorno: PMBOK (Project Management Body O f Knowledge) y METRICA (Gestión de Proyectos de la Administración Pública Española).

Los autores tratamos de poner en manos del estudiante una colección de toda la tecnología existente a fin de contribuir a ayudarle a fijar el vasto campo de la Ingeniería del Software desde el punto de vista de la planificación y gestión de sistemas informáticos.

CAPÍTULO 1

INTRODUCCIÓN

A lo largo de la historia de la Informática, en el desarrollo y gestión profesional

de los sistemas de información se ha considerado de forma habitual que este tipo de tecnología era fruto del buen criterio del técnico, que se entendía como

un

artesano de la programación. Este enfoque no es el que se pretende fomentar

en

este libro, en el que se estudia la forma de aplicar un conjunto de métodos,

técnicas y herramientas en las diferentes fases del ciclo de vida de un proyecto informático. De hecho, se pondrá especial énfasis en los aspectos de la dirección de proyectos, las medidas de esfuerzo para su realización en las mejores condiciones económicas, el establecimiento de las tareas a realizar, la estimación de recursos necesarios, la planificación, cómo mejor adecuación de los recursos a las tareas con una visión de futuro para evitar conflictos en la no disponibilidad de recursos, la comunicación técnica, el control de calidad y de costes, la documentación del producto obtenido, y el mantenimiento, tanto del producto como de la propia documentación.

Debemos considerar que los contenidos de esta obra no son los de una

ciencia que explica fenómenos de la naturaleza o de la sociedad, sino más bien

se han de entender en el sentido amplio de conocimiento sistemático con base

teórica que permite construir y manejar objetos útiles dentro de unos escenarios con limitaciones económicas, temporales y de aceptación. Así pues, la planificación de sistemas de información debe ser considerada una rama de la ingeniería más que una ciencia propiamente dicha. En cualquier caso, se ha señalar que éste conjunto de fundamentos teóricos y procesos de ingeniería práctica conduce a la nueva visión de que la ingeniería puede aplicarse al diseño y construcción de sistemas abstractos, aunque la afirmación no adolezca

de detractores.

6 PLA N IFIC A C IÓ N

Y G ESTIÓ N DE SISTEM A S IN FORM ÁTICOS

1.1 LA EM PRESA Y SU EN TO R NO

El desarrollo de aplicaciones informáticas se lleva a cabo en el contexto de una organización de producción de software. Por este motivo, antes de adentrarnos en la descripción de aspectos eminentemente técnicos, es conveniente detenerse a analizar el marco de referencia en el que se van a situar los proyectos informáticos, constituido fundamentalmente por una o varias empresas en las que se llevan a cabo unos determinados procesos y un tipo de relaciones internas que pueden afectar al desarrollo de este tipo de proyectos.

Una empresa podemos considerarla como una combinación de factores orientados a prestar un servicio u ofrecer un determinado producto, normalmente, para conseguir un beneficio o resultado propio de su actividad.

Para lograr esto es necesario, en primer lugar, un negocio en el sentido de cualquier actividad relacionada con la compra-venta o prestación de servicios que genere beneficio. Además es necesario disponer, en términos de economía normales, de una sociedad mercantil entendida como una unidad jurídica que regula la relación que produce el patrimonio del cual son titulares al menos dos personas. También se necesita de una unidad técnica vista como un conjunto de procesos tecnológicos por los que un determinado conjunto de factores van a ser trasformados en una serie de productos o resultados, y que se entiende con el nombre de explotación. Además suele ser necesario un establecimiento, en forma de unidad espacial o física donde se localiza la actividad (puede ser una planta, una factoría software, unas oficinas, etc).

Grandes investigadores de la gestión empresarial han ayudado a precisar los factores que intervienen en una empresa; así, Gutenberg, en “Fundamentos de la Economía de Empresa”, establece dos grupos específicos de factores a considerar: los elementales y los dispositivos. Los aspectos “elementales” de la empresa están formados por la materia prima, las factorías, los equipos, el trabajo a realizar, en resumen todo aquello que se puede considerar como activos materiales, que, por tanto se pueden ver, medir y contabilizar fácilmente. Por otra parte estarían los factores “dispositivos” o pautas intangibles de gestión de la empresa, formados por la dirección, la propia planificación o forma de hacer el trabajo, la organización de todo el negocio, las patentes que pueda tener y el conocimiento y su gestión que puede establecer elementos diferenciadores de una empresa respecto a otra.

En este contexto empresarial podemos decir que la planificación es el proceso de ordenamiento de los factores en función de los objetivos. Así, según los factores que tratemos se obtendrán distintas visiones de la planificación: si

C A P ÍT U L O 1: IN T R O D U C C IÓ N

7

utilizamos como punto de vista los factores productivos, obtendremos una planificación orientada a la productividad; si introducimos todos los factores que componen el conjunto de la empresa con el objetivo de su posible proyección en el tiempo, obtendremos datos de la planificación estratégica; y así sucesivamente.

Sin embargo, en la definición anterior, hemos introducido el término “ordenación” en el sentido de organización, entendida como la búsqueda de las estructuras humanas y técnicas para ejecutar la planificación, obteniendo el mayor rendimiento posible desde una consideración dinámica de la organización empresarial. Según Gutenberg, la empresa es una unidad que dispone de unos factores de producción determinados y que, a partir de la decisión del hombre, se combinan entre sí para alcanzar unos servicios o productos que va a colocar en el mercado.

En este sentido, tenemos que considerar seriamente el entorno económico- social de la empresa, ya que la empresa está integrada por individuos, organizados formal o informalmente, que desarrollan una serie de tareas cumpliendo una función social y, la empresa, en su función global se presta a dividir su funcionamiento en tareas específicas, de tal forma que se trate de relacionar cada tarea con un individuo que la satisfaga.

Antiguamente la empresa buscaba una forma de realizar un producto, organizar la producción y, finalmente, investigar la forma de vender mejor ese producto. En el caso específico de una empresa de software, normalmente se obtenía un producto que, posteriormente se trataba de vender. Hoy día el proceso es a la inversa: primero se investiga qué se puede vender, después se

desarrolla el proyecto de producción, posteriormente acudirá a los suministros

la producción de lo que

o

materias primas, y, venderá.

finalmente

llevará a cabo

Hemos visto una dimensión social de la empresa, pero para entender mejor la planificación de su producción es necesario entender otra serie de dimensiones como son:

• La dimensión funcional, entendida como la actividad organizada y alternativa al mercado con ánimo de lucro

• La dimensión técnico-económica, que se centra en el proceso de trasformar productos. Es la actividad productiva de bienes y servicios.

• La dimensión económico-financiera, como unidad creadora de valor añadido. Es la actividad económica que crea valor y dinero.

8 P L A N IF IC A C IÓ N

Y G EST IÓ N DE S IS T E M A S IN FO R M Á T IC O S

• La dimensión jurídico-mcrcantil, que junto con la comercial es la actividad generadora de relaciones.

• Otros aspectos de la dimensión social, entendida como otra actividad compuesta por relaciones humanas y de poder que establecen un complejo diseño de comunicaciones y de relación entre las personas que forman esa empresa

También tenemos que comprender que existe una serie de factores que condicionan la explotación económica, y que podemos clasificar en factores independientes y dependientes. Entre los primeros se encuentra la productividad que se obtiene por el mero hecho de poder modificar la prioridad de los recursos, la economía en la gestión, el equilibrio financiero o la experiencia de saber hacer las cosas bien. Como factores dependientes podríamos citar los costes de obtención de las licencias de los sistemas operativos, el precio de los suministros básicos o la rigidez del mercado laboral establecido por ciertos grupos de presión, los sistemas organizativos que configuran el tipo de economía centralizada que condiciona la propia estructura en cuanto a las posibles dependencias de la gestión o, incluso, la misma realización de las actuaciones asignadas.

Al considerar los factores dependientes, debemos tener en cuenta que la actividad empresarial forma parte de un sistema de “economía de mercado” que condiciona fuertemente el desarrollo de la propia planificación empresarial. Los pilares básicos de la economía de mercado son la configuración de un mercado con un mecanismo de regulación que trata de garantizar que las empresas funcionen con la misma eficiencia, es decir, que las empresas tengan las mismas oportunidades de sobrevivir en ese mercado. La primera consecuencia de ello es que el precio de los productos o servicios lo impone el propio mercado y no las empresas que operan en él. La economía de mercado trata de garantizar una política social necesaria para que no existan personas y actividades marginadas del mecanismo del mercado, basada en los principios de solidaridad y subsidiariedad, que van a imponer serias restricciones, por ejemplo, en el calendario laboral del personal asignado a un proyecto. Existen otra serie de factores que son necesarios en la economía de mercado, como son una cierta estabilidad monetaria que permita la regulación de las operaciones por medio de un sistema financiero controlado por el sistema político participado por el estado. También se puede producir la intervención de los estados en la creación de estructuras y tejido comercial, para facilitar el desempeño de las funciones propias de la empresa y que permitan reducir los costes externos. Otro factor dependiente sería la existencia de un sistema educativo que contemplase la capacitación de los individuos para

C A PÍTU LO

1: IN T R O D U C C IÓ N

que puedan realizar un aprendizaje continuo y la adecuación permanente a su puesto de trabajo con independencia del avance de las tecnologías.

Otro aspecto de interés a tener en cuenta en este capítulo de introducción es la presentación de la figura del empresario, como responsable de una organización que desarrolla software. En este sentido, podríamos enumerar algunas de las capacidades básicas que ha de reunir cualquier empresario:

• Una persona que asume riesgos.

• Aquel que cede el capital para iniciar la actividad empresarial.

• Aquel que establece cómo se realiza la combinación de factores dentro de la empresa.

• Aquel que plantea innovaciones dentro de la empresa.

• Persona que fija objetivos a conseguir, establece los medios que llevarán a conseguir esos objetivos y plantea las medidas económicas oportunas y más favorables para ello.

Si tenemos en cuenta la consideración de Gutenberg del empresario como directivo, en tanto factor dispositivo, con funciones de dirección, planificación y organización, puede afirmarse que también ha de tener la capacidad de adaptarse al entorno y a sus estructuras, de tal suerte que la empresa, como conjunto de funcionalidades, debe imprimir a sus procesos y estructuras un carácter dinámico frente a los cambios, que le permita incrementar la utilidad de todos y cada uno de los grupos o factores que la componen: personal, clientes, accionistas, la propia comunidad donde está implantada). En este sentido, es necesario hacer una breve reflexión sobre la globalización de la economía1ya que el valor de los recursos de una empresa tiene que evaluarse desde su dimensión mundial y en función de su utilización mundial, lo que nos lleva a desarrollar nuevos diseños organizativos dentro de la actividad empresarial, como pueden ser la movilidad rápida de las personas y de las estructuras2 que permitan trabajar con estructuras más flexibles, y poder crear estructuras organizativas complejas para competir con ventaja en aspectos globalizadores de la producción. Esto supone crear una cultura empresarial nueva que se oriente a los procesos y no a las funciones, con una coordinación permanente y estableciendo una división del trabajo que permita obtener, en cada momento, productos de mayor calidad y en el menor tiempo posible.

1 Las causas de la Globalización de la economía se deben fundamentalmente a la eliminación de barreras políticas, aduaneras, financieras, culturales, etc.; así como a la descentralización geográfica y de estnictura de la propia empresa. 2 Esto se conoce como el aumento de la movilidadfunciona!.

10 P L A N IF IC A C IO N Y G E ST IÓ N DE S IST E M A S IN FO R M Á T IC O S

1.2 LA IN G EN IER ÍA DEL SOFTW ARE

Además del marco económico descrito, constituido por la empresa y su entorno, el contexto tecnológico en el que ha de entenderse la planificación y gestión de proyectos de desarrollo de sistemas informáticos es el de la Ingeniería del Software, ya que este tipo de sistemas implica normalmente la generación de un tipo de software con la suficiente complejidad como para concebir su construcción según un enfoque “ingenien!”.

El origen de la ciencia conocida como “Ingeniería del Software’* suele fijarse a finales de la década de los años sesenta, cuando, después de más de veinte años de desarrollo “artesanal” del software, la Comisión de Ciencias de la OTAN, en otoño de 1968, convoca a un grupo de medio centenar de expertos con la intención de trazar las líneas maestras para salir de la denominada “crisis de la programación” o “crisis del software”. El arte de la programación se encontraba, entonces, en una situación en la que los fracasos operativos cada, día eran más frecuentes. Los expertos concentrados por la OTAN no lograron definir un camino capaz de guiar la nave a buen puerto, aunque acuñaron un término para esa lejana meta: ‘'La Ingeniería del Software”.

Una de las primeras definiciones de ingeniería del software se debe a Fritz Bauer3, quien, en una de las primeras conferencias importantes dedicada a la Ingeniería del Software, la define como “<?/ establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funcione de manera eficiente sobre máquinas reales". Algunas definiciones posteriores, como la de Boehm, la entienden como “la aplicación práctica de! conocimiento científico en el diseño y la construcción de programas de computadora la documentación asociada requerida para desarrollarlos y mantenerlos”. Posteriormente, Zelkovitz, Shaw y Gannon (1978) afirmaron que la Ingeniería del Software es “el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas software”. Finalmente, en 1993, la asociación IEEE Computer Society la define como “/a aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software” en su estándar 610.12.

En cualquier caso, la opinión compartida por los diferentes autores en este ámbito es la necesidad de llevar a cabo actividades adicionales a la

3 Nota tomada de P. Naur y B. Randcll, en "Software Engineering: A report on a Conference sponsored by the NATO Science Commitee”, NATO, 1969.

C A P ÍT U L O

I: IN TRO D U C CIÓ N

programación que den un carácter sistemático al desarrollo de software que permita considerarlos como un trabajo de ingeniería. En la figura 1.1 se muestra un ejemplo de estructuración en etapas de un proyecto de ingeniería del software. Durante la Etapa de Análisis se definen los requisitos o requerimientos del sistema, que establecen lo qué tiene que hacer, es decir, su funcionalidad. En la Etapa de Diseño se establece una estructura del software que se ajustará a los requerimientos formulados en la etapa anterior. La Etapa de implementación tiene por objetivo producir un sistema terminado: esta etapa incluye la programación del sistema y su implantación. Finalmente, durante la Etapa de mantenimiento se produce una sucesión de sistemas terminados, que perfeccionan, adaptan y corrigen las versiones base previas.

Figura 1.1 M odelo en etapas para el desarrollo de proyectos softw are

De las definiciones anteriores se deduce que en la Ingeniería del Software existen tres elementos clave que han de ser tenidos en consideración por el director de un proyecto para conseguir un control efectivo del mismo y para la obtención de sistemas de información productivos y de calidad; se trata de los métodos, que definen una secuencia ordenada de acciones cuya realización permitirá conseguir los objetivos establecidos en cada etapa del proyecto; los procedimientos para llevar a cabo los métodos; y las herramientas que han de ofrecer el soporte que permita la aplicación real de tales procedimientos.

Pero la Ingeniería del Software sigue siendo una ciencia inmadura y la mayor parte del software que se produce se realiza con técnicas artesanales similares, salvando la distancia, a los productos obtenidos por las manufacturas de productos anteriores a la revolución industrial donde no existían procedimientos normalizados de intercambiabilidad y sí una fuerte labor artesanal. De hecho, a medida que los proyectos de desarrollo de software crecen tanto en complejidad como en volumen, la productividad, medida como número de programas por hora de trabajo disminuye. Se emplea poco tiempo en tareas tales como diseñar, codificar y depurar productos, que es lo que cons­ tituye el trabajo real del desarrollo de software, y mucho en coordinar lo que se está programando. Así pues, no parece ser realista medir en programadores- mes la cantidad de trabajo necesaria para desarrollar un proyecto de software.

PLA N IFIC A C IÓ N Y G ESTIÓ N DE SISTEM AS IN FORM ÁTICOS

Un proyecto que ocupa a una persona durante ocho meses es un proyecto de ocho programador-mes. Pero quizás, no pueda terminarse en cuatro meses por dos personas o, peor aún, en dos meses por cuatro personas. La caída de productividad a medida que el tamaño del equipo se incrementa es tan dramática, que equipos de tamaño medio o grande pueden no llegar a producir absolutamente nada útil (Sommerville en “Software Engineering”).

En muchos casos se puede atribuir la disminución de la productividad a los problemas de comunicación entre los miembros del equipo. En este sentido, se puede afirmar que cuantas más personas involucradas, será necesario utilizar más tiempo en la comunicación entre los miembros del equipo; así, en un equipo de tres personas hay tres canales de comunicación entre esas personas, pero en un equipo de cuatro hay seis canales de comunicación. Siguiendo esta progresión se puede entender que en equipos muy grandes, a pesar de las estructuras jerárquicas que se decidan para la administración del proyecto, las vías de comunicación crecen desorbitadamente en número, con lo que la comunicación entre los miembros del equipo se hace cada vez más importante

y a la vez más trabajosa.

Como el número de canales de comunicación crece más deprisa que el

número de personas involucradas, un equipo de desarrollo de tamaño mediano

o grande emplea proporcionalmente más tiempo coordinando (y menos tiempo

progresando) que un equipo pequeño. Como el tamaño del equipo crece en algunos puntos críticos del proyecto, todo el tiempo se emplea en comunicación entre miembros y en acomodar lo ya producido a las estructuras

recientemente acordadas, y no se deja tiempo para el progreso real.

En el pasado, las tareas de los programadores consistían exclusivamente en codificar y depurar, sin dar importancia a diseñar el software antes de desarrollarlo. En general, no se usaban modelos para asegurar que el resultado final se ajustase al propósito inicial, o para definir una estructura de programa práctica y mantenible.

De esta forma los cambios producidos por la adaptación al Euro o la problemática del año 2000 han hecho que una gran cantidad del software antiguo existente haya sido imposible de modificar; y es que, cuando se desarrollaron los grandes programas que aún permanecen funcionando, fueron pobremente estructurados y escasa o nulamente documentados, de tal suerte que resultaba muy caro y, en algunos casos, imposible su mantenimiento. A menudo, no se ajustaban a los requerimientos iniciales del usuario. Al poco de la aparición de la Ingeniería del Software, los ingenieros aprendieron a desarrollar los grandes sistemas en una serie de etapas, cada una de las cuales

C A PÍTU LO

I

IN TR O D U C C IÓ N

produce una línea base o configuración ele referencia que es tomada como plataforma para las actividades de la siguiente etapa.

El mantenimiento del software puede entenderse como el “proceso de modificar un sistema o componente software después de la entrega aI cliente o

usuario para corregir defectos, mejorar el rendimiento o atributos, adaptarlo a un cambio de entorno o ampliar su funcionalidad’’ [IEEE, 1993]. En este contexto, una línea base puede considerarse como un producto o especificación que ha sido formalmente aprobado por los miembros del proyecto de desarrollo

y sólo podrá cambiarse mediante procedimientos formales de control de

cambios. De una manera más sencilla se puede tomar como una “fotografía” aprobada del sistema en un momento dado de su configuración.

1.3 LA PLANIFICACIÓ N Y GESTIÓN EN LA INGENIERÍA DEL

SOFTW ARE

La Ingeniería del software se creó como un intento para resolver los habituales

problemas que se plantean en las organizaciones dedicadas al desarrollo de software o sistemas de información, entre los que se encuentran los siguientes:

• La imposibilidad de satisfacer en unos plazos razonables las crecientes necesidades marcadas por sus clientes, cuyas expectativas hacen que cada día el desarrollo sea más complejo.

• Los altos costes de mantenimiento debido fundamentalmente la escasa o nula documentación de los sistemas.

• La necesidad de terminar el producto, en muchos casos a cualquier coste, en un periodo limitado de tiempo debido, sobre todo, a problemas de competitividad.

Se trata, por tanto de llevar a cabo una producción industrializada del software para así mejorar la calidad total de los productos y disminuir los costes de mantenimiento. Esto implica también la necesidad de plantear una auténtica ingeniería de procesos, estudiando, planificando y definiendo los métodos de trabajo y sus flujos para conseguir maximizar la eficiencia e, indirectamente, los resultados económicos.

Por todo ello, las actividades de gestión destinadas a la planificación, el seguimiento y control de los procesos y recursos, tanto humanos como materiales, que intervienen en un proyecto software también han de

PL A N IFIC A C IÓ N Y G E ST IÓ N D E SISTEM A S INFORM ATICOS

considerarse como actividades de la Ingeniería del Software, que deberán integrarse con las de desarrollo para conseguir conjuntamente la obtención de un producto software de calidad, fácilmente mantenible y a un coste y en un tiempo razonables.

En la figura 1.2 se muestra la integración de los dos tipos de actividades. En el caso de las actividades de gestión, en primer lugar se realiza la planificación del proyecto, en la que se definen las condiciones de trabajo, los recursos, las fechas y se estiman los costes. A continuación comienza el desarrollo según el plan establecido y, en paralelo, las actividades de seguimiento y control para vigilar el avance del proyecto.

Planifie

ación

«=>

0

a

í

Seguimiento

y Control

o

F igura /.2 Integración de las actividades de desarrollo y de gestión en proyectos software

Esta forma sistemáticas de trabajar exige el establecimiento de un conjunto de métodos, procedimientos, tareas, herramientas que hagan posible la realización del proyecto según las etapas y actividades previstas y faciliten su control por parte del responsable del mismo.

Los objetivos se irán consiguiendo en tanto que todas las técnicas se apliquen en el marco de una metodología que cubra, en la mayor medida posible, todas las fases del ciclo de vida del proyecto. Aunque se puede establecer una metodología de aplicación totalmente manual, es conveniente que ésta sea susceptible de ser automatizada, utilizando herramientas CASE (Computer Aided Software Engineering) que faciliten la generación de los productos intermedios previstos (modelos, prototipos, etc.) y el control del proyecto, y que permita la reutilización de elementos en futuros proyectos.

Para concluir podemos afirmar que en una metodología de Ingeniería del Software se deben considerar tanto actividades de ingeniería de producto, relacionadas directamente con la secuencia de desarrollo del software; como

C A PÍT U L O

I

IN T R O D U C C IÓ N

15

actividades de ingeniería de proceso, encargadas de la planificación y control de las anteriores. Sin pasar por alto, la conveniencia de que tal metodología incluso supere los límites de un proyecto en particular, y contemple también la definición de los procesos de planificación estratégica de las empresas que permitan prever su evolución tecnológica a medio o largo plazo.

PLANIFICACIÓN Y GESTIÓN DE SISTEMAS INFORMÁTICOS

CAPITULO 2

DEFINICIONES BÁSICAS

La gestión de proyectos es una rama especializada en el campo de la gestión, cuya evolución ha servido para controlar y coordinar algunas de las complejas actividades de la industria moderna.

Uno de los fenómenos que se pueden observar continuamente a nuestro alrededor es el crecimiento de las cosas vivas, observación que puede realizarse en las plantas, en los animales, en las colonias o, en la población. Tarde o temprano el desarrollo tiene que depender del abastecimiento de los recursos naturales en cantidades suficientes para que la población pueda sustentarse. La competitividad en el logro del alimento deberá ser cada vez mayor al haber, cada día, más bocas que alimentar. Cuando los recursos son escasos solamente pueden sobrevivir aquellos organismos que puedan adaptarse a la situación y no necesariamente son los más fuertes los que sobreviven -recordemos los grandes dinosaurios de otros tiempos, eran poderosos y capaces de arrollar a los pequeños roedores, pero que no supieron adaptarse a unas condiciones climáticas adversas mientras que los la regla de la "ley del que se adapta" se extenderá como norma en la evolución de estas formas de vida que cada vez será más especializada.

En los procesos industriales existe un cierto paralelismo con los acontecimientos que suceden en el mundo de la naturaleza cuando comparamos los efectos del crecimiento y de la evolución. Las empresas nacen en un ambiente de competencia que crea una demanda cada día más acusada de los recursos disponibles, es más, su propio temperamento económico la presenta retos continuos que la obligan a adaptarse a esas necesidades cambiantes. Algunas nuevas empresas surgirán con éxito, mientras otras no podrán soportar la presión ejercida por aquellas que han sido capaces de readaptarse a tiempo, lo que las obligará a dejar su espacio teniendo que cerrar sus puertas y despedir a todos sus empleados.

18 P L A N IFIC A C IÓ N Y GESTIÓN DE S ISTEM A S IN FO R M Á TICO S

Supongamos que nos encontramos en una empresa que se dedica a crcar programas informáticos de gestión de empresa, a prestar servicios en la instalación y adaptación de tales programas a la vez que ofrece servicios de consultaría de sistemas y que cuenta con una plantilla de unos cincuenta empleados. La producción de esta empresa debería estar supervisada por un director de producción y así se aseguraría que los pedidos de mejoras, desarrollo e implantación de los productos que vende no tardaran más de una cuantas semanas en estar totalmente disponibles o incluso instalados con la

satisfacción total de los distintos clientes. El volumen de trabajo encomendado

a los distintos empleados tiene que programarse de tal modo que se asegure

una armonía total para asegurar un uso efectivo de los recursos humanos que deben de tener una perfecta dinámica de trabajo.

En un principio, esta empresa cuenta con un director de producción

competente que, con conocimientos basados en la propia experiencia, hace que

la

empresa funcione dando beneficios, los costes se calculan a tiempo vencido

y

la duración de los nuevos desarrollos se estiman en base a la experiencia

acumulada de trabajos similares ya que, al fin y al cabo, tenían una duración bastante corta. Pero con el paso del tiempo esta empresa está creciendo, sus clientes están demandando nuevos servicios. Ahora los pedidos son mayores tanto en cantidad como en tiempo de desarrollo, aparecen nuevos factores:

algunos clientes necesitan que alguno de los productos desarrollados para ellos se adelanten en un plazo considerable a pesar de que el número de horas a emplear en este proceso sea muy elevado. Los programas desarrollados se han vuelto tan especializados que no tienen validez fuera del ámbito del cliente concreto que encarga este determinado trabajo. La empresa que antes tomaba un producto del almacén y le hacía cuatro pequeños arreglos, ahora tiene que diseñar sistemas especiales y adaptarlos a las necesidades del cliente, de tal modo que las entregas que antes podía realizarlas en pocas semanas ahora

necesita varios meses en poder satisfacerlas.

¿Qué es lo que sucede en estos momentos? Simplemente que las tareas de antes, casi rutinarias, han dado paso a complejos proyectos y los viejos sistemas de control y producción ya no son efectivos por sí mismos.

Cualquier intento de planificación en el trabajo tiene que considerar todas las fases necesarias para que éste llegue a buen término. El conjunto de todas las fases de un proyecto informático desde que se concibe hasta que muere, bien por desuso o por sustitución, es lo que se llama ciclo de vida de un producto o sistema informático. Este tipo de definiciones, y el centrar los distintos términos, será el objetivo claro de esta lección que consideramos básica y fácil de entender.

C A PÍTU LO 2

D EFIN IC IO N ES BASICAS

2.1 LO QUE ES UN PROYECTO

19

Como en casi todas las disciplinas, la definición de proyectos, depende del punto de vista que se les dé a los mismos. En este sentido, y dentro del contexto de los proyectos industriales, podemos citar a Archibald que define los proyectos como “el conjunto de procesos requeridos para producir un producto nuevo, un bien nuevo, un sistema nuevo, u otro resultado especificado''. Otra definición, en este caso dado por General Electric, define un proyecto como “una actividad claramente definida, con una implantación de duración finita y con una meta a alcanzar bien especificada". En este sentido podemos fortalecer estas definiciones diciendo que un proyecto es un conjunto de actividades dirigidas a crear unfuturo deseado.

La mayor parle de los Ingenieros de hoy día han dedicado bastantes horas a diseñar, desarrollar o implementar sistemas y, en este sentido, han dedicado horas en ayudar a sus empresas a superar el reto de la incorporación de las tecnologías de información así como en hacer cada día más coherentes los procesos de negocio de sus organizaciones con los sistemas de información de que disponen.

La mayor parte de los Ingenieros de hoy día han dedicado bastantes horas a diseñar, desarrollar o implementar sistemas y, en este sentido, han dedicado horas en ayudar a sus empresas a superar el reto de la incorporación de las tecnologías de información así como en hacer cada día más coherentes los procesos de negocio de sus organizaciones con los sistemas de información de que disponen.

Los procesos de negocio, como decimos, suelen ser la fuente de nuevos

proyectos. Es más, la mayoría de los proyectos se originan en el seno de las empresas como resultado de sus nuevas exigencias para poner en sus

organizaciones

nuevos

productos

o

servicios

con

los que se quiere

comercializar.

Los proyectos en la empresa han evolucionado enormemente. En los años sesenta se ponía un gran empeño en desarrollar productos que fuesen fabricados a gran escala para lo cual se estudiaban los procesos que optimizaran cada una de las tareas o fases de desarrollo del producto. Posteriormente, en los años setenta, se cambió el enfoque de los proyectos por el concepto de calidad como elemento diferenciador entre los productos

20 P LA N IFIC A C IÓ N V G ESTIÓ N DE SISTEM A S IN FORM ÁTICOS

ofrecidos por las distintas empresas: Se luchaba por la calidad a la vez que por la producción en masa que hacía el producto más competitivo en un mercado global.

En los años siguientes las empresas enfocaban sus productos hacia la per­ sonalización o variedad. Las empresas ponían a disposición de sus clientes un catálogo de productos lo mas variado posible como fuerza de ventas. Era necesario haccr proyectos diferenciadores de la competencia para poder seguir manteniendo el pulso de la producción industrial.

Últimamente el mercado exige novedad. El cliente con capacidad econó­ mica de comprar un producto desea algo tecnológicamente novedoso, y los equipos de diseño hacen productos enfocados en esta vertiente.

Pero desde los principios de la organización empresarial se ha visto que es necesario introducir una cierta previsión de lo que sucederá. Así podemos definir la previsión como “la acción y efecto de ver con anterioridad o conjeturar con ciertas señales lo que sucederá”. Es decir, hablamos de anticipar el futuro en base a cierta información, ya que no se trata de tener una fórmula mágica que adivine el futuro.

En este sentido es necesario hacer una pausa y considerar cómo son los proyectos que se realizan en las distintas fábricas u oficinas, y considerar las diferencias que existen entre los proyectos y los sistemas de producción. Podemos establecer, siguiendo este razonamiento, tres categorías dentro de la totalidad de los sistemas de producción existentes en el mundo actual: por una parte estaría la categoría de producción en masa, por otra parte las factorías que hacen producción por lotes y, finalmente, aquellas industrias que realizan proyectos normalmente no repetitivos, mejoras, adaptaciones.

Los sistemas que circundan la producción en masa se diseñan para optimi­ zar cada una de las fases o tareas con objeto de reducir costes, aumentar la calidad y mejorar los procesos. Así las fábricas tienen sus ingenieros del departamento de “métodos y tiempos”, o algún nombre similar, que estudian la duración de cada fase, los materiales que se emplean, sus utillajes, etc. entendiendo que optimizando cada uno de estos elementos atómicos se mejora la calidad del producto. La ventaja de este tipo de producción es que obtiene datos de la experiencia anterior y continuamente trabaja por la mejora continua. Es normal que cada una de las fases esté perfectamente informada por un sistema de gestión que recoge estadísticas para ayudar a la toma de decisión de las posibles debilidades y mejoras a introducir. Los datos se capturan de forma

C A PIT U L O 1: D E FIN IC IO N E S B Á S IC A S

21

automática y se obtienen grandes resultados basados en la eficiencia de los medios empleados.

Los sistemas de producción por lotes son los más frecuentes y son los que se producen utilizando los mismos medios para producir bienes distintos a lo largo del tiempo. Como ejemplo se puede considerar una empresa de tipo “taller de mecanizados” que un día tiene un encargo de fabricar una cantidad de piezas concretas y, algunas horas más larde, otro tipo de productos utilizando las mismas herramientas y el mismo personal. El aspecto más importante para la rentabilidad de este tipo de sistemas de producción es la flexibilidad. Cada ensayo sufrido valdrá para incorporar una nueva experiencia para el futuro. Los sistemas son adaptables y se reutiliza la tecnología aprendida en la fabricación de cada producto.

En contraposición a los sistemas anteriores, los proyectos informáticos normalmente son no repetíbles, en el sentido de que su naturaleza suele ser única, y los medios para alcanzar ese bien futuro suelen ser nuevos cada vez, lo que implica que exista una considerable expectación sobre los pasos a seguir, y que supone, por tanto, un cierto riesgo a sufrir.

Es necesario, en base a las consideraciones anteriores, establecer una dife­ rencia clara entre lo que son los productos, los resultados del proyecto y el pro­ yecto en sí mismo: así podemos definir los productos como esos bienes futuros

a obtener, es decir, los bienes o servicios que la organización fabrica según la

naturaleza de sus objetivos, y que para fabricarlos se necesita de los resultados del proyecto. Estos resultados se definen por los objetivos mismos del proyecto

y suelen formar parte del conocimiento de las propias empresas por lo que, normalmente, no se ceden a terceros.

En el caso concreto de los proyectos, debido a que son actividades inicia­ das para obtener un bien futuro, no se puede asegurar que los planes y estimaciones sean correctos, pero es posible ir formando una base de conocimiento para aplicarla a futuros proyectos más o menos afines.

En otras palabras, cuando hablamos del futuro que deseamos lo tenemos que configurar desde el presente y, en el mejor de los casos, a lo más que pode­ mos aspirar es a hacer pronósticos en los resultados obtenidos hasta el momento actual y en la buena medida efectuada sobre esos resultados.

es

decir, son más de una, y cada una de ellas, puede tener intereses o prioridades ajenos al proyecto que en casos concretos nos puede llevar a la falta de

Por otra parte, se habla de “un conjunto de procesos o actividades

”,

PLA N IFIC A C IÓ N Y G E ST IÓ N DE SIST E M A S IN FO R M A TICOS

C A P ÍT U L O 2: D E FIN IC IO N E S B Á SIC A S

23

recursos disponibles en el momento en el que más nos puedan interesar. Esta consideración es importante porque, como se verá a lo largo del libro, se necesitan cualidades para poder controlar cada una de estas actividades.

Otro aspecto importante, sobre todo de la última definición, es la palabra “dirigidas” y también se hablará de forma detenida de lo que se entiende por dirección desde el punto de vista de “timón” que controla el rumbo del proyecto. Pero el director (o gestor) del proyecto necesita del poder de decisión necesario para poder administrar un determinado marco de referencia.

También ha surgido el término “control”, que en su momento entenderemos que es la posibilidad de saber en cada momento la posición exacta en que nos encontramos en el desarrollo del proyecto. No es posible separar la palabra gestión del término control debido a que no se puede gestio­ nar algo con ciertas garantías de éxito si no se controla.

2.2 TIPOS DE PROYECTOS

Podemos clasificar los proyectos según varias vertientes o aspectos:

• Técnicos y no técnicos

• Unipersonales y inultipersonales

• Monodisciplinares y multidisciplinares

• Monocontrato o multicontrato

• Resultados: tangibles o intangibles

• Rentabilidad económica o rentabilidad social

• Con fines claros: proyectos espaciales

Las características de cada tipo de proyecto nos pueden servir para estudiar el entorno entendido como el conjunto de condiciones en las que se va a realizar el proyecto. El entorno puede cambiar en función de otro tipo de prioridades ajenas al propio proyecto. Una de las amenazas más fuertes sobre el proyecto es el contexto socio-económico, por lo que tendremos que formularnos preguntas del tipo ¿Podemos cambiar el entorno del proyecto a nuestra voluntad? ¿Se modificará el proyecto si cambian las condiciones extemas?.

Igualmente, en función del tipo de proyecto, tendremos que tener un cui­ dado especial en la forma de controlar los gastos, que las disposiciones de efectivo se realicen según el presupuesto previamente establecido, las

condiciones administrativas y su implicación con los otros proyectos, o con actividades coyunturales que puedan surgir.

Es necesario conocer de forma detallada las condiciones de contorno, en particular las prioridades del proyecto y, a ser posible, tratar de tener un calendario en el que se fijen los hitos más importantes del mismo. Hay que considerar la política de la propia compañía respecto a este Proyecto porque puede definir la atención que se puede esperar de sus directivos. En algunos proyectos tendremos que marcar una importancia alta a la normativa legal que exista para el desarrollo de proyectos concretos y así no tener que vulnerar la ley o contradecirla por no conocerla.

Un énfasis especial tendremos que dar a las necesidades de comunicacio­ nes que los entornos modernos demandan. En este sentido se debe de considerar la posibilidad de disponer de herramientas de gestión automática de bases de conocimiento y mensajería para todo el grupo de desarrollo que, en algunos casos, puede estar constituido por personas físicamente distantes lo que nos puede llevar a considerar la necesidad de infraestructura adicional, como puede ser videoconferencias, correo electrónico, y, en general, la disponibilidad de tejido industrial

Con este tipo de información la Dirección de la empresa aborda la decisión de comenzar el proyecto. En el capítulo quinto se desarrollan los aspectos económicos y algunos parámetros sobre el estudio de la rentabilidad. Ejemplos de proyectos pueden ser:

• La sustitución de un sistema informático en una empresa.

• El traslado de un determinado departamento de una planta a otra.

• La

fabricación

de

un

nuevo

electrodoméstico

en

una

fábrica

lavadoras.

de

• El desarrollo e implantación de un nuevo Sistema de Información para el departamento de ventas de una organización.

• La migración de un sistema informático basado en terminar orientado a carácter a consultas tipo web.

• La implementación de un sistema de e-businnes.

• La contratación de un sistema de soporte para una determinada planta de fabricación industrial.

• El establecimiento de una serie de indicadores de captura automática que midan la evaluación del desempeño del personal.

24

PLANIFICACIÓN Y GESTIÓN DE SISTEMAS INFORMÁTICOS

2.3 LOS PROCESOS I)E INGENIERÍA DEL SOFTWARE.

Una vez fijados los aspectos generales vamos a “tomar tierra'’ con los procesos de ingeniería del software entendidos como las etapas que debe satisfacer un proyecto de informática para llegar a su fin. En este sentido es necesario que el Director de Proyecto considere de forma detallada los flujos de trabajo que existan en su organización, así como las metodologías internas de producción que pueden ser factores dependientes que le establecen un determinado marco de maniobra y que, normalmente, deberá cumplir.

En este sentido tiene capital importancia seguir las pautas de:

• La Planificación del Proyecto.

• La Comunicación Técnica

• La Gestión de Configuraciones

• El Control de Calidad

• La Organización administrativa del proyecto

• La Gestión del Centro de Proceso de Datos

Y en general todo tipo de procesos que tienen relevancia dentro de los aspectos considerados por la profesión del informático.

El Ministerio de Administraciones Públicas, a través del Consejo Superior de Informática (CS1), ha publicado la Metodología METRICA versión 3, en uno de cuyos apartados lo dedica a la Planificación de Sistemas de Información según nueve actividades concretas resumidas en los siguientes puntos (figura

r

2 .1):

• Inicio del Plan de Sistemas de Información (PSl)

• Definición y organización del PSI

• Estudio de la Información Relevante

• Identificación de Requisitos

• Estudio de los Sistemas de Información actuales

• Diseño del Modelo de Sistemas de Información

• Definición de la Arquitectura Tecnológica

• Definición del Plan de Acción

• Revisión y Aprobación del PSI

P S l

l

IrtiOo dtl P i n

de

Siste flU i do IftfOrm se lén

*SI 2

D c U i£ i< A

PSl

y

del

CAPÍTU LO

3

IMormacion

Kdevftnlc

T

P S l

4

ld «nl^ic¿ci& n d *

P S l 6

€ *U i0o

0e los

de

loíorm ación

¿eluato

2: DEFINICIONES BÁSICAS

P S l

6

D ise ñ o

á«i f/ o d d o

0# S 't le m a s

de

inform ación

P S l

7

0*fin¡ci*n efe Id

Afquil«cturj

T*cn<?lógicd

PSIO

de Ace»**

P

S

l

*

25

R e visió n y

Figura 2.1 Secuencia de actividades según Métrica V.3

2A ORGANIZACIÓN DEL PROYECTO

Se pueden aplicar una variedad de estructuras para organizar el proyecto en función del bien a producir, de la naturaleza del proyecto, del nivel de riesgo, las posibilidades técnicas del director o del equipo de desarrollo, etc.

La palabra "organización” deriva de “ordenar” en el sentido de diseñar la

estructura o arquitectura con la que vamos a establecer las dependencias entre

dentro del proyecto. Asignar las tareas más

idóneas para esas capacidades y el tiempo estimado para cumplir las tareas o funciones.

individuos, departamentos, cosas

Desde este punto de vista disponemos de cuatro aspectos básicos: tareas que se tienen que realizar, de individuos que forman parte del proyecto con sus

, vez pueden ser materiales o no, de los que disponemos para desarrollar el pro­ yecto, y de las estructuras formales organizativas que van a marcar las reglas del juego.

de los recursos, que a su

conocimientos, motivación, capacidad, actividades

Los modelos organizativos clásicos se clasifican, en una primera visióru en las siguientes categorías:

E/ modelo lineal: En este tipo de modelo se da el principio de unidad de mando y disciplina. Cada persona tiene un solo jefe al que dar cuentas. La responsabilidad y relación con los demás está claramente definido. Son eficaces en control de tareas y tienen bajo coste de funcionamiento. Rigidez de estructura y poca cultura dinámica. (Fayol y Weber).

P L A N IFIC A C IÓ N Y G ESTIÓ N D E SISTEM A S IN FORM ÁTICOS

El modelo de Tcivlor: Trata de separar las actividades mentales de las corporales. Desplazar la responsabilidad de la masa obrera al manager. Trata de la especialización de tareas (un obrero una tarea). Previsión adecuada de “jefes” mediante el estudio del trabajo que se va a dirigir y basado en un acuerdo entre obrero y empresario para definir retribuciones conforme al trabajo realizado.

El modelo de Henry Ford: parte de la fabricación en serie siendo más práctico que teórico. Parecido al de Taylor pero hace descender el número de controladores dejando esta labor a la propia cadena de montaje.

En cuanto a la estructura organizativa, con independencia del tipo de orga­ nización, se suele utilizar alguna de las siguientes:

funcional:

Estructura

Las

tareas

del

proyecto,

las funciones

y

las

actividades

se

clasifican

en

categorías

diferenciadas

entre

y

se

ordenan en función del objetivo a cubrir por el proyecto.

Estructura de autoridad: Se establece una jerarquía entre el personal determinando las responsabilidad de cada uno y sus controles.

Estructura de decisión: Cada persona, según la autoridad que posee, tiene la capacidad de adoptar una u otra decisión

En este apartado no podemos olvidar los principios organizativos clásicos que hacen que el grupo de proyecto funcione debidamente:

Principio de objetivo: Cada componente del proyecto tiene que contribuir a conseguir el objetivo fijado por dicho proyecto.

Principio de definición: Es necesario especificar al máximo las tareas que cada persona tiene que desempeñar y qué responsabilidades tiene en ese sentido.

Principio de autoridad: Es necesario limitar el número de personas con el que nos tenemos que relacionar. Limitar las relaciones entre personas y funciones.

Principio de responsabilidad: La responsabilidad de cada directivo abarca también la responsabilidad de los subordinados.

CA PÍT U L O 2: D E F IN IC IO N E S BÁ SIC A S

27

Principio de continuidad: la reorganización es un proceso continuo.

2.5

IDENTIDAD

EL

DIRECTOR

DEL

PROYECTO:

SU

PER FIL

Y

SU

El Director de Proyecto debe de estar en línea con el director de los Servicios

Informáticos (o cargo similar dentro de la organización) y se le debe de otorgar

la suficiente autoridad para gestionar los conflictos que, desde su nivel hacia

abajo, puedan producirse dentro del proyecto. Igualmente debe de gozar de una independencia suficiente como para poder analizar cada problema con suficiente objetividad para mejor servicio de su organización.

Entre las cualidades que se deberían buscar para el Director del Proyecto cabe destacar las siguientes:

• Mente estructurada y lógica

• Liderazgo y Aceptación por el grupo de trabajo

• Conocimiento del sector de la actividad del proyecto

• Madurez

• Formación específica en aspectos gerenciales (dirección por objetivos)

En concreto es necesario mantener un cierto equilibrio entre directivo y técnico. Es de considerar que el principal reto personal del director está en

encontrar ese difícil equilibrio entre sus funciones directivas -muy importante-

y el papel técnico. De hecho si aspira a un puesto superior dentro de su

organización debe de tener preparado un sucesor lo suficientemente preparado para no tener problemas con la herencia acumulada ya que puede convertirse

en un arma de doble filo que se puede volver contra él mismo.

La dirección es técnica, ciencia y artel. En este sentido es necesario, en las empresas actuales, que los empresarios y directivos sean capaces de guiar a su empresa u organización en un proceso de continua transformación que, para adaptarse a su entorno, necesitarán afrontar debidamente. Pero para poder guiar o conducir a sus empresas, se necesitan de unas dotes de liderazgo para que su personal confíe en ellos y les tenga como referencia en el bien hacer las cosas. Sin embargo las características de los líderes sueles ser distintas, sobre todo si

1 Arte: Conjunto de reglas o preceptos para conseguir hacer bien una cosa (Diccionario de la Real Academia de la Lengua Española)

28 P L A N IF IC A C IÓ N Y G E S T IÓ N D E SIS T E M A S IN FO R M Á T IC O S

contemplamos a hombres que han conducido la historia, como pueden ser Ghandi, Stalin, Cario Magno, etc.

Si bien la noción del liderazgo la tenemos asumida como el arte de dirigir, conducir y proceder, nosotros la podemos centrar como “la capacidad para crear una visión convincente, trasformarla en acción y sostenerla”. En este sentido es necesario señalar algunos elementos del liderazgo, entre ellos:

• La habilidad para utilizar el poder con efectividad y responsabilidad.

• La capacidad para entender cuales son las motivaciones más importantes de sus seguidores.

• La habilidad para saber conseguir que sus seguidores apliquen todo su potencial para la consecución de los objetivos.

• La capacidad para crear un estilo propio conservando un ambiente que favorezca el desempeño de sus esfuerzos para conseguir llegar a las metas marcadas.

La mayoría de los directivos tratan de ser lideres mediante algunos de los sistemas clásicos, que cada uno de ellos en su ambiente concreto ha demostrado su buen funcionamiento, y que son el estilo democrático, el autoritario y el del liberalismo. Sin embargo fue Rensis Likert en 1969 quien sostenía que el estilo participativo en la gestión era el que mejor resultado daba en cuanto al rendimiento de las empresas. Criticado por sus contemporáneos que mantenían que Likert no tenía datos que soportaran esta afirmación, realizó una encuesta evaluada por el personal a cargo de los directivos, que le condujo a clasificar sus estilos de dirección hoy ampliamente aceptados y que son:

• Gestión explotadora y autoritaria, con directivos autocráticos que no confían en sus subordinados motivando con castigos donde la comunicación es totalmente descendente.

• Gestión benévola y autoritaria de directivos que motivan, generalmente, con premios. El tipo de información es descendente y, cuando interesa a la dirección, ascendente.

• Gestión consultiva. En este tipo de estilo la dirección confía plenamente en sus empleados, se delega autoridad para los temas técnicos y los flujos de comunicación son ascendentes y descendentes.

• Gestión participativa. Los directivos promueven la participación y ofrecen recompensas económicas. Todo el grupo se siente cercano y toda la toma de decisiones se realiza a través de procesos participativos del grupo. En este estilo de gestión la información fluye de arriba abajo, así como entre grupos y sus elementos y es el más realista a la hora de fijar sus metas.

C A PÍT U L O 2: D EFIN ICIO N ES B Á SIC A S

29

Es más, Likert llega a proponer un quinto estilo que, según él, surgirá en el luturo y que romperá con la estructura piramidal de la autoridad.

Los cuatro estilos básicos de dirección, se pueden observar desde la personalidad del jefe, que estará condicionado por su experiencia, por la responsabilidad de sus colaboradores y por la confianza mutua entre lodos ellos2. Según el tipo de dirección se desprenderán cierto tipos de actitudes entre las que caben distinguirse la actitud de apoyo que se corresponde con una buena comunicación entre el Director y los colaboradores que participan en el proceso de las decisiones, hasta la actitud de órdenes que el director emite sobre el subordinado con indicación clara de qué debe hacer, en qué momento, con qué medios, de qué forma, supervisándose su cumplimiento.

Existe, también, la teoría del Ciclo Ininterrumpido que reconoce que el estilo de liderazgo más apropiado depende del líder, del equipo y de la situación ya que el seguimiento de un estilo u otro viene condicionado por los respectivos grados de madurez de cada miembro del equipo. El líder puede seguir un estilo u otro a lo largo del tiempo y en función del colaborador.

Para conocer el estilo de dirección de un jefe se suele emplear la técnica conocida como “la rejilla gerencial” en la que se representan, según dos dimensiones, la preocupación por la producción y la preocupación por las personas. En el eje de abscisas se representa la preocupación por la producción, donde se incluyen las actitudes del jefe frente a los problemas de gestión de la empresa, como pueden ser el cumplimiento de la normativa, la productividad del puesto de trabajo, la calidad de los servicios prestados, la creatividad y la seguridad en los procesos de la toma de decisiones. En el eje de ordenadas se representa la preocupación por las personas, esto es, el interés por la motivación, la toma de compromisos del grupo y la calidad de sus relaciones internas.

En la figura 2.2, se representan los cuatro estilos extremos para ayudar a comprender la rejilla gerencial.

2 Descrito más ampliamente en MANAGEMENT OF ORGANIZATIONAL BEHAVIOR- UTILIZING HUMAN RESOURCES. Prentice-IIall, 1981.

3 0 ,

PLA N IFIC A C IÓ N

Y GESTIÓ N D E SISTEM A S IN FORM ÁTICOS

preocupación por la producción

Figura 2.2 Rejilla gerencias de Likeri

El director de proyecto, además debe de tener unas ciertas nociones sobre motivación que es conveniente tocar en la presente sección, si bien su desarrollo sé reserva al capítulo dieciocho, donde descubriremos la importancia de saber qué es lo que hace que las personas trabajen para conseguir sus objetivos; cuales son sus motivaciones y cómo podrían aumentarse. Una de las principales tareas del director será motivar, es decir, detectar las necesidades personales de sus empleados y encontrar el modo de satisfacerlas por medio de su propia actividad en la empresa.

Antes de abandonar este capítulo en el que hemos tratado ligeramente de los estilos es conveniente hablar de dos filosofías de dirección:

• La Dirección por Excepción

• La Dirección por Objetivos

La filosofía de la Dirección por Excepción consiste, básicamente, en limitarse a recibir la información de las incidencias y de las circunstancias excepcionales sin involucrar al personal colaborador en otras tareas participativas. Por otra parte la Dirección por Objetivos, basado en un sistema que supone que las personas se implican en su trabajo identificando las metas comunes con la dirección, definiendo sus respectivas áreas de responsabilidad y evaluándose en la consecución de los resultados.

En el arte de dirigir proyectos, se definen una serie de cualidades que se deben de disponer para poder controlarlos y que son:

C A PÍT U L O 2: D E F IN IC IO N E S B Á SIC A S

• Disciplina

• Concentración

• Paciencia

• Preocupación

• Razón y humildad

• Una serie de habilidades, entre ellas:

■ Liderazgo

■ Creatividad

■ Capacidad de integración

■ Afición al orden y al control

31

A pesar de tener todos los ingredientes para poder tener éxito en los

proyectos es necesario entender que estos, normalmente, se desarrollan contra las metas comunes de la organización (sobretodo si se realiza desde otra

organización contratada para este fin) y que existe una cierta iteración entre el hombre y el proyecto que hace, que frente a cualquier cambio del entorno, entendido este como el conjunto de condiciones en las que se va a realizar el proyecto, se puedan producir una serie de resultados no deseados e, incluso, impredecibles, por lo que se deberá tener en cuenta este tipo de coyunturas, en

socio-económico que normalmente suele seres el más

especial el contexto cambiable.

El entorno no siempre podemos controlarlo y, si cambian las condiciones

externas, el proyecto se modificará. Es más, en momentos de conflicto, tendremos que saber controlar los gastos y conocer lo que pasará con otros proyectos.

2.6 ESPECIFICACIONES DEL PROYECTO

Cuando en una organización se plantea, o se descubre, una nueva necesidad que se pretende resolver con un sistema informático, será necesario establecer previamente un estudio de viabilidad donde se valore, en la medida en que se pueda, el esfuerzo necesario para que el desarrollo del nuevo sistema pueda llegar a construirse. En este sentido el director del proyecto deberá ser capaz de preparar un documento en el que se plasmen, de modo formal, los objetivos del proyecto, así como las directrices generales de planificación, estimación y gestión del proceso del proyecto.

En este documento se deberá:

32 PL A N IFIC A C IÓ N Y G E ST IÓ N D E S IST E M A S IN FO R M Á T IC O S

• Establecer el ámbito y alcance del proyecto, o lo que es lo mismo, definir los productos a obtener.

• Establecer los criterios de terminación del proyecto.

• Efectuar un balance del estado actual mediante la identificación de los problemas existentes y de las necesidades futuras.

• En

la

algunos

casos

se

puede

diseñar

un

modelo

que

represente

situación anterior.

• Concepción de los objetivos y definición de los requisitos a satisfacer.

• los

Documentar

supuestos

sobre

los

que

se

han

producido

las

estimaciones.

• Estudio de la viabilidad de las diferentes alternativas de la construcción.

Pasamos a comentar los beneficios de obtener este documento de objetivos: por una parte se debe de considerar que los proyectos tienen dificultades al arrancar y al terminar. Las dificultades de comienzo tienen una consecuencia clara en la realización del proyecto ya que, en función del desarrollo de las conversaciones iniciales y de la coyuntura en la que se haya planteado la necesidad del proyecto, conducen a que los elementos de análisis previos hayan podido estar distorsionados y la información de partida, por lo tanto, puede ser inconsistente.

Por otra parte, los criterios de terminación son básicos para poder establecer las responsabilidades finales en una actividad que siempre va a tener que estar siendo mantenida. Este factor será mucho más importante en tanto que la necesidad de un proyecto nazca de una empresa cuya relación con el grupo de desarrollo sea, o no, ajena al mismo. Estos factores, o criterios de terminación, deben de ser discutidos por ambas partes y consensuados para que, finalmente, quede perfectamente escrito en el documento de alcance o especificaciones del proyecto.

Con este documento, tanto la dirección como el grupo de desarrollo, debe de tener suficiente información como para saber en qué se están comprometiendo, y si pueden o no aceptar el proyecto, sus plazos y sus cláusulas sin incurrir en penalizaciones que pueden ser muy perjudiciales tanto para el equipo de desarrollo como para la organización origen del proyecto.

2.7 EL CICLO DE

VIDA I)E UN PRODUCTO INFORM ÁTICO

El ciclo de vida es el conjunto de fases por las que debe pasar un proyecto de desarrollo de un sistema de información desde su concepción inicial hasta que el sistema deja de utilizarse o se transforma en otro.

C A P ÍT U L O 2: D EFIN IC IO N ES UÀ SICA S

33

Existen diferentes modelos de ciclo de vida que pueden aplicarse en función del tipo de sistema a desarrollar. Así, el ciclo de vida denominado "vertical" sería adecuado para sistemas pequeños, con gran urgencia de desarrollo y una relativa corta esperanza de vida. El "ciclo evolutivo" contempla la posibilidad de desarrollar una primera versión básica que se irá ampliando en versiones sucesivas. El "ciclo de software estándar", por su parte, es adecuado cuando se trata de seleccionar y adaptar un paquete de software existente.

Sin duda, el modelo de ciclo de vida más completo es el denominado "clásico" o "en cascada" (waterfall model). Este ciclo establece una serie de fases, al finalizar las cuales se obtiene una serie de productos (documentos, diagramas, programas) que permite evaluar lo realizado hasta ese momento y continuar con la fase siguiente o modificar algunos aspectos de las fases anteriores (proceso de realimentación). En la figura 2.3 se muestra un ejemplo de modelo de este tipo, adaptado del propuesto por la metodología MÉTRICA versión 3.

Planificación listn

Ajiálisis de R equisitos del Sistem a

Í T

T

T

ANALISIS DEL SISTEM A

Especificación

Funcional del

Sistem a

_

.-sr srx r r - -

•"

D iseño

del Sistem a

C onstrucción

del

Sistem a

Im plantación

del

Sistem a

Figura 2.3. Fases del ciclo de vida de un Sistema de Información

34 PLA N IFIC A C IÓ N Y G ESTIÓ N DE SISTEM A S IN FO R M Á TICO S

Aunque en la segunda parte de este texto se describen con detalle todas las actividades a realizar en cada fase, a continuación se indica someramente el objetivo de cada una de ellas:

• Planificación Estratégica: No se considera estrictamente como una fase del ciclo de vida, ya que su existencia es opcional (no es necesaria si se desarrollas un sistema aislado), y no afecta a un sólo sistema. Si existe, su objetivo es adecuar los objetivos estratégicos de la organización (de usuario) y la información necesaria para soportar dichos grandes objetivos. Para tal labor se hace necesaria una metodología de planificación de sistemas que abarque a toda la organización y exija considerar una serie de conceptos que desbordan el marco específico de una Metodología de Desarrollo de Sistemas, por lo que no se tratará en este texto. No obstante, si se ha llevado a cabo, el producto final que se habrá generado, será la definición de los sistemas de información que se deben desarrollar para satisfacer los objetivos estratégicos de la organización. Por tanto, la parte de este documento que haga referencia al sistema concreto que se vaya a desarrollar, puede ser el punto de partida para la siguiente fase, la de Análisis del Sistema.

• Fase de Análisis: El objetivo de esta fase es el estudio de las necesidades de información que debe satisfacer el sistema a desarrollar, elaborando una serie de especificaciones formales que describan la funcionalidad del mismo y que permitan abordar con garantías la siguiente fase (Diseño). Esta fase de Análisis se puede estructurar en dos sub-fases claramente diferenciadas, en las que se lleven a cabo tales actividades:

o

Análisis de Requisitos del Sistema: Se trata de establecer el alcance, los objetivos y requisitos del sistema, examinando las posibles alternativas que podrían solucionar las necesidades del usuario (cliente) y recomendar una de ellas. Al final de esta sub- fase se obtiene un documento denominado "Documento de Requisitos del Sistema" (DRS).

o

Especificación Funcional del Sistema (conocida tradicionalmente como "Análisis Funcional"): Una vez aceptado formalmente el documento anterior por las partes (organización de desarrollo-organización de usuario), se elabora un conjunto de especificaciones formales que describan la funcionalidad del sistema, estableciendo los subsistemas en que se descompondrá, definiendo los datos que utilizará y las interfases de usuario.

C A P ÍT U L O 2: IJHFIN ICIONH S B A SIC A S

35

También se planificarán las pruebas que deberá superar el sistema, se estimará la relación coste/beneficio para comprobar si interesa su construcción y se establecerán los plazos de entrega del sistema. Todo ello se recoge en dos documentos, denominados "Documento de Especificación Funcional del

Sistema"

(DEFS)

y

"Documento

de

Pruebas

del

Sistema"

(DPS).

• Fase de Diseño (conocida tradicionalmente como "Análisis Orgánico"):

El objetivo de esta fase es obtener un conjunto de especificaciones que contemplarán los aspectos físicos del sistema, considerando las características tecnológicas del entorno específico en el que se implantará, que constituirán el punto de partida para la construcción del sistema. Al final de esta fase se obtienen el "Documento de Diseño Técnico" (DDT) y el anterior "Documento de Pruebas del Sistema"

(DPS) con

las ampliaciones relativas a la definición del entorno de

pruebas.

• Fase de Construcción: El propósito de esta fase es, a partir de las especificaciones de diseño, la obtención del sistema completamente construido y probado, listo para ser implantado en la organización de usuario. También durante esta fase se desarrollará el conjunto de procedimientos y se llevará a cabo la formación necesaria que permitirá, tanto al personal del área de usuario final como al personal del área de explotación o proceso de datos (si existe), la utilización óptima del sistema. Además del software correspondiente, al final de esta fase también se obtendrán los siguientes documentos:

"Documentación Técnica de Programación" (DTP), "Manual de Usuario" (MU), "Manual de Explotación" (ME), "Documento de Pruebas del Sistema" (DPS), ampliado con los informes de las pruebas unitarias, de integración y globales.

• Fase de Implantación: El objetivo de esta última fase es la puesta en servicio del sistema construido y conseguir su aceptación final por parte de los usuarios del mismo, para lo cual se tratará de hacer ver a éstos, mediante demostraciones formales (pruebas de aceptación), que el sistema cumple todos los objetivos y requisitos para los que fue desarrollado. En esta fase se incluye la ejecución y el mantenimiento del sistema, con lo que su duración se prolongará hasta que el sistema deje de utilizarse o sea sustituido por otro.

P L A N IF IC A C IÓ N Y G E ST IÓ N D E SIST E M A S IN FO R M Á TICOS

CAPÍTULO 3

FACTORES DE DIMENSIÓN

El análisis de los problemas a resolver y los medios a utilizar para realizar un determinado sistema constituyen una de las fases fundamentales en el desarrollo del estudio, pues es en ese momento cuando la toma de conciencia del cambio previsto debe de ser asimilado por los usuarios del futuro servicio. En este momento se debe de efectuar una valoración estimada de los distintos recursos que se deben de aplicar a la consecución del citado proyecto.

En cualquier caso, para llevar a buen término un proyecto de desarrollo de software, es necesario comprender el ámbito del trabajo a realizar, los recursos requeridos, las distintas tareas que se deben de ejecutar, el esfuerzo a emplear y el calendario que debe de cumplirse. La planificación del proyecto de software es un primer paso en el proceso de la ingeniería del software y nos proporcionará este conocimiento. Pero, al inicio de la planificación, el director se encuentra con un fuerte dilema: necesitaría una estimación sólida de la estimación cuantitativa, pero conocer tales estimaciones son fruto de un análisis detallado que puede durar incluso meses, sin embargo las estimaciones se necesitan "ya".

El objetivo de la planificación del proyecto software -y la definición de tal proyecto está incluido en sí mismo- es el de suministrar un área de trabajo que permita al director hacer razonadas estimaciones de recursos, costes y métodos necesarios para terminar el proyecto con los niveles de satisfacción deseados. Estas estimaciones se efectúan sin un plazo de tiempo conveniente y deberán ajustarse a lo largo del desarrollo del mismo según los progresos que se vayan realizando.

Como se ha mencionado anteriormente, el objetivo e la planificación se alcanza a través de un proceso de descubrimiento de información que lleve a estimaciones razonables, pero no se puede emplear las mismas técnicas y métodos para proyectos de un esfuerzo de unos centenares de horas/hombre o de varios miles de horas/hombre.

3S

P L A N IF IC A C IÓ N Y G E S T IÓ N DF. SIST E M A S IN FO RM Á TICOS

Una de las actividades necesarias para poder estimar en un primer análisis el esfuerzo es tratar de delimitar el ámbito del software, para ello se valorarán las funciones que deben de realizarse y el rendimiento que se espera de tales funciones, este análisis se verterá en un documento que deberá ser lo menos ambiguo y lo más claro posible para que lo entiendan los distintos directores a los que afecte la materia. En este documento se deben delimitar los datos cuantitativos que sean necesarios para definir el alcance, (por ejemplo se delimitará el número máximo de usuarios que accederá de forma concurrente al sistema, el tiempo máximo de respuesta, el tamaño de cada uno de los ficheros, etc.). También se describirán las restricciones del tiempo de procesamiento, las interfaces de usuario, la fiabilidad, etc.

El director del proyecto, con el informe anterior, tendrá una primera aproximación para estimar el esfuerzo total para acometer el proyecto y, si este documento ha sido cuidadosamente elaborado, tendrá una descripción de las tareas a desarrollar con una primera documentación que puede ser firmada para fijar un primer marco de actuación.

Con este documento podrá hacer una estimación razonada del esfuerzo a realizar en cada una de las etapas del ciclo de vida del proyecto, es decir, que tiempo estima que se ha de dedicar al análisis funcional, cuanto al diseño, cuanto al desarrollo, etc.

La segunda fase para efectuar una posible planificación del proyecto es la estimación de los recursos que son necesarios para acometer el esfuerzo de desarrollo de software anteriormente señalado: por una parte los recursos máquina o herramientas necesarias para facilitar el desarrollo de las distintas tareas y, por otra parte, las personas que utilizan esas máquinas y/o herramientas. Cada recurso se debe especificar por cuatro características:

• El recurso en sí (su descripción)

• Disponibilidad en sí

• Las distintas fechas en las que se le requiere

• La duración a partir de cada fecha de comienzo

Las dos últimas características son en sí una tabla múltiple y, veremos más adelante, que tales fechas y duraciones son fluctuantes en un tiempo concreto debiendo ser su disponibilidad -referida a esa fecha- lo más pronto posible.

C A P IT U L O 3: FA C TO R ES D E D IM ENSIÓN

39

Se discutirá en clase los factores que inciden en los recursos humanos como pueden ser la motivación, los calendarios laborales, las fiestas, la formación del personal, las distintas categorías, etc.

Por otra parte se valorarán especialmente los recursos de hardware, haciendo referencia al propio ordenador como un potencial importante en la informática. Se considerarán tres aspectos básicos en el ordenador durante la planificación del proyecto software: el sistema de desarrollo, la máquina objetivo y otros elementos hardware del nuevo sistema.

Los recursos software los utilizaremos del mismo modo que se utilizan las máquinas y utilizaremos software para construir nuevo software. En este momento se deberán mencionar tanto las herramientas actuales (herramientas orientadas al código, orientadas a la metodología, orientadas a la construcción de prototipos y generadoras de código fuente) como futuras (sistemas expertos para el proceso de lenguaje natural, ayudas colegiadas en la toma de decisiones en el mismo proyecto, etc.).

3.1 ESFU ER ZO TO TA L

D ED IC A DO AL SOFTW ARE

Como veremos a lo largo de este libro, las estimaciones de recursos, de plazos y de la calidad esperada del producto suelen estar bastante distantes del objetivo final del cliente o de la organización usuaria del sistema de información. En general todo se traduce en precisar un equilibrio en el triángulo del triple compromiso: Calidad, coste y calendario.

Figura 3.1 El triángulo del triple compromiso

Al inicio del proyecto es normal que se trabaje con una cierta incertidumbre en cuanto a las estimaciones que se van aclarando conforme se consumen las fases anteriores. Sin embargo es fundamental considerar el

4 0

P L A N IF IC A C IÓ N

Y G E S T IÓ N

D E S IS T E M A S IN FO R M Á T IC O S

equilibrio de compromiso entre los tres aspectos de gestión en la planificación de proyectos. De todas formas, cuando la calidad forma parte de la organización, o se asume desde ciertos estándares, es mejor hablar de producto desde el punto de vista de tamaño, es decir, desde el número de cosas que se espera que se realicen hasta la finalización del proyecto. En el producto se incluyen todos los aspectos que intervienen en el software final, desde los requisitos hasta los programas ejecutables pasando por todos los casos de prueba, la documentación del sistema y los criterios de usabilidad.

Es normal que el proyecto comience con cierta desidia, de tal suerte que el esfuerzo total dedicado al proyecto sea poco relevante. En algunas ocasiones se teme por los grandes riesgos que el estado cambiante de la tecnología introduce o por la incorporación de cambios dentro del propio proyecto, sin embargo es necesario hacer énfasis en que el coste que pueda resultar debido a la falta de planificación efectiva que hace que no se acometa el proyecto con toda la fuerza productiva, puede ser muy alto si se quiere mantener el compromiso de los plazos.

Cuando nuestros interlocutores nos ayudan a descubrir sus requisitos tendremos que hacer una cierta estimación entendida como una cierta

estimación se basa en

incertidumbre que pretender “objetivizar” el coste

emplear datos históricos bien definidos, precisos y exactos que nos llevará a un modelo basado en experiencias que necesita de la habilidad de la persona que

la efectúa para no tratar de subjetivizar las ideas de la parte contratista.

La

Los datos de referencia suelen ser los de la propia empresa que parecen asemejar las circunstancias pero, se deben de considerar, los datos extemos para hacer estimaciones comparativas.

Cuando se dispone de una cierta estimación tendremos que hacer un planteamiento al cliente de la organización usuaria para tratar de llegar al compromiso sobre los vértices del triángulo de tal suerte que, si no se puede satisfacer alguno de los extremos de sus necesidades, seguramente el proyecto no se podrá desarrollar en esos parámetros. Nuestro trabajo como jefes de proyecto será facilitar alternativas a cada uno de los puntos para que el equilibrio nuevamente se establezca.

Es muy importante en esta fase de la negociación considerar el esfuerzo total dedicado al software: en general todas las fases de la Planificación y Gestión de Sistemas de Información así como su desarrollo son esfuerzos de software.

C A P ÍT U L O 3: FA C TO R ES D E D IM E N SIÓ N

3.2 DISTRIBUCIÓN DEL ESFUERZO

41

Antes de entrar en la parte técnica de comprender cómo se lleva a buen fin los procesos de planificación y gestión de sistemas de información vamos a fijarnos en una metodología muy próxima, en nuestro caso a la Metodología Métrica v.3 creada por el Consejo Superior de Informática del Ministerio de Administraciones Públicas, que ofrece a las organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software dentro de un marco, que como dice la propia metodología, permite alcanzar los siguientes objetivos:

• Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.

• Dotar a las Organizaciones de Productos Software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requerimientos.

• Mejorar la productividad de los departamentos de Sistemas y tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y considerando la reutilización en la medida de lo posible.

• Facilitar la comunicación y entendimiento entre los distintos participantes en la producción del software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.

• Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

Métrica V.3 tiene un enfoque orientado al proceso siguiendo la tendencia de los estándares que se encaminan en este sentido por lo que se ha enmarcado dentro de la norma ISO 12207 que se centra en la clasificación y definición de los procesos de ciclo de vida.

Dentro de la metodología Métrica Versión 3, se estructura un apartado importante bajo el epígrafe de Planificación de Sistemas de Información, cuyo enfoque, al no estar soportado por la norma ISO 12207, se ha determinado en

42 P LA N IF IC A C IÓ N

Y GESTIÓN DE SISTEM A S IN FORM ÁTICOS

el estudio de los avances surgidos en esta área de interés junto con las presiones de la alta competitividad y la naturaleza de adaptación al cambio a los que están sometidas la mayoría de las Organizaciones. Este entorno fuerza a que cada día se consideren con mayor énfasis el requerimiento de disponer de sistemas de información muy flexibles para poder adaptarse a las exigencias que demanda el mercado y con una rapidez de adaptación hasta ahora casi inimaginable.

En particular, dentro del apartado Planificación de Sistemas de Información, Métrica v.3 establece una serie de actividades, que se describen el la figura 3.2, para alcanzar un objetivo claro que es "la obtención de un marco de referencia para el desarrollo de sistemas de información que responda a los objetivos estratégicos de la organización ”.

Este alineamiento de los Sistemas de Información con la estrategia de la organización donde se implica directamente la alta dirección en la propuesta de solución va a presentar una serie de ventajas, como son:

• Se creará una perspectiva más horizontal de los procesos dentro de la Organización donde los interesen generales tendrán una mayor importancia en contra de cada uno de los intereses particulares que podrían desvirtuar los objetivos estratégicos y que obligará a un estudio minucioso de los procesos.

• La implicación de alta dirección permitirá disponer de los recursos suficientes que permitirá ofrecer resultados dentro del calendario acordado.

• La prioridad de los procesos se verá fortalecida por el apoyo de todos los miembros participantes dentro de las líneas establecidas en el Plan Estratégico

Con las ideas anteriores podemos lanzarnos a tratar de efectuar un primer esbozo de lo que será el proyecto, al menos en sus límites, para poder efectuar un cálculo inicial del esfuerzo necesario para poder desarrollar eficientemente el proyecto. De esta forma nos encontramos en disposición de introducir el término de Planificación del Proyecto entendida como la ciencia que suministra un escenario al director para poder efectuar estimaciones razonadas de los recursos, poder efectuar un presupuesto de costes, obtener visibilidad para determinar los métodos necesarios a utilizar para terminar el proyecto y, en resumen, poder disponer de todo lo anterior para realizar el proyecto con un máximo de eficiencia.

C A PÍT U L O 3: FA C T O R E S D E D IM E N SIÓ N

43

Hemos señalado en el capítulo anterior la necesidad de poner límites al proyecto y, en particular, tenemos que delimitar el ámbito del software en el sentido de marcar claramente lo que se quiere que efectúe el nuevo sistema y lo que no se desea mecanizar en el proyecto actual ya que muchos proyectos 110 se terminan, o se terminan fuera de plazo, por 110 saber cuánto falta para que se termine de desarrollar. E 11 este sentido tenemos que manifestar que el proyecto termina cuando se ven satisfechos todos y cada uno de los requisitos (software o de cualquier otra índole) del sistema.

Para efectuar la planificación del proyecto se debería disponer de una serie de datos cualitativos y cuantitativos en forma de requisitos (tiempo máximo de

que

desgraciadamente no se conocerán hasta una vez avanzada la planificación, y sin embargo, dentro de nuestra disciplina, tendremos que efectuar más de alguna planificación tentativa antes de conocer el proyecto con a un nivel de detalle suficiente. Tendremos que aventurarnos efectuando algunos tipos de consideraciones sobre el tipo de proyecto que se quiere realizar y, en muchos casos, fundamentalmente en fases tempranas de la planificación, tendremos que efectuar ensayos de distinto tipo de actuaciones para acometerlo.

transacción, número de usuarios máximos, interfases gráficas

)

Con el documento de requisitos (más o menos detallado) y con la lista de objetivos, así como con un posible calendario “forzado”, el director podrá estimar, en una primera fase, el esfuerzo a desarrollar en cada etapa. Con posterioridad podrá obtener una especificación de los recursos que serán necesarios para acometer el proyecto.

3.3 CATEGORÍAS DE PROYECTOS DE INGENIERÍA DEL SOFTWARE SEGÚN SUS “DIMENSIONES”.

Antes de continuar con la especificación de recursos vamos a ensayar una clasificación de los proyectos de ingeniería del software según su dimensión. Para ello vamos a considerar las necesidades de recursos según el tipo de problema a resolver.

Decíamos, cuando habábamos del triángulo del proyecto, que las dimensiones de todo proyecto son calendario, coste y cantidad de producto. La dimensión del proyecto puede determinarse dentro de las variables de complejidad, de riesgo, de calidad y de tamaño, como veremos a continuación.

44 PLA N IFIC A C IÓ N Y GEST IÓN DE SISTEM AS IN FORM ÁTICOS

El factor complejidad puede ser tratado, a su vez, desde varios puntos de vista: Por una parte podemos hablar de la complejidad de datos, de métricas, algorítmica o de operaciones, ciclomática y de la arquitectura en sí. La complejidad de datos normalmente expresa la dificultad, o sencillez, de un determinado módulo que se mide en función de los datos de entrada y de los salida. En general la complejidad de los datos no se considera en el momento de efectuar una clasificación de los proyectos por categorías. Lo mismo ocurre con la complejidad algorítmica y la ciclomática que trata de ver la complejidad de la lógica de uno o varios programas. Otro caso es la complejidad de la arquitectura del sistema y las relaciones de dependencia que se pretendan

la hora de

establecer1 que definen un cierto acoplamiento que es importante a valorar los proyectos.

La dimensión del producto visto desde la perspectiva del factor riesgo trata de clasificar los proyectos según la probabilidad de impacto en el negocio y las consecuencias que de cumplirse el impacto se derivarían del sistema de información que se desea crear frente a la organización. Considerar los riesgos dentro de la fase de ejecución del proyecto es muy importante ya que, de satisfacerse el riesgo, posiblemente toda la planificación del proyecto se vería afectada por el propio impacto de una serie de amenazas en los puntos más vulnerables.

El factor calidad puede clasificar los proyectos según el resultado en cuanto al buen funcionamiento en el tiempo del sistema de información creado. Así no es lo mismo los requisitos de calidad que se establecen en la construcción de un software comercial como en el software que gobierna una planta nuclear donde, por ejemplo, un mal funcionamiento de algún componente puede acarrear problemas de salud a los individuos. Normalmente las máximas exigencias de calidad se demandan en software empotrado en ciertos equipos electrónicos que, en caso de funcionamiento erróneo o indisponibilidad, pueden traer como consecuencia, la pérdida de vidas humanas.

La dimensión tamaño es la mejor pauta para clasificar los distintos tipo de proyectos dentro de una empresa que normalmente efectúa trabajos más o menos parecidos dentro de las mismas prácticas ingenieriles. De esta forma es posible hablar de proyectos grandes, medianos o pequeños, en función del número o cantidad de funcionalidades previstas, del número de líneas de programa fuente a producir, del tiempo de desarrollo y, en general, de la cantidad de esfuerzo a invertir en el proyecto. Es de señalar que esta

1Zhao J. “On assessing the Complexity of Software Architectures”, Proccedings of Lnteligent Software Archileclure, ACM, pp. 163-167, Orlando, Florida, 1998.

C A PÍTU LO 3: FA CTORES DE D IM E N SIÓ N

45

característica suele ser con la que más frecuentemente se clasifican los proyectos a la vez que anticipamos que a mayores proyectos en tamaño más probabilidad de no cumplir los plazos de entrega del proyecto.

3.4 DISTRIBUCIÓN DEL TIEMPO A LO LARGO DEL CICLO DE VIDA DE UN SISTEMA INFORMÁTICO.

En los proyectos informáticos se da el hecho de que la cantidad de recursos puestos a disposición del director no es constante a lo largo del tiempo. Suele ser normal que las primeras fases de tanteos de búsqueda de solución, presupuestos iniciales no definitivos y valoración del alcance, lo realice un número muy reducido de personas. El objetivo fundamental de este reducido equipo de personas será tratar de fijar el proyecto y establecer, dentro de lo posible, las líneas básicas de actuación. Como objetivos secundarios se

intentará recoger toda la información del cliente tratando de alcanzar las líneas generales de sus necesidades para dar cumplimiento de ciertas consideraciones comerciales entre las que se encuentra elaboración de la posible oferta económica de servicios, las reglas que detallen la forma de facturar y se ensayará, igualmente, a establecer los criterios de terminación. En esta fase se suele exigir, por parte del contratista, que se establezcan ciertos patrones de calidad, de seguimiento y de seguimiento del proyecto a fin de garantizar el

perfecto

desarrollo

del

mismo

dentro de los patrones de seguridad de la

empresa.

En esta fase de conocimiento de las necesidades del cliente suelen tener una importancia muy alta las gestiones comerciales y los acuerdos tácitos que se alcancen. Es normal que se establezcan penalizaciones en caso de no cumplimiento de alguna de las partes y que se contemplen todas las especificaciones del contratista y se describa un primer documento con la especificación del producto haciendo un buen desglose del proyecto.

Una vez que el proyecto avanza y se cuenta con la aprobación del cliente trataremos de adecuar los objetivos estratégicos de la organización y la información necesaria para soportar esos objetivos. El proceso anterior puede ser un punto de partida para la Metodología de Desarrollo de Sistemas. Con esta información se intuye una posible “luz de salida”, se incorporará más gente a realizar labores de análisis, que aún constituirá un grupo pequeño de personas, cuyo espacio en el tiempo puede dilatarse pero que no supone el total de las fuerzas del equipo del proyecto.

46 P L A N IF IC A C IÓ N

Y G ESTIÓ N DE SIS T E M A S IN FO R M Á T IC O S

La duración de esta fase es bastante más medible que la anterior. El director ya 110 tiene que someterse a un número alto de variables cuya respuesta está en manos del cliente y, estudios realizados demuestran que los recursos trabajan en el proyecto con más continuidad.

En la fase de diseño arquitectónico el grupo es más numeroso, aunque todavía es pequeño comparado con el personal que interviene en el diseño detallado. Posteriormente se incorpora un número alto de personas y el proyecto trabaja con un máximo de recursos que poco a poco se irán reduciendo hasta la puesta en marcha del sistema y el posterior mantenimiento.

Es de señalar que la etapa inicial de mantenimiento puede requerir un número elevado de personal, aunque este número deberá disminuir en poco tiempo, si no existen mejoras o adaptaciones importantes, permaneciendo constante con tendencia a la disminución a partir de un cierto momento.

Como se verá en el capítulo noveno la distribución de esfuerzos frente al tiempo en el desarrollo de sistemas informáticos sigue el modelo de la función de Rayleight representada en la figura 3.2.

3.5 ESTIMACIÓN DE RECURSOS

Una vez fijado el calendario y la cantidad de producto a desarrollar, y habiendo efectuado un estudio sobre la viabilidad del proyecto, tenemos que fijarnos en la estimación de los recursos necesarios para poder efectuar el proyecto.

C A P ÍT U L O

3:

F A C T O R E S

D E D IM E N S IÓ N

47

Dentro de los recursos nos encontramos con dos tipos fundamentales de

recursos:

• Recursos humanos

• Recursos materiales

Dentro de los recursos humanos, nos ocupamos de las personas que trabajan para nuestra organización y de la que necesitaremos tener información sobre su formación, su capacidad y su actitud frente al proyecto para poder determinar el tipo de tareas que se les puede asignar de forma individual y colectiva. Esta información se puede organizar en forma de fichas, mecanizadas o no, sobre las que se tengan datos de la persona en sí misma, de

su disponibilidad tanto general como particular para el proyecto, lo que llevaría

a poder informar de las distintas fechas en las que se le requiere cada recurso

para cada proyecto concreto o, en su caso, la duración a partir de cada fecha de comienzo.

Existen muchos factores que inciden en los recursos humanos como pueden ser la motivación, la especialización y entrenamiento, los posibles calendarios y la normativa laboral vigente en cada entorno concreto que puede establecer unas limitaciones que el director debe de conocer en cada momento. Así, las fiestas laborales locales o autonómicas se deben de considerar en la planificación de reuniones o en las cargas de trabajo de cada uno de los individuos que forman el equipo del proyecto. Igualmente puede suceder con las restricciones debidas a la indisponibilidad de los recursos por bajas temporales, enfermedades o cualquier tipo de discontinuidad en el trabajo, lo que nos forzará a considerar los tiempos perdidos por este tipo de situaciones.

Un factor importante en las restricciones de la planificación puede deberse

a la existencia de diversas categorías laborales que obligarán, de hecho, a que

cada una de las personas del equipo de trabajo quiera desarrollar la tarea propia de su categoría, en algunas ocasiones sin ningún tipo de flexibilidad.

Cada día se tiene mayor conciencia de la independencia de algunos recursos humanos para satisfacer las necesidades de implementación de soluciones y se considera la conveniencia de utilizar recursos propios o recursos ajenos, sobre todo en algunos proyectos que, por su naturaleza, exijan una mayor cantidad de personas durante plazos relativamente cortos de trabajo con las ventajas que supone el hecho de contratarlos como miembros de otra empresa.

48 P L A N IF IC A C IÓ N

Y G ESTIÓ N D E S IS T E M A S IN FO R M A TIC O S

Entre los recursos materiales deberemos de considerar, fundamentalmente

el entorno de desarrollo y el ordenador objetivo que, con sus particularidades

de sistema operativo y bases de datos, puede no tener la misma configuración que las herramientas del “banco de trabajo" donde se desarrolla el sistema de información. En otros casos se consideran recursos algunos elementos hardware que se integrará dentro del proyecto pero que su disponibilidad, por diversas causas, no es inmediata.

Dentro de las posibilidades de utilización de algunos recursos que no disponemos está la de alquilar horas de recurso material (normalmente hardware) en alguna instalación similar a la de la organización cliente donde, de forma programada, se puedan probar los módulos que se están construyendo

y donde se pueda verificar el avance del proyecto.

Una importancia extraordinaria en la construcción de sistemas de información modernos tienen las herramientas software con las que construimos el nuevo sistema que, posiblemente, a lo largo de la fase de construcción del sistema tengan que ser sustituidas por otras herramientas futuras, lo que nos llevará a estimar esfuerzos de conversión y de formación en las nuevas versiones de software de base.

Otro punto interesante a la hora de asignar los recursos es la disponibilidad de los mismos:

• Los recursos son escasos

• Los recursos no siempre están disponibles

• A veces no se puede conseguir un recurso a cualquier precio

Muchas veces la duración óptima de la tarea, o su eficiencia, no depende del número de recursos empleados como veremos en el capítulo noveno. En ese capítulo estudiaremos que existe una relación entre coste y duración de cada actividad y se verá que hay un número de elementos a dedicar en cada fase del proyecto de forma que se optimice el binomio tiempo, coste.

El proyecto suele ser muy vulnerable ante una multitud de amenazas que pueden hacer peligrar el desarrollo del mismo. En el caso de que una amenaza impacte en una vulnerabilidad del proyecto tendríamos una probabilidad de riesgo en el proyecto por lo que el director tendrá que considerar planes de solucionar “contingencias” ante la ausencia repentina de recursos tratando de que el tiempo se convierta en un recurso.

C A P ÍT U L O

3:

F A C T O R E S

D E D IM E N SIÓ N

49

En general el proyecto se puede gobernar cuando existe información

compartida

responsabilidad, tenga conocimiento de las tareas programadas y del estado de las tareas realizadas, para lo cual son muy útiles los métodos técnicos que en forma de normas y procedimientos, marcan la ruta a seguir en el avance del mismo.

su

del

mismo,

de

tal

modo

que

todo

el

equipo,

según

En los capítulos ocho y diez volveremos sobre el uso de los recursos y la estimación de los costes con métodos estadísticos; haremos estimación de los

costes en función del tipo de recurso, la cantidad de recursos, de la duración de la actividad, todo ello con técnicas de estudio fijando los escenarios más probables, más pesimistas y más optimistas. Todo ello, junto con el tratamiento de los costes directos: precio, cantidad, eficiencia, duración de la tarea,

oportunidad del momento, etc

,

nos llevará a la asignación al proyecto.

(

50

PLANIFICACIÓN Y GESTIÓN DE SISTEMAS INFORMÁTICOS

(

<

(

(

(

(

CAPÍTULO 4

FACTORES DE PRODUCTIVIDAD

El objetivo fundamental de la presente unidad temática es estudiar el conjunto de métricas que se utilizan habitualmente en cualquier disciplina de ingeniería ( y que, por tanto, en la planificación de proyectos informáticos deben de ' utilizarse. En particular nos ocuparemos de las métricas de productividad como . medidas del rendimiento de la construcción de software en función del esfuerzo aplicado y estudiaremos cómo se puede mejoran la productividad en base al empleo de herramientas que nos ayuden en la automatización de tareas.

 

<

Antes de continuar listaremos la tabla los factores que afectan a la

/

^

productividad en un proyecto informático y que tendrán que tenerse en cuenta a la hora de diseñar métricas y herramientas:

• Factores humanos. Experiencia y tamaño del equipo de desarrollo.

• Factores

del

problema.

Complejidad

del

sistema

y

cambios

de

requisitos durante el desarrollo.

 

^

• Factores del proceso. Técnicas utilizadas (análisis y diseño) y gestión. (

• Factores del producto. Rendimiento y fiabilidad del sistema.

• Factores de los recursos. Disponibilidad de recursos HW, SW para el

(

desarrollo

(

4.1 METRICAS DE PRODUCTIVIDAD DEL SOFTWARE.

'

í

La medida es fundamental para cualquier actividad. Lord Kelvin dijo: "Cuando

puedes medir lo que estas diciendo, y expresarlo en números, sabes algo sobre ello; pero citando no puedes medirlo, cuando no puedes expresarlo con números, tu conocimiento es escaso e insatisfactorio: puede ser el principio del conocimiento, pero en tus pensamientos, apenas estás avanzando hacia el

'

escenario de la ciencia”. Durante la década pasada se ha tomado al pie de la

*

 

(

;

52 P L A N IF IC A C IÓ N

Y G E S T IÓ N DE S ISTEM A S IN FO R M A TIC O S

letra esta afirmación de Lord Kelvin pero lia traído algunos desencantos que han suscitado una gran polémica.

Pero cuando tratamos de realizar un nuevo proyecto, normalmente irrepetible, no valen de mucho los métodos empíricos sino más bien el conocimiento histórico. Preguntas del tipo ¿Cómo se ha comportado mi equipo de desarrollo en anteriores proyectos? ¿Los datos anteriores cómo pueden ser extrapolados ahora?

En la exposición de la presente lección se hará una presentación de las distintas métricas del software para entender en que puntos se ajustan mejor las medidas de productividad. Pero debemos de considerar las razones la medida del software: El software se mide para:

• Indicar la cantidad de producto

• Evaluar la productividad de la gente que desarrolla ese producto

• Aseguramos los beneficios derivados de nuevos métodos

• Justificar la adecuación de nuevas herramientas

Por ello se estudiarán las distintas métricas del software y se catalogarán, como en el mundo de la ingeniería, en dos grandes categorías: las medidas directas (por ejemplo: la longitud de un programa en sentencias fuente) y las medidas indirectas (por ejemplo: la calidad de tal programa fuente), las medidas directas son fáciles de obtener, al fin y al cabo es establecer un convenio que ayude a identificar el "metro" a utilizar, pero las medidas indirectas como la calidad, eficiencia y mantenibilidad son más difíciles de obtener.

Dentro

de nuestro

mundo, y

para asegurar

el

correcto

empleo de

los

términos, se pueden clasificar las distintas métricas en:

• Métricas orientadas al tamaño

• Métricas orientadas a la función

• Métricas orientadas a la persona

La implantación de métricas genera beneficios para la empresa. Estos beneficios pueden ser en la reducción de costes, en la mejora de la productividad, el incremento de las ventas motivada por la reducción de los ciclos de desarrollo. También se obtienen beneficios derivados de la satisfacción del cliente que se sentirá recompensado por un software de calidad y que recomendará al equipo de desarrollo a otros colegas.

C A P ÍT U L O 4: FA C TO R ES DE PR O D U C T IV ID A D

53

Frente a los objetivos del negocio podemos asegurar que la iniciación de programas de métricas del software, proveerá la asistencia de asegurar, monitorizar e identificar acciones de mejora para alcanzar un conjunto de objetivos de calidad y productividad de la compañía.

El programa de métricas, a su vez, camina muy relacionado con el proceso

de desarrollo ya que las métricas se definen para medir características cuantitativas de rendimiento en determinados puntos del proceso.

Es importante considerar que el proceso de implantación de métricas deberá ser realimentado de tal suerte que los datos obtenidos de la medida provean una guía para mejorar la identificación de acciones a mejorar en el proceso de desarrollo de sistemas de información1.

4.2 HERRAMIENTAS QUE MEJORAN LA PRODUCTIVIDAD.

La mayor parte de los conocimientos sobre el funcionamiento de una empresa, y sobre la influencia de la información sobre ese funcionamiento, reside en la mente de un número relativamente reducido de personas. Para intentar conservar y explotar este conocimiento, a lo largo del tiempo, las organizaciones han dedicado esfuerzos en construir modelos donde poder efectuar un tratamiento documental de esa rica información. El objetivo de este tipo de modelos es poder representar, en muchos casos de forma simbólica, los conocimientos de esas personas clave con la esperanza de que todo el personal que interviene en los distintos procesos de negocio pueda usar, de una forma fácil y completa, los conocimientos acumulados por esas personas.

A lo largo del tiempo se han concebido diversas metodologías para

construir estos modelos. Esas metodologías suelen consistir en una combinación de técnicas de diagramas y textos explicativos. Los diagramas representan visualmente las actividades comerciales y el uso que se hace de la información en apoyo de las mismas. Los diagramas también describen

gráficamente los atributos empleados en el diseño y desarrollo de sistemas.

Las técnicas de diagramas emplean iconos para representar los distintos componentes de las actividades empresariales: personal, recursos, datos, etc. Cada icono de los diagramas suele llevar asociado un texto explicativo de su

1 Un buen libro para ampliar esta información es el de K.H. Móller y D.J. Paulish, Software Metrics. A Practioner’s Guíete to improved Product Developmenl, IEEE Press, Chaptnan & Hall, 1993.

54 P L A N IFIC A C IÓ N Y G ESTIÓ N DE SISTEM A S IN FORM ÁTICOS

propósito, su función en el marco de las actividades comerciales, su respaldo informático y su relación con otros iconos. El texto explicativo contiene información suficiente para deducir las características fundamentales del objeto real representado por el icono.

Las metodologías de modelización permiten encauzar la elaboración de modelos representativos de las actividades empresariales y el desarrollo de sistemas. Sin embargo, los modelos comerciales exigen frecuentemente modificaciones como resultado de la evolución del negocio. Si los modelos se construyen a mano, esos cambios requieren considerables esfuerzos; en consecuencia, los modelos trabajosamente elaborados a mano se vuelven pronto obsoletos. Por otra parte, si se invierten grandes esfuerzos en la construcción de un modelo manual, se tiende a no invertir más trabajo en todo lo que suponga modificarlo. La modelización representa simbólicamente las distintas facetas del negocio con vistas a su estudio y subsiguiente mejora, antes de comprometerse formalmente en la elaboración del modelo. El cambio, por tanto, es inherente al modelado, de ahí que haya que facilitarlo al máximo.

4.3 LOS CASE.

En la actualidad ya no se concibe el desarrollo de Sistemas de Información sin utilizar herramientas de ayuda para automatizar gran parte de las tareas del ciclo de vida. Esto ha dado lugar al nacimiento de la Ingeniería del software Asistida por Ordenador o tecnología CASE (Computer Aided Software Engineering), que consiste en una combinación de metodología de desarrollo

y herramientas orientadas a

facilitar dicho desarrollo basado en esas metodologías concretas (Rational Rose, Predict CASE, Excelerator, Designer 2000

de sistemas (UML, OMT, SSADM, METRICA,

)

La tecnología CASE utiliza el ordenador como herramienta tanto para el establecimiento de modelos descriptivos de las empresas que se van a automatizar como para documentar el desarrollo de los Sistemas Informáticos implicados, desde el momento de su planificación hasta su implantación final. En este sentido, dicha tecnología permite resolver el conflicto existente entre el dinamismo de la actividad empresarial y la dificultad que entraña el desarrollo de nuevos Sistemas Informáticos que se adapten a tal dinamismo.

La tecnología CASE reemplaza el papel y el lápiz por el ordenador para hacer del desarrollo del software un proceso más productivo. El objetivo fundamental de la CASE es proporcionar un conjunto de herramientas que

C A P ÍT U L O 4: FA CTO RES D li PR O D U C T IV ID A D

55

automaticen los trabajos de desarrollo y mantenimiento del software. Aunque de esta forma se facilita la implantación de soluciones, su principal aportación se refiere a las mejoras en la productividad y calidad en todos los aspectos del desarrollo, abarcando todas las fases del ciclo de vida, permitiendo la aplicación real de las técnicas recomendadas por la metodología utilizada; algo que de forma manual sería muy difícil de llevarse a cabo debido a la gran cantidad de información, esquemas y documentación que se debe generar.

Se han desarrollado herramientas CASE que automatizan muchas de las metodología conocidas empleadas para el modelado. Esas herramientas aplican muchos de los principios de la CASE desde el momento en que aportan técnicas de diagramas acompañadas de textos explicativos. Muchos sistemas CASE funcionan en ordenadores personales, requiriéndose un ratón para manejar los de mayor orientación gráfica. Los mandatos se introducen mediante menús o teclas de función estando reservada parte de la pantalla para introducir la especificación oportuna de los modelos.

Dentro de las metodología más gráficas automatizadas a través de los sistemas CASE, algunos iconos cumplen varias funciones. El texto que aparece tras los iconos explica que simbolizan estos en el marco de la faceta comercial en fase de modelado.

Estos textos explicativos se introducen en la parte del sistema CASE conocida como "diccionario" (algunos sistema CASE poseen gestores de bases de datos incorporados que realizan esta función). El diccionario contiene pantallas preformateadas asociadas a los distintos iconos, pantallas que suministran una información muy valiosa acerca de los aspectos del negocio simbolizados por los iconos. El diccionario contiene además un directorio que muestra las relaciones existentes entre determinados diagramas, iconos y textos explicativos.

La mayoría de las organizaciones se enfrentan a una crisis del software y tienen, generalmente, una gran cantidad de proyectos esperando a ser desarrollados. Es necesario, por tanto, resolver este grave problema, obteniendo sistemas de mejor calidad y en menor tiempo.

Una importante parte del éxito de la implantación de la CASE es determinar lo qué se debe hacer y cómo para resolver el problema planteado dentro de la organización. Debido a que cada organización vive el problema desde un punto de vista distinto, se deben determinar con detalle las necesidades y las prioridades de la misma que se deben cubrir.

56 PLA N IFIC A C IÓ N Y G ESTIÓ N

DE SISTEM A S IN FO R M Á TICO S

C A P IT U L O 4

FA C T O R E S DI- P R O D U C T IV ID A D

57

4.4 PRODUCTIVIDAD SEGÚN EL CICLO DE VIDA.

La utilización de un tipo u otro de ciclo de vida en un proyecto informático puede aumentar o disminuir considerablemente la productividad del proyecto. Aunque la necesidad de un modelo de desarrollo o ciclo de vida hace tiempo que está firmemente establecida todavía hay muchos proyectos que no aplican ningún modelo o utilizan modelos no adecuados. La elección del ciclo de vida

Aproximación por prototipo. Es habitual que en un proyecto software no se identifiquen inicialmente los requisitos detallados de entrada, procesamiento o salida. En casos así, lo habitual es construir un prototipo. Esta aproximación se enfoca a mejorar la efectividad del proceso de desarrollo y 110 a mejorar la eficacia de ese proceso, ya que la plena definición del usuario es un proceso muy lento y al terminarlo es cuando se empieza a desarrollar el producto (el prototipo no suele ser reutilizable). Este enfoque es apropiado cuando:

a utilizar es una tarea en la que hay que tener en cuenta factores del proceso,

o

El cliente no tiene claro lo que quiere.

del producto y del problema. La utilización de un ciclo de vida u otro nos determina:

o

Al cliente le gustaría ver algo similar para poder hacerse una idea de lo que obtendrá.

• Las fases productivas de un proyecto.

• Los objetivos de cada fase productiva.

• Los productos obtenidos en cada una de estas fases así como sus características.

Se han propuesto muchos ciclos de vida para el desarrollo del software, pero estos son los más representativos:

• Aproximación en cascada. Técnica rígida, su filosofía es completar un paso con un alto grado de exactitud, antes de empezar el siguiente. Adecuado para el desarrollo de sistemas con especificaciones muy elaboradas desde el principio. Los proyectos raras veces siguen el modelo secuencial que se supone, pero si es aplicable a un proyecto, su planificación y su gestión son mucho más fáciles y no suele haber desviaciones. En general presenta desventajas como:

o

La versión operativa de los programas no está disponible hasta que el proyecto está muy avanzado,

o

No contempla iteraciones y paralelismos potenciales entre las fases. Algunos integrantes del equipo han de esperar a otros para completar tareas pendientes,

o

Un error importante puede ser desastroso, si se descubre al final del proceso.

o

En muchas ocasiones no es posible disponer de unas especificaciones correctas desde el primer momento, porque puede ser difícil para el usuario establecer al inicio todos los requisitos.

Existen dos clases de prototipos:

o

De INTERFACE. Usualmente un modelo de papel o sobre PC en el que se muestran pantallas y listados.

o

De COMPORTAMIENTO: Es posible ofrecer todos los menús del sistema y simular débilmente los procesos o cubrir funciones que presentan ambigüedades al cliente o a los informáticos.

Aproximación evolutiva. Similar a la de prototipos, intenta un sistema flexible con una gran capacidad de expansión de tal forma que se van obteniendo versiones del prototipo cada vez más parecidas al sistema final. El prototipo no se desecha, incluso los requisitos de fiabilidad y rendimiento se implementan desde el principio. Mientras que en la aproximación por prototipos se asume que existe una serie de requisitos que no están claros para diseñar el prototipo, esta aproximación se diseña en base a los requisitos que están claros y se pretende descubrir* los demás. Cada vez se desarrolla una nueva versión de todo el sistema.

Aproximación incremental. Se comienza el desarrollo para satisfacer una parte de los requisitos especificados. Se van añadiendo mas requisitos en futuras versiones. Se logra una pronta disponibilidad parcial del producto que, si bien es incompleto, puede ser utilizable y satisfacer algunas necesidades de información. Se desarrolla cada vez un nuevo sistema sin modificar el anterior añadiendo nuevas funciones. Tiene una desventaja importante: los errores en los requisitos (o errores de análisis), si aparecen tarde, son graves, es decir, son difíciles de corregir.

58 PLA N IFIC A C IÓ N Y GESTIÓ N DE SISTEM A S IN FORM ÁTICOS

• Aproximación en espiral. Esta aproximación, formalizada por Boehm en 1985, nace para recoger lo mejor de la aproximación convencional y de la de prototipo añadiéndole el componente de análisis de riesgo. Es importante determinar en la fase inicial el nivel de riesgo que existe. Si como consecuencia del análisis de riesgo se observa que hay incertidumbre sobre el problema entonces en la actividad de ingeniería se aplicará la aproximación prototipo cuyo beneficio es el de reducir la incertidumbre. Un proyecto que utilice este ciclo de vida tendrá una estructura similar a la que muestra la figura 4.1.

Planificación

,

Análisis riesgos

F igura 4.1 E volución de un proyecto utilizando un ciclo d e

vida en espiral

• Aproximación basada en transformaciones. Con la aparición de las herramientas CASE junto con los generadores de código, el ciclo de desarrollo software en cascada ha cambiado a un ciclo de vida basado en transformaciones. La utilización de herramientas CASE afecta a todas las fases del ciclo de vida del software. Este ciclo de vida se puede considerar como una serie de transformaciones. Primero se definen los requisitos del sistema, seguidamente existe un proceso de transformación que hace que la especificación se convierta en un diseño lógico del sistema. Posteriormente, este sufre otro proceso de transformación para lograr un diseño físico, es decir que responda a la tecnología destino. Tiene una gran ventaja: la posibilidad de comprobación de errores en etapas iniciales del desarrollo junto con el soporte de rastreabilidad de requisitos y de reusabilidad.

C A PÍT U L O

1: F A C T O R E S

D E PR O D U C T IV ID A D

4.5 DISPONIBILIDAD DE RECURSOS.

59

Es importante considerar la disponibilidad de recursos. Los recursos no siempre están disponibles y, a veces, no se pueden conseguir nuevos recursos en un intervalo prefijado de costes, estas consideraciones se desarrollarán a continuación para el perfecto entendimiento de este tipo de limitaciones. También es importante en la planificación del proyecto, considerar, para llegar mejor a la consecución de los fines, la valoración y experiencia del equipo de desarrollo. Entre los principales problemas planteados por la crisis del software, ninguno es más inquietante que la relativa escasez de recursos humanos capaces para desarrollar software con las nuevas herramientas que surgen cada día y que mejoran la productividad dentro de las limitaciones del presupuesto. Es relativamente fácil obtener buenos codificadores de algoritmos concretos que pueden desarrollar pequeños sistemas completos, pero es difícil encontrar un equipo de desarrollo que conozca las técnicas de comunicación a fin de poder ser coordinado con otras personas para el desarrollo de tareas no repetitivas.

Otro problema consiste en la asignación efectiva de tareas a los recursos mejor especializados. En un equipo de desarrollo de software es normal encontrarse con afirmaciones como la siguiente: “Fulanito hace mejor las

pantallas

miembro del equipo las misiones que mejor cumplan los objetivos del proyecto, y un objetivo del proyecto puede ser realizado con la incorporación de las habilidades concretas de cada miembro del equipo.

sin embargo la pericia del director deberá saber asignar a cada

”,

4.6 LA EXPERIENCIA Y EL ENTRENAMIENTO DEL EQUIPO DE DESARROLLO.

Hay que considerar las distintas figuras que aparecen en el desarrollo de un sistema de información de tipo mediano-grande: el director del proyecto, los analistas funcionales, analistas orgánicos, programadores, técnicos de sistemas, documentalistas para el mantenimiento de la biblioteca software, operadores, administradores de la base de datos, técnicos en seguridad, etc. Cada uno de ellos tendrá una participación más o menos activa en función de la evolución del proyecto en sí.

60 PL A N IF IC A C IÓ N Y G E S T IÓ N

DI; SIS T E M A S IN FO R M Á TIC O S

Aunque depende en gran medida de la envergadura, complejidad y características del sistema a desarrollar, puede establecerse de forma general que en todo proyecto de desarrollo de un sistema están implicados, por una parte, personas pertenecientes a la organización usuaria o promotora del proyecto, la que utilizará el sistema cuando éste se construya y, por otra, la organización de desarrollo o empresa contratista a la que la primera encarga la realización de tal sistema.

Puede ocurrir, no obstante, que se trate de un desarrollo interno de la propia organización usuaria, a través de su propio departamento de proceso de datos (o departamento de informática). En tal caso, la organización de desarrollo se correspondería precisamente con este departamento.

Aunque no suele ser habitual su presencia en la mayoría de los proyectos, puede determinarse por parte de ambas organizaciones (de usuario y de desarrollo), la contratación de una tercera firma, especialista en auditoria informática e independiente de ambas, que intervenga en aquellos casos en los que se hayan previsto procedimientos extraordinarios de control (auditorias).

El personal perteneciente a las anteriores organizaciones que interviene en un proyecto determinado es el siguiente:

• Comité de Dirección: Está constituido por los responsables de la organización usuaria o promotora del proyecto y de la organización u organizaciones encargadas de su desarrollo. Al frente de este comité se encontrará el Director del Proyecto.

• Director del Proyecto: Se trata de un directivo de alto nivel, con amplia experiencia en planificación y gestión de Sistemas de Información, nombrado por acuerdo entre las organizaciones implicadas. Normalmente se trata un directivo de la organización encargada del desarrollo del sistema.

• Comité de Garantía de Calidad: Está integrado por personal, con conocimientos y experiencia en metodologías de desarrollo, del departamento de informática, si existe, de la organización usuaria o, en caso contrario, de una organización externa, independiente de la que desarrolla el sistema. Este comité se encargará de controlar la evolución del proyecto a través del análisis de los productos generados a lo largo de las diferentes fases de desarrollo. En el caso de pertenecer a la organización usuaria, el personal encargado de este control de calidad

C A P ÍT U L O

4:

F A C T O R E S

D E

P R O D U C T IV ID A D

61

deberá ser independiente de aquel, de la misma organización, que compone el equipo de desarrollo del sistema.

• Equipo de Desarrollo: Está constituido por las personas que se van a encargar directamente del desarrollo. Pertenecerán a la organización contratada para desarrollar el sistema; aunque si se trata de un desarrollo interno, los miembros del equipo pertenecerán a la propia organización usuaria. Normalmente, si el desarrollo es externo (empresa contratista) y la organización usuaria dispone de Departamento de Informática, algunas personas de tal departamento pueden considerarse también del equipo, participando, por tanto, en el desarrollo.

• Al frente del Equipo de Desarrollo se sitúa el Jefe del Proyecto, persona con amplios conocimientos informáticos y experiencia en el desarrollo de este tipo de sistemas. El resto de personal implicados en el desarrollo serán:

• Analistas: Personal con conocimiento de la metodología de desarrollo a utilizar y de las herramientas que permiten automatizar este desarrollo. Se encarga del estudio de los requisitos, objetivos y funciones a realizar por el sistema, documentando todos estos aspectos según la metodología establecida.

• Diseñadores: Suele tratarse del propio analista anterior. Se encarga de establecer la estructura del software y de los datos que constituyen el sistema.

• Programadores: Codificarán, mediante un lenguaje de programación concreto, los componentes software establecidos por los diseñadores.

• Técnicos de Sistemas: Personal experto en software de base (sistemas

y equipos informáticos, que ofrece apoyo

operativos, software de red,

técnico a lo largo del desarrollo.

)

• Personal del Area de Explotación: Se trata de personas del departamento de informática o proceso de datos de la organización usuaria, con conocimientos sobre el entorno en el que se explotará el

sistema cuando se instale. Estas personas colaborarán con el equipo de desarrollo, para concretar determinados aspectos relacionados principalmente con la definición del entorno tecnológico del sistema

62

P L A N IF IC A C IÓ N Y G E ST IÓ N DE S IS T E M A S IN FO R M Á TICO S

que, con toda seguridad, utilizará el sistema. En este último caso, conviene destacar la conveniencia de la existencia de un Administrador de tal Base de Datos, que será una persona del área de explotación experta en esta labor y que se responsabilizará de la seguridad, confidencialidad y ajustes de dicha base de datos, mediante parámetros extemos para asegurar el óptimo rendimiento, cuando el sistema funcione en explotación.

• Personal del Area de Usuario Final: Se trata de aquellas personas que utilizarán el sistema normalmente, a las que habrá que recurrir para determinar con detalle las funciones que debe realizar el sistema.

• Personal del Área del Comité de Calidad: Formado por personas cuya misión será someter el sistema a todo tipo de pruebas para garantizar que se han realizado todo tipo de controles y, por lo tanto, el producto obtenido tiene la calidad deseada. Estos equipos de testeadores normalmente se utilizarán, posteriormente, como formadores o consultores del producto final.

CAPÍTULO 5

ASPECTOS GERENCIALES

En este capítulo se realiza una visión de la situación del director de proyecto

dentro de la empresa en la cual presta sus servicios. Deberá aprender el cómo y

el por qué de efectuar presupuestos, controlar los gastos y preparar información estratégica para que la gerencia pueda tomar decisiones. Igualmente conocerá

los

criterios generales de la organización, el concepto de cultura de empresa y

los

cambios a los que indiscutiblemente está sometida. Finalmente, se hace

hincapié, en comprender la necesidad de ajustar los sistemas de información a esos cambios como método organizativo de ser competitivos.

5.1 EL A N Á L ISIS PREVIO Y EL C O N TR O L DE LA INVERSIÓN.

A la hora de enfrentarse con la decisión de realizar un proyecto nos

encontramos con el problema de la inversión, con el conveniente estudio de viabilidad y otro análisis de la rentabilidad del proyecto. En otras palabras: se debe de considerar si las ideas del promotor del proyecto son viables, es decir, si se puede alcanzar ese futuro deseable para la organización en un entorno aceptable y con unas condiciones económicas aceptables.

Los estudios de viabilidad1 suelen englobar todos los aspectos que se consideren necesarios para que la alta dirección pueda tomar sus decisiones en

un ambiente de relativa seguridad dentro de la subjetividad profesional de los promotores. En general, en el documento de Análisis de la Viabilidad se incluirán datos de:

Parte importante de este tema es que el lector adquiera una visión clara de la situación del director de proyecto dentro de la empresa en la cual presta sus servicios. Deberá aprender el cómo y el por qué de efectuar presupuestos, controlar los gastos y preparar información estra­ tégica para que la gerencia pueda tomar decisiones.

64 P L A N IF IC A C IÓ N

Y G E S T IÓ N

DB

S IS T E M A S

IN F O R M Á T IC O S

• Estudios técnicos sobre el estado del arte de la materia a proyectar

• Estudios econométricos y comerciales sobre el universo en el que se implante, o comercialice, el producto a obtener

• Estudios financieros sobre la inversión necesaria, cadencia de pagos, costes financieros y previsiones de venta.

• Estudios de recuperación de la inversión y de rentabilidad.

• Estudios sobre el efecto de no realizar el proyecto

Con los estudios anteriormente citados se procede a efectuar una valoración, o mejor aún, un proceso de valoración entendido como “un proceso formal según el cual se asignan unas magnitudes monetarias a determinados procesos o hechos económicos con objeto de hacerlos calculables para un determinado fin”. Es necesario que existan varias formas de datar el precio de un producto o de un servicio y si bien todos sabemos que el valor de un bien depende de la necesidad humana que va a satisfacer podemos establecer, básicamente, dos métodos a la hora de establecer el precio. De una parte se puede utilizar un criterio que sea consecuente con los procesos de pagos y cobros, considerando ciertas implicaciones con algunas funciones de los sistemas de escasez o de boyantía, a este sistema se les reconoce con los criterios pagatorios, como decimos, basados en una corriente real de pagos y cobros, es decir, estudiando el coste real del bien.

Otro criterio es utilizar un sistema de tipo calculatorio, donde no existe la corriente anterior de pagos y cobros, pero hay consumo de bienes que, hasta que se establece un mercado en el que se equilibre la oferta y la demanda, puede funcionar con un cierto nivel inflaccionista2.

Ya hemos utilizado una serie de conceptos que, si bien no han sido rigurosamente definidos, de alguna forma estamos familiarizados con ellos:

Memos hablado de inversión y siempre que utilizamos este término nos referimos a un cierto desembolso inicial que, normalmente, es económico. Siempre que se realiza una inversión esperamos un cierto rendimiento conocido como rentabilidad en un cierto tiempo. Pero cuando invertimos en un determinado bien, por la naturaleza finita del dinero, renunciamos, de forma implícita, a obtener otro bien a satisfacer en el momento actual con ese tipo de recursos. Se renuncia a un bien actual seguro pensando en que se obtendrá una rentabilidad futura incierta, lo cual conlleva un cierto estado de riesgo que tendrá que valorarse lo más fríamente posible.

2 Vcase el libro Dirección de Proyectos Informáticos: Una guía práctica del Jefe de Proyecto; dePlam Thu Quang y Jean-Jacques Gonim. Gestión 2000, 1994.

C A P ÍT U L O

5. A S P E C T O S

G E R E N C IA L B S

65

Normalmente la inversión se realiza en términos de capital entendido como un conjunto de derechos de propiedad que se pueden cambiar (invertir) por otras propiedades: en nuestro caso se cambia dinero por un bien futuro que puede ser, por ejemplo, un sistema de control de la producción con el que se va a obtener más beneficios.

un determinado

proyecto viene dado por el trinomio formado por un desembolso inicial, un rendimiento y una duración.

En general se puede considerar que toda inversión en

Formalicemos estos conceptos, y otros más que nos servirán de apoyo, utilizando la notación estándar3:

Capital circulante: el que necesita todo negocio para afrontar su actividad normal después de realizar la inversión.

Valor residual: Valor del producto cuando se decide liquidarlo.

Periodos a contemplar (/;): Es el número de periodos que vamos a contemplar desde que se efectúa la primer inversión hasta que el producto deja de ser un bien útil o cuando de decide liquidarlo a cambio de cierto valor residual. Suele coincidir con los periodos durante los cuales el proyecto genera flujos de caja.

Valor Esperado Monetario (VEM) Es el sumatorio de la renta que se espera obtener en cada alternativa4 multiplicada por la probabilidad de que esa renta se produzca.

VEM = p r o b a b ilid a d J x rentaesperada¡

Rentabilidad prevista (RP): Es el cociente entre la diferencia del Valor Esperado Monetario menos el Coste de la Inversión dividido por el Coste de la Inversión:

3 Gotlieb utiliza estos conceptos en su obra "Economics of Computers, The Cost, Benefits, Policies and Strategies", Prenlice-Hall, 1985. 4 En muchos libros de texto considera periodos como forma de simplificación de las alternati­ vas, nuestra consideración es que se deben de considerar distintas alternativas como una gene­ ralización de los periodos considerados por otros autores.

66 PLANIFICACIÓN Y GESTIÓN DE SISTEMAS INFORMÁTICOS

R r

VEM-CI

C I

Supuesto práctico 5.1: Una compañía se encuentra en condiciones de realizar unas mejoras en su sistema de información de dientes pudiendo tomar una de las siguientes alternativas:

1.-Comprar un portal de venta electrónica que le supondría un coste total de la inversión de

47 millones de pesetas y que, por otra parte ahorraría, entre mano de obra, alquiler de locales

e infraestructura, una cantidad estimada de 80 millones de pesetas.

2.- Construir un sistema de ayuda a la distribución de mercancías parafacilitar la entrega de las mismas a los clientes en el mercadojaponés. El coste de la inversión se estima en 35 millones de pesetas mientras que los resultados esperados, considerando la reducción de los plazos de entrega que aumentarían las ventas, es de 70 millones de pesetas.

3.- Crear un sistema de gestión de cobros que permitaflexibilizar las entregas gracias a un control puntual de la “bondadfinanciera " de los clientes. Esto se puede realizar con una inversión de 52 millones de pesetas y, como contrapartida, se obtendrían unos beneficios, incluyendo la menor cantidad de efectos que hasta el momento resultaban ser impagados, de

83 millones de pesetas.

La dirección cree que las previsiones se han realizado basadas en unas hipótesis de estimación de probabilidad 0,7, pero cree posible que, debido a coyunturas económicas adversas, podría darse el caso desfavorable de que esto no suceda así (con una probabilidad de 0,2) de tal form a que sus resultados comerciales fueses de 72, 45 y 57 millones de pesetas respectivamente en cada proyecto. Igualmente, y por eliminación, cree que el escenario podría ser muy favorable, con probabilidad 0. i, y los resultados respectivos de las tres opciones podrían ser de 93, 87 v 113 millones de pesetas. En cualqttier caso cree que los costes de implementación siempre se mantendríanfijos sea cualfuese el escenario.

Estimar, en base a la información facilitada qué proyecto es el más aconsejable según el valor esperado monetario y la rentabilidad prevista.

Construiríamos, con la ayuda de una hoja de cálculo, una tabla con los datos aportados por el proyecto

 

Hipótesis baja

Hipótesis media

Hipótesis aita

Probabilidad

Probabilidad

Probabilidad

0,2

0,7

0,1

Coste

Portal de ventas

72

80

93

47

Ayuda distribución

45

70

87

35

Gestion de Cobros

57

83

113

52

CAPÍTULO 5: ASPECTOS GERENCIALOS

67

Para calcular el Valor Esperado Monetario ( VEM) de cada proyecto aplicaríamos la fórm ulay diríamos:

VEM(l) = 72 x 0,2 + 80 x 0,7 + 93 x

0,1 = 79,7

VEM(2) = 45 x 0,2 + 70 x 0,7 + 87 x 0,1 = 66,7

VEM(3) = 57 x 0,2 + 83 x 0,7 + 113 x 0,1 = 80,8

Así ventos que el proyecto con mayor valor esperado meto es el tercero, pero calculemos la rentabilidad prevista para cada proyecto para decidir cual de ellos es el más interesante::

RP(\) =

7 9

7 -4

■»

47

7

= 0,69

RP( 3) = 80,8~ 52 = 0,55

52

Observamos,

es el segundo de ellos.

que desde el punto de vista de

rentabilidad el proyecto m ás interesante

(

(

I

(

■(

i

<

í

(

En el caso de haber considerado que los costes de producir el bien también tuvieran un valor concreto en cada escenario de probabilidad tendríamos que ^ obtener un valor resultante del coste del proyecto efectuando su media ponderada.

Continuamos definiendo otros términos de importancia en el control de proyectos como puede ser el periodo de recuperación de la inversión; aspecto importante para poder abordar un nuevo proyecto, para lo cual nos apoyaremos en un segundo supuesto.

Supuesto práctico 5.2: La compañía descrita en el supuesto práctico 5.1 decide ampliar su estudio y saber cual es el tiempo de retorno de su inversión como un nuevo parámetro para la toma de su decisión de qué tipo de proyecto acometer con prioridad uno. Para ello indica que la inversión en cada uno de los tres proyectos la realizará al principio del periodo (podrían realizarse las

68 P L A N IF IC A C IO N

Y

G E S T IÓ N

D E

S IS T E M A S

IN F O R M Á T IC O S

aportaciones de la inversión

de cada periodo son los siguientes:

en varios periodos) y que los flu jo s de tesorería

Para el prim er proyecto serán constantes en ocho años a un importe de 10 millones de pesetas.

Para el segundo proyecto los beneficios serán igualmente fijo s y importe de siete m illones de pesetas durante diez años.

de

un

En el tercer proyecto se estima que se producirán flujos positivos con la

en cada año

cadencia de 2, respectivo.

4,

7,

12,

15,

14,

13

y

12 millones de pesetas

Obtendríamos que, para el prim er proyecto, el tiempo de retorno sería del cociente de dividir la inversión entre el flu jo de tesorería por ser constante, es decir:

PR(1)

explotación.

=47/10

=4,7

PR(2) = 35/ 7 — 5

por

lo tanto se recupera en el quinto

año de

En el tercer caso se recupera en el año sexto ya que ese año el importe de la inversión, que eran 52 millones, está “horquillado ” entre una flujo de tesorería del quinto año que no llega a cubrir los costes y un sexto año en que se supera la inversión.

Q¡ = 2

+ 4

+

7 +

12+15

= 40

y

Qi+,

= 2 +

4 + 7+12+15

+ 14

= 54

Con la información obtenida hasta el momento podem os decir que los

prim eros

proyectos son más interesantes, frente al periodo de recuperación,

que el tercero.

Vamos a introducir algunos valores que tienen importancia trascendental en los proyectos. Hablamos de los siguientes términos:

Tasa de inflación (/): Se define como la medida del incremento continuo en los precios de los bienes y servicios a través del tiempo.

C A P ÍT U L O

5: A S PE C T O S G ER I-N C 1A LES

69

la s a de referencia: Interés medio de unos fondos de los que se carece.

Interés

prefijado:

Es

el

interés

de mercado que se pagará por disponer

negociado

y

que

suponemos

que

se

mantendrá fijo en la aplicación del préstamo.

Periodo de Recuperación (Pay-back) es el tiempo necesario para recuperar el capital depositado en la inversión como hemos visto en el supuesto anterior. Este valor nos indica la velocidad con que se recupera la inversión de tal suerte que a valor más bajo, con el resto de las condiciones constantes, mejor será económicamente el proyecto.

Cuando entra enjuego la lasa de inflación, el PB se obtiene en el momento en el que se iguala la siguiente expresión:

f

PT,

7¿{\ + r )

= f

h { \

1,

+ r )

siendo /, el valor de la inversión que se efectúa en el periodo t5.

Normalmente la restricción del proyecto viene impuesta por una condición del tipo “que el PB sea menor de x años”.

El PB se suele considerar de una única inversión inicial y, en este caso, el PB se obtiene de la fórmula:

PB

y

JP 'T

= i

/=o (1 + r)

Si hubiera distintas inversiones anuales hasta el año N, el PB sería mayor de N y se calcularía como:

PB

fT 'T

/=o (l + ry

N

T

,=o (!+/•)'

5 La igualdad anterior puede no darse nunca con valores de periodificación discretos por lo que se considerará, a efectos prácticos, el primer periodo en que el primer término (suma acumula­ da de los flujos de tesorería) sean iguales o inmedatamente superiores al segundo término (in­ versión soportada).

70 PLA N IFIC A C IÓ N Y G ESTIÓ N DE SISTEM A S IN FO R M Á TICO S

El segundo término es el valor actualizado de todas las inversiones que igualarían, en el momento del periodo de retorno, al valor actualizado de lodos los flujos de caja hasta el año en que se cubre la inversión.

Flujos de Tesorería

(FT)\

Son las entradas y salidas de caja en cada

periodo, así FT„ es el flujo de caja del periodo n.

Valor Actual Neto ( VAN) de una inversión: representa el valor monetario neto en un momento dado. Se calcula como la diferencia entre los flujos de tesorería actualizada a la tasa de interés prefijado y las inversiones actualizadas a esa misma fecha. Así un VAN positivo indica que la inversión en el proyecto es rentable o, al menos, es mejor que la tasa de referencia.

Se calcula mediante la fórmula:

F e

i,-'/-

¿ í( l + /')'

p i i

i

w í(l + '-)

En el cálculo del VAN se debe de considerar al final del periodo (año n) el valor residual del bien como si se tratara de un flujo de tesorería en ese año. Realmente se debería de utilizar un Cash Flow Neto en los numeradores, así:

Ingresos - gastos y costes financieros = Beneficio de explotación + amortización técnica = Beneficio bruto - impuestos = Beneficio neto + amortización técnica = Cash Flow Bruto - amortización del crédito = Casli Flow Neto

Tasa Interna de Rentabilidad (TIR) es el tipo de rentabilidad que anula el Van del final del periodo. O lo que es lo mismo: es la tasa que compensa todas las inversiones con los flujos de tesorería esperados. Cuando un proyecto tiene un TIR de un x% va a generar liquidez suficiente para remunerar al x% del capital invertido en el proyecto además de devolver el capital invertido.

Se calcula mediante la fórmula:

f

FT,

¿o(l +TRI)'

y ¿ ( l

i,

+TRI)'

donde N es la duración total de la inversión.

C A P ÍT U L O 5. A SPE C TOS GP.KHNCIAI.KS

71

Tipos de rentabilidad económica: rea! (considerando la inflacción) y monetaria (sin ella)

(I + m „ ) = (I +0(1+77?/,)

Dentro de la documentación que se suele acompañar al lanzamiento del proyecto es interesante conocer los conceptos de Perfil y de Portafolio.

Perfil: Es un estudio en el que se valoran todos los elementos que forman

parte de un proceso (componentes/elementos): calidad, precio, competencia,

Con estos datos se establece una

escala métrica y en cada componente se asigna un valor con lo que obtendremos el perfil del proceso.

coste, producto, diferenciación, tiempo, etc

Portafolio: Análisis espacial en el que se relacionan diferentes conceptos:

Todo ello se evalúa en una

matriz finita de tal forma que en cada uno de los intervalos se establece la posición de la empresa. Posteriormente se define la posición de la empresa según su operatividad del futuro lo que nos facilita a encontrar la situación exacta de la empresa en cada momento.

evolución del mercado, ventaja competitiva,

5.2 ¿CUÁNDO UN PRO YECTO ES

SATISFACTO RIO ?

Una vez que el directivo posee el documento de valoración inicial se planeara la decisión de realizar el proyecto y, en este momento, debemos de considerar cual es la mejor forma de alcanzar el éxito en el desarrollo del proyecto, para ello vamos a estudiar cuales son los criterios desde distintos puntos de vista.

Para la alta dirección

un proyecto ha resultado exitoso

normalmente, los siguientes aspectos:

• Es un activo real

• Se alcanzaron los objetivos

• Se controlaron los costes

• Estuvo bien dirigido y controlado

si se cumplen,

Frente a la organización usuaria o los usuarios de la unidad de negocio, el sistema será “bueno” si:

72 PLA N IFIC A C IÓ N

Y G ESTIÓ N D E SIS T E M A S IN FO R M Á TICO S

• Se comprendieron las necesidades

• Permite el crecimiento

• Se implementaron cambios vitales

• El sistema resulta fácil de controlar

• Trabaja como se esperaba

Frente al personal del equipo del proyecto hubo éxito si se han satisfecho sus necesidades personal, en concreto si:

• Hubo comunicación con los usuarios

• Las especificaciones fueron revisadas y aprobadas

• Se evaluaron los cambios

• La dirección estuvo continuamente implicada

• Aumentó nuestra experiencia y confianza

Frente a los que operan el sistema, o en casos de proyectos subcontratados, frente a los que tendrán responsabilidad en el mantenimiento del mismo:

• Está bien documentado

• Es fácil de operar

• Fue bien probado y no tiene “sorpresas”.

• Tiene una excelente capacidad de recuperación y, ante posibles caídas del sistema, permite un rápido rearranque.

En general, como líneas maestras, toda la organización piensa que la realización de un proyecto ha tenido éxito si se ha realizado dentro de los plazos previstos, dentro de los presupuestos establecidos y se ha obtenido un producto de calidad que satisface a los usuarios.

No se debe despreciar la dimensión institucional del proyecto que dependiendo del entorno de la empresa variarán los objetivos y dependiendo de cómo definamos los objetivos obtendremos el éxito o no.

Los objetivos que queremos obtener nos van a decir la orientación que deberá darse a la utilización de recursos y el comportamiento del personal lo que implicará hacer cierta investigación de la eficiencia o combinación de factores que se debe de llevar a cabo para obtenerlos.

CAPÍT ULO 5: A S PE C T O S GEREN C1A I.F.S

73

Es de considerar que suele haber un conjunto de objetivos lo que conlleva una serie de prioridades que nos obligarán al establecimiento de un plan o programa de cumplimiento de objetivos.

Decíamos, por otra parte, que el proyecto ha sido exitoso si ha cumplido los presupuestos. El control de costes es fundamental porque:

• Si no existe presupuesto se hace difícil la gestión del proyecto.

• Si hay presupuesto pero la gestión es mala, tarde o temprano los resultados serán malos.

• Los costes de un sistema informático son cada vez más altos.

• Las áreas usuarias (o clientes) deben de soportar los costes.

La gestión debe iniciarse con una buena elección del presupuesto, y los gastos e inversiones deben de justificarse en relación con el "negocio". El presupuesto debe abarcar todas las partidas para tener controlado todo el Proyecto Informático para saber puntualmente lo que estamos gastando globalmente en los distintos conceptos.

Respecto a la filosofía de como se deben de realizar los presupuestos se debe decir que no hay un método único, que se defienden varias teorías y que se pueden combinar así, por ejemplo, se puede:

• Partir de unas directrices (Top-down), basadas en porcentajes sobre proyectos similares más recientes.

• Elaborar un borrador según determinados criterios (Bottom-up condicionado) justificando lo que exceda un determinado porcentaje de las directrices.

Entre

destacar:

las partidas

más

importantes

a

• Costes totales de personal:

incluir en

el

presupuesto,

cabe

o

Fijo o eventual.

o

Formación.

o

Gastos derivados de selección y contratación.

o

Viajes y desplazamientos.

• Técnicos y servicios contratados:

o

Consultores.

o

Auditores.

o

Administración de Seguridad Informática.

74

PLANIFICACIÓN Y GESTIÓN DE SISTEMAS INFORMÁTICOS

o

Técnicos de desarrollo,

o

Entrada de datos,

o

Transportistas, mensajeros.

• Equipos (ordenadores, periféricos, redes, terminales

o

Alquiler.

o

Compra/amortización,

o

Mantenimiento.

• Software (Básico, paquetes, utilidades, herramientas

• Comunicaciones:

o

Voz

o

Datos

• Instalaciones:

):

).

o

Alquileres,

o

Gastos.

o

Consumos (agua, electricidad,

)

o

Mobiliario

• Suministros

(papel,

soportes

servicios contratados:

magnéticos,

cintas

entintadas,

)

y

o

Consultores,

o

Auditores.

o

Administración de Seguridad Informática,

o

Técnicos de desarrollo,

o

Entrada de datos,

o

Transportistas, mensajeros.

• Oficinas de servicios.

• Impuestos.

• Seguros.

• Intereses (si hay partidas que financiar).

CAPÍTULO 5: ASPECTOS GERHNCIALES

75

5.3 LOS ACTIVOS DE LA EMPRESA

Conocer los criterios generales de la organización, el concepto de cultura de empresa y los cambios a los que indiscutiblemente está sometida6.

Un proyecto puede ser satisfactorio para los empleados que lo utilizan, frente a la operación, etc., pero finalmente se verá que es satisfactorio si realmente constituye un activo importante para la empresa, considerándolo como un elemento de posicionamiento en el mercado frente a la competencia.

Se situará la gestión informática como un activo más de la empresa, comparándolo con otros activos, se estudiarán propiedades comunes y características diferenciadoras con la idea de que el alumno asimile el concepto de "cultura de empresa".

5.4 LA INFORMACIÓN COMO ACTIVO ESTRATÉGICO

El acceso a la información, en las empresas de hoy día, es una de las tareas más difíciles de los directivos en sus diarios procesos de toma de decisiones. Hoy día no es posible esperar de un empresario, que ya de por sí necesita tener un gran conocimiento sobre el funcionamiento de la empresa, del posicionamiento de sus competidores frente a un mercado altamente cambiante, de la

información que poseen sus técnicos, de los gustos de sus clientes,

condice a que, para que algunas empresas puedan sobrevivir, necesitan incorporar lo que, en términos generales, se conoce como las nuevas tecnologías de la información. ¿Y esto por qué? Porque, hoy más que nunca, la información es un valor para la empresa, es un activo de primer orden que puede ser utilizado para crear riqueza, para obtener un mejor posicionamiento en el mercado, o para poder utilizarlo como una baza de mejora frente a la competencia. En este sentido hacemos énfasis en el activo estratégico que supone, no el hecho de tener mucha información, sino el poder utilizarla, de la

forma más eficientemente posible, para que sea un verdadero conocimiento que sirva como factor productivo de explotación.

Esto nos

En este sentido podemos afirmar que una buena gestión en la información que soporta una empresa a nivel globalizado, que pone la información en el punto y en el momento en que sea preciso consultarla, que permite obtener un mayor rendimiento en sus empleados al disponer de esa información puntual al

6 Grupp, B., "La cuestión del departamento de

informática". Hispano Europea, 1985.

76 P L A N IF IC A C IÓ N Y G E S T IÓ N DF. SIST E M A S IN FO R M Á T IC O S

momento, es un activo extraordinariamente importante como para que los directivos la consideren como una de las responsabilidades de primer orden. Es tal la importancia de este tipo de activo que el empresario o el director no podrá delegar este tipo de tareas en ningún caso. Es más, existen sectores de actividad, como pueden ser las empresas dedicadas a los sectores turísticos o de seguros, donde el verdadero factor productivo es la buena gestión de sus sistemas de información y en los que la inversión en este tipo de activos tendrá una influencia directamente relacionada con sus resultados de explotación.

5.5 NECESIDAD DE ELABORAR PROYECTOS PARA ADECUAR LOS SISTEM AS DE INFORMACIÓN A LAS TOMAS DE DECISIONES EN UN M ERCADO CAM BIANTE

Según el planteamiento anterior en algunos casos será necesario elaborar proyectos en el que el orden de los “ingredientes” para “fabricar” servicios cambie de valoración: La gestión del conocimiento, entendida esta como la gestión más eficiente de sus sistemas informáticos, que traten de obtener valor adicional a toda la información que fluye por la empresa, incluso en datos no estructurados, será la materia prima, cada vez, y según la empresa va creciendo, más inagotable. Los procesos de los tendrán mayor cabida en cuanto que son la base de la toma de decisiones, y los procedimientos se irán adecuando a que la información sea correcta, útil, completa, pertinente y disponible en tiempo real.

Otro argumento que se aporta, para comprender la necesidad de ajustar los sistemas de información a esos cambios como método organizativo, es el hecho diferenciador de la competitividad: En la empresa hay que estar bien posicionados, disponer de más y más información aunque solamente sea por la necesidad de sobrevivir en un periodo de fuertes cambios que, únicamente se podrán realizar, con un buen sistema de conocimientos.

Otro apartado importante que se debe considerar dentro de la unidad temática actual -aspectos gerenciales-, es la repercusión de costes7 que dará a los directivos una visión global de la realidad de sus organizaciones. En este sentido, si bien no puede imponerlo el Director del Proyecto por ser decisión de la Alta Dirección, es necesario y tiene más ventajas que inconvenientes sobre todo a la hora de tener una valoración en la toma de decisiones. El general, y

7 En este sentido se puede consultar la obra de Romeo Baroggi "I costi dell'elaborazione elei- ironica dei dati", Franco Angeli Editore, Milano 1978.

C A P ÍT U L O 5. A SPECTO S G ER F-N C IA LE S

77

dentro de la Dirección de Proyectos, su funcionamiento debe de ser como si el "Proyecto" fuera una unidad diferente y, si fuera necesario, se crearía un centro de coste para la gestión en sí.

Una consecuencia beneficiosa de la repercusión de costes es la necesidad de dar buen servicio8 ya que un usuario que no obtiene un nivel de respuesta aceptable, un servicio pobre, o cuyas peticiones no se tengan en cuenta, protestará ante unos cargos que pueden considerar injustificados o excesivos introduciendo nuevamente unos factores de productividad que ejercerán nuevamente una dinámica hacia el cambio correctivo y, finalmente, hacia la mejora en el servicio.

s Se puede obtener más información del artículo de Joan M. Amat Salas “el control empresarial mediante la contabilidad de gestión” publicado en Cuadernos de Management, suplemento n.° 338 de Nueva Empresa. 16-30 de septiembre de 1990.

P L A N IF IC A C IÓ N Y GESTIÓN D E SIS T E M A S IN FORM ÁTICOS

CAPÍTULO 6

DEFINICIÓN DEL PROBLEMA Y ESTRATEGIAS DE SOLUCIÓN

La definición de los requerimientos es una descripción abstracta de los servicios que se espera que se construyan y aporten al sistema para que realice las funciones que el usuario espera del mismo. Debe consistir sólo en señalar el comportamiento externo del sistema sin que, en ningún caso, entre a definir elementos internos o características. Estos requerimientos deben de ser formalizados por escrito en un lenguaje natural que pueda ser entendido por cualquier persona conocedora de la empresa pero sin conocimientos básicos de informática. Los requerimientos se clasifican en dos categorías:

Requerimientos funcionales y requerimientos no funcionales.

La función y el rendimiento deben de ser evaluados a la vez y este binomio puede dar una resultante de tal magnitud que pudiera ser que la diferencia en el esfuerzo de desarrollo sea muy importante en distintos escenarios de fiabilidad.

Por otra parte, el software interacciona con otros elementos del sistema informático. El planificador debe de considerar la naturaleza y la complejidad de cada interfaz para determinar cualquier efecto en los recursos, costes y métodos de desarrollo. La descripción de los interfases, considerados como hardware, software y personas que lo utilizan, deben de estar perfectamente documentados.

Una vez que se dispone de un exhaustivo análisis de requerimientos pasaremos a diseñar un modelo que será construido más adelante. El proceso de diseño combina intuición y métodos que cambian continuamente conforme aparecen nuevas experiencias y un más amplio conocimiento (obsérvese que hablamos de diseño de software y no de programación o escritura de código conceptos abandonados desde hace casi dos décadas).

80 PLA N IFIC A C IÓ N Y G ESTIO N DE SISTEM A S IN FO R M Á TICO S

6.1 OBJETIVOS A ALCANZAR.

En un principio el proyecto ha nacido como una idea que trata de obtener un bien futuro y que, de alguna forma, ha sido presentado a la alta dirección para solicitar su posible aprobación pero que aún se mantiene en la fase de lo que podríamos denominar “fase conceptual”. Los ejemplos que podríamos citar de proyectos que no pasan de esta etapa son numerosos; los técnicos que se han afanado en el proyecto, y no ven continuidad a algo que para ellos parece trivial, les posiciona en un punto de incomodidad que debe de entenderse como las posibles dudas que actúan en la mente del empresario o del cliente que tiene que financiar la operación y que, sin lugar a duda, estará forzado a correr un cierto riesgo.

¿Es esta la mejor solución al problema?¿Es el momento adecuado? Para poder despejar este tipo de dudas será necesario obtener más conocimiento sobre el proyecto en sí: Será necesario efectuar una definición formal de las necesidades de la organización para poder estudiar el mejor proyecto de una posible gama de soluciones.

Para poder llevar este estudio por vías controladas efectuaremos un primer análisis sobre el estudio del problema a detalle para lo cual comenzaremos por describir una serie de necesidades identificadas que quedarán documentadas en un informe que todos los miembros implicados conocerán, discutirán y manejarán como punto de partida para nuevos avances del proyecto.

Como decíamos anteriormente del estudio del “informe de necesidades identificadas” se pasará a ensayar un borrador de objetivos del proyecto que mediante una serie de reuniones periódicas en las que se busque la solución más adecuada y en la que cada parte establecerá sus necesidades se intentará llegar a un informe de objetivos que nuevamente será cuestionado, atendiendo en especial a las recomendaciones técnicas y al posible plan de implantación definido por la dirección de la empresa hasta conseguir un documento de objetivos terminado que servirá, a su vez de revisión, hasta conseguir su total aprobación por las partes implicadas.

En la fase de revisión del documento de objetivos, el director del proyecto, irá creando una lista de puntos de control de las reuniones sucesivas: En especial mantendrá registros vivos, de una reunión a otra, de los puntos que puedan suponer un riesgo especial del proyecto e irá perfilando un posible plan de actuación que continuamente se irá perfilando hasta conseguir una definición lo suficientemente clara como para iniciar otra fase del proyecto. En

C A P ÍT U L O 6: D EFIN ICIÓ N D EL PR O B L E M A Y EST R A T E G IA S DE SO L U C IÓ N

SI

especial, el director de proyecto, en la fase de revisión del documento de objetivos se tendrá muy en cuenta los siguientes aspectos:

• Ámbito

• Factibilidad técnica

• Los recursos a emplear

• Las responsabilidades de cada participante

• Las Directrices generales de la compañía

• Los factores de productividad

• Los criterios de terminación

Con el análisis de cada uno de los puntos anteriores se debe de llegar a tener dispuesto el documento listo para la firma en el cual se deben de haber despejado las incógnitas que hacen que el proyecto sea creíble y dónde se pueda evaluar claramente el riesgo que se correrá con el proyecto en cuestión en cado de seguir adelante y en el caso de no seguir.

En cada una de las fases o reuniones que se hayan ido produciendo hasta afinar el documento de objetivos, el director del proyecto habrá ido actualizando la lista de control del riesgo y el plan de actuación a la vez que irá eliminando la lista de control de revisión de objetivos.

El documento de objetivos deberá tener una lista de objetivos de proyecto claros. Estos objetivos son muy importantes porque, como hemos visto en el capítulo anterior, uno de los factores del éxito del proyecto está vinculado al grado de cumplimiento de los mismos. Si cada objetivo de proyecto es claro se puede medir sin lugar a confusión que beneficiaría al director de proyecto poco eficiente que tratará de buscar excusas para justificar su ineptitud. Por lo tanto se deberán evitar objetivos con doble interpretación o con interpretación muy generalista del tipo “se podrá consultar la información con agregación de cualquier dato de la compañía”. En este sentido debemos considerar que los objetivos deben de ser:

• Cuantificables, lo que conlleva que sean controlables.

• Realistas, alcanzables.

• Omnipresentes a lo largo del proyecto: tienen que constituir las líneas maestras de referencia.

• Jerarquizables entre sí.

• Deberían de ser, en medida de lo posible, independientes del entorno.

• Permanentes mientras no se decida el cambio, es decir, no son modificables sin una justificación sólida.

82 P LA N IFIC A C IÓ N Y G E ST IÓ N DE SISTEM A S IN FO R M Á TICO S

Por otra parte debemos de considerar distintos p