Professional Documents
Culture Documents
Captulo 1: Introduccin....................................................................................5
1.1 La empresa y su entorno........................................................................... 6
1.2 La ingeniera del software....................................................................... 10
1.3 La planificacin y gestin en la ingeniera del software.................... 13
PRLOGO
1 ACM/IEED-CS Join Curriculum Task Force. Computer Curricula 1991. Ed. ACM Press, \ -,
1991.pp.78.
2 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 PRLOGO 3
objetivo que se persigue con la asignatura Planificacin y Gestin de Sistemas trmino reingeniera estaba posiblemente muy lejos de imaginar que en pocos
Informticos est orientada hacia la asimilacin de conceptos informticos aos este concepto iba a dejar una huella indeleble en la mayor parte de los '
tendente a su posterior utilizacin en el dimensionado, planificacin y procesos de desarrollo informtico de empresas. La idea de Hammer se ha (
operacin de un proyecto informtico: El Desarrollo de Software de Calidad asentado fuertemente como sinnimo de procesos de adaptacin y
como proyecto. optimizacin de viejas aplicaciones. ,
La necesidad de esta materia podemos encontrarla en el hecho de la La calidad del software y las nuevas metodologas junto con la necesidad
competitividad, la competencia ofrece al cliente mayores posibilidades de evidente de poseer una tecnologa suficientemente potente para adaptar los (
eleccin y precios ms bajos. Por otra parte, la garanta que se ofrece al procesos rpidamente a las nuevas y crecientes necesidades de un mercado
consumidor de obtener mercancas y servicios de calidad a los mejores precios, cada vez ms competitivo, han popularizado la necesidad de la reingeniera de
es que pueda contar con varios proveedores que compitan en el mismo la informtica y, tenemos que decir, que actualmente los resultados no estn a (
negocio. La competencia libre y abierta es la piedra angular en la que descansa la altura de lo que se esperaba. Por el hecho de necesitar los resultados (
nuestro sistema de economa de mercado. Adems las empresas o instituciones rpidamente no se han instalado de forma global procesos de reingeniera con ^
no siempre persiguen de una forma natural la competencia y el recorte de una metodologa adecuada en casi ninguna empresa; normalmente se ha
precios, pero su principal misin es conseguir los mximos beneficios para sus recurrido a este tipo de soluciones cuando el propio sistema necesita, de forma '
accionistas. La Informtica no se puede quedar fuera de este juego: los cambios urgente, una reparacin, lo que hace que se haya producido un alto ndice de
que se demandan del personal de proceso de datos son para mejorar la fracasos en los proyectos emprendidos y no por ello se puede achacar toda la (
competitividad y los resultados de la compaa, y tales cambios tambin culpa a deficiencias intrnsecas de este tipo de procesos sino a la falta de unas <
inciden en el propio departamento de informtica. buenas herramientas y metodologas suficientemente asentadas en la ,
organizacin de la empresa.
Para muchos la poltica de competencia es una idea abstracta, sin embargo,
los beneficios que nos reporta a todos son bien tangibles. Para demostrar esta Por esta razn es por lo que el tipo de reingeniera que se est imponiendo f
tesis basta con mirar la mala calidad de los servicios ofrecidos por los sistemas actualmente en las empresas (sobre lodo en Espaa) es la reingeniera de r
de economa planificada. La competencia, obliga a los fabricantes, en nuestro procesos, en base a la cual se estudian, se planifican y se redefinen los flujos de
caso de software y hardware, a mantener los precios ms bajos posibles si no trabajo y metodologas internas de las empresas para conseguir maximizar la (
quieren correr el riesgo d perder cotas de mercado. Adems, un sistema de eficiencia e, indirectamente, los resultados econmicos. A partir de aqu se ^
libre competencia sensibiliza a las empresas frente a las exigencias y deseos de desvela la importancia que est tomando el papel que juegan los departamentos
los clientes (las empresas con ciertos monopolios ofrecen al consumidor lo que informticos en la toma de decisiones empresariales, los viejos centros de
ellas quieren producir y no lo que ellos quieren que se produzca). La proceso de datos se reestructuran y pasan a asumir un papel protagonista en la 1
competencia tambin es un agente dinamizador estimulando a las empresas y gestin del cambio y en los procesos de planificacin estratgica de empresa. (
organismos a invertir, investigar, innovar y fabricar mejores productos que sus (
rivales. Por todo ello, en la lectura de este libro, nos fijamos unos objetivos (
especficos que se orientan a que el lector sea capaz de:
Es un hecho comprobado que los profesionales de centros de proceso de
datos cuyas empresas se han visto obligadas a competir, estn ms capacitados Estudiar la viabilidad y la conveniencia de desarrollar algn producto
para hacer frente a sus competidores y se han cultivado ms en el manejo de las informtico. 1
nuevas tecnologas. Planificar el desarrollo, con unos medios finitos, para lograr el mejor 1
resultado. (
Pero la competitividad no est cifrada nicamente en bajar los precios, Gestionar la realizacin de dicho producto controlando y evaluando los (
sino adems, en hacer las cosas mejor que los dems: ofrecer garantas de resultados producidos. (
funcionamiento, tener los productos con unas tasas de mantenibilidad bajas, Dimensionar un sistema informtico adecuado a unas necesidades (lo
ofrecer una buena documentacin tcnica. Cuando Michael Hammer acu el que significa no despilfarrar los medios).
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
Medir cuales son las prestaciones que dicho sistema informtico le est
ofreciendo.
Detectar los posibles "cuellos de botella", si los hubiese, as como sus
causas.
Evaluar y determinar los mtodos alternativos o las modificaciones
oportunas para conseguir, si fuera posible, un modo de explotacin que CAPTULO 1
mejore el rendimiento del sistema.
INTRODUCCIN
En resumen, dirigir un Proyecto de Informtica de una envergadura
creciente, en funcin de la experiencia que se vaya adquiriendo y adecuar los
recursos a la consecucin de los fines, en las mejores condiciones posibles.
A lo largo de la historia de la Informtica, en el desarrollo y gestin profesional
La organizacin de la obra se ha agrupado en captulos repartidos dentro de los sistemas de informacin se ha considerado de forma habitual que este
dos grandes mdulos: tipo de tecnologa era fruto del buen criterio del tcnico, que se entenda como
un artesano de la programacin. Este enfoque no es el que se pretende fomentar
Planificacin de Proyectos Informticos. en este libro, en el que se estudia la forma de aplicar un conjunto de mtodos,
Gestin de Proyectos Informticos tcnicas y herramientas en las diferentes fases del ciclo de vida de un proyecto
informtico. De hecho, se pondr especial nfasis en los aspectos de la
Se entiende que la materia de PLANIFICACIN Y GESTIN DE direccin de proyectos, las medidas de esfuerzo para su realizacin en las
SISTEMAS debe girar entorno a estos dos grandes temas, para ello, dentro del mejores condiciones econmicas, el establecimiento de las tareas a realizar, la
primer mdulo y despus de hacer una amplia introduccin a la planificacin, estimacin de recursos necesarios, la planificacin, cmo mejor adecuacin de
se va a pasar a estudiar las "tcnicas de representacin" y la gestin de tales los recursos a las tareas con una visin de futuro para evitar conflictos en la no
proyectos. Finalmente nos ha parecido conveniente aadir dos anexos para disponibilidad de recursos, la comunicacin tcnica, el control de calidad y de
explicar dos de las metodologas de gestin de proyectos ms utilizadas en costes, la documentacin del producto obtenido, y el mantenimiento, tanto del
nuestro entorno: PMBOK (Project Management Body O f Knowledge) y producto como de la propia documentacin.
METRICA (Gestin de Proyectos de la Administracin Pblica Espaola).
Debemos considerar que los contenidos de esta obra no son los de una
Los autores tratamos de poner en manos del estudiante una coleccin de ciencia que explica fenmenos de la naturaleza o de la sociedad, sino ms bien
toda la tecnologa existente a fin de contribuir a ayudarle a fijar el vasto campo se han de entender en el sentido amplio de conocimiento sistemtico con base
de la Ingeniera del Software desde el punto de vista de la planificacin y terica que permite construir y manejar objetos tiles dentro de unos escenarios
con limitaciones econmicas, temporales y de aceptacin. As pues, la
gestin de sistemas informticos.
planificacin de sistemas de informacin debe ser considerada una rama de la
ingeniera ms que una ciencia propiamente dicha. En cualquier caso, se ha
sealar que ste conjunto de fundamentos tericos y procesos de ingeniera
prctica conduce a la nueva visin de que la ingeniera puede aplicarse al
diseo y construccin de sistemas abstractos, aunque la afirmacin no adolezca
de detractores.
6 P L A N IF IC A C I N Y G E S T I N DE S IS T E M A S IN F O R M T IC O S C A P T U L O 1: IN T R O D U C C I N 7
1.1 LA E M PR E SA Y SU E N T O R N O utilizamos como punto de vista los factores productivos, obtendremos una
planificacin orientada a la productividad; si introducimos todos los factores
El desarrollo de aplicaciones informticas se lleva a cabo en el contexto de una que componen el conjunto de la empresa con el objetivo de su posible
organizacin de produccin de software. Por este motivo, antes de adentrarnos proyeccin en el tiempo, obtendremos datos de la planificacin estratgica; y
en la descripcin de aspectos eminentemente tcnicos, es conveniente as sucesivamente.
detenerse a analizar el marco de referencia en el que se van a situar los
proyectos informticos, constituido fundamentalmente por una o varias Sin embargo, en la definicin anterior, hemos introducido el trmino
empresas en las que se llevan a cabo unos determinados procesos y un tipo de ordenacin en el sentido de organizacin, entendida como la bsqueda de las
relaciones internas que pueden afectar al desarrollo de este tipo de proyectos. estructuras humanas y tcnicas para ejecutar la planificacin, obteniendo el
mayor rendimiento posible desde una consideracin dinmica de la
Una empresa podemos considerarla como una combinacin de factores organizacin empresarial. Segn Gutenberg, la empresa es una unidad que
orientados a prestar un servicio u ofrecer un determinado producto, dispone de unos factores de produccin determinados y que, a partir de la
normalmente, para conseguir un beneficio o resultado propio de su actividad. decisin del hombre, se combinan entre s para alcanzar unos servicios o
productos que va a colocar en el mercado.
Para lograr esto es necesario, en primer lugar, un negocio en el sentido de
cualquier actividad relacionada con la compra-venta o prestacin de servicios En este sentido, tenemos que considerar seriamente el entorno econmico-
que genere beneficio. Adems es necesario disponer, en trminos de economa social de la empresa, ya que la empresa est integrada por individuos,
normales, de una sociedad mercantil entendida como una unidad jurdica que organizados formal o informalmente, que desarrollan una serie de tareas
regula la relacin que produce el patrimonio del cual son titulares al menos dos cumpliendo una funcin social y, la empresa, en su funcin global se presta a
personas. Tambin se necesita de una unidad tcnica vista como un conjunto de dividir su funcionamiento en tareas especficas, de tal forma que se trate de
procesos tecnolgicos por los que un determinado conjunto de factores van a relacionar cada tarea con un individuo que la satisfaga.
ser trasformados en una serie de productos o resultados, y que se entiende con
el nombre de explotacin. Adems suele ser necesario un establecimiento, en Antiguamente la empresa buscaba una forma de realizar un producto,
forma de unidad espacial o fsica donde se localiza la actividad (puede ser una organizar la produccin y, finalmente, investigar la forma de vender mejor ese
planta, una factora software, unas oficinas, etc). producto. En el caso especfico de una empresa de software, normalmente se
obtena un producto que, posteriormente se trataba de vender. Hoy da el
Grandes investigadores de la gestin empresarial han ayudado a precisar proceso es a la inversa: primero se investiga qu se puede vender, despus se
los factores que intervienen en una empresa; as, Gutenberg, en Fundamentos desarrolla el proyecto de produccin, posteriormente acudir a los suministros
de la Economa de Empresa, establece dos grupos especficos de factores a o materias primas, y, finalmente llevar a cabo la produccin de lo que
considerar: los elementales y los dispositivos. Los aspectos elementales de la vender.
empresa estn formados por la materia prima, las factoras, los equipos, el
trabajo a realizar, en resumen todo aquello que se puede considerar como Hemos visto una dimensin social de la empresa, pero para entender mejor
activos materiales, que, por tanto se pueden ver, medir y contabilizar la planificacin de su produccin es necesario entender otra serie de
fcilmente. Por otra parte estaran los factores dispositivos o pautas dimensiones como son:
intangibles de gestin de la empresa, formados por la direccin, la propia
planificacin o forma de hacer el trabajo, la organizacin de todo el negocio, La dimensin funcional, entendida como la actividad organizada y
las patentes que pueda tener y el conocimiento y su gestin que puede alternativa al mercado con nimo de lucro
establecer elementos diferenciadores de una empresa respecto a otra. La dimensin tcnico-econmica, que se centra en el proceso de
trasformar productos. Es la actividad productiva de bienes y servicios.
En este contexto empresarial podemos decir que la planificacin es el La dimensin econmico-financiera, como unidad creadora de valor
proceso de ordenamiento de los factores en funcin de los objetivos. As, segn aadido. Es la actividad econmica que crea valor y dinero.
los factores que tratemos se obtendrn distintas visiones de la planificacin: si
8 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 F O R M T IC O S ___ _______ C A P T U L O 1: IN T R O D U C C I N
La dimensin jurdico-mcrcantil, que junto con la comercial es la que puedan realizar un aprendizaje continuo y la adecuacin permanente a su
actividad generadora de relaciones. puesto de trabajo con independencia del avance de las tecnologas.
Otros aspectos de la dimensin social, entendida como otra actividad
compuesta por relaciones humanas y de poder que establecen un Otro aspecto de inters a tener en cuenta en este captulo de introduccin
complejo diseo de comunicaciones y de relacin entre las personas es la presentacin de la figura del empresario, como responsable de una
que forman esa empresa organizacin que desarrolla software. En este sentido, podramos enumerar
algunas de las capacidades bsicas que ha de reunir cualquier empresario:
Tambin tenemos que comprender que existe una serie de factores que
condicionan la explotacin econmica, y que podemos clasificar en factores Una persona que asume riesgos.
independientes y dependientes. Entre los primeros se encuentra la Aquel que cede el capital para iniciar la actividad empresarial.
productividad que se obtiene por el mero hecho de poder modificar la prioridad Aquel que establece cmo se realiza la combinacin de factores dentro
de los recursos, la economa en la gestin, el equilibrio financiero o la de la empresa.
experiencia de saber hacer las cosas bien. Como factores dependientes Aquel que plantea innovaciones dentro de la empresa.
podramos citar los costes de obtencin de las licencias de los sistemas Persona que fija objetivos a conseguir, establece los medios que
operativos, el precio de los suministros bsicos o la rigidez del mercado laboral llevarn a conseguir esos objetivos y plantea las medidas econmicas
establecido por ciertos grupos de presin, los sistemas organizativos que oportunas y ms favorables para ello.
configuran el tipo de economa centralizada que condiciona la propia estructura
en cuanto a las posibles dependencias de la gestin o, incluso, la misma Si tenemos en cuenta la consideracin de Gutenberg del empresario como
realizacin de las actuaciones asignadas. directivo, en tanto factor dispositivo, con funciones de direccin, planificacin
y organizacin, puede afirmarse que tambin ha de tener la capacidad de
Al considerar los factores dependientes, debemos tener en cuenta que la adaptarse al entorno y a sus estructuras, de tal suerte que la empresa, como
actividad empresarial forma parte de un sistema de economa de mercado conjunto de funcionalidades, debe imprimir a sus procesos y estructuras un
que condiciona fuertemente el desarrollo de la propia planificacin carcter dinmico frente a los cambios, que le permita incrementar la utilidad
empresarial. Los pilares bsicos de la economa de mercado son la de todos y cada uno de los grupos o factores que la componen: personal,
configuracin de un mercado con un mecanismo de regulacin que trata de clientes, accionistas, la propia comunidad donde est implantada). En este
garantizar que las empresas funcionen con la misma eficiencia, es decir, que las sentido, es necesario hacer una breve reflexin sobre la globalizacin de la
empresas tengan las mismas oportunidades de sobrevivir en ese mercado. La economa1 ya que el valor de los recursos de una empresa tiene que evaluarse
primera consecuencia de ello es que el precio de los productos o servicios lo desde su dimensin mundial y en funcin de su utilizacin mundial, lo que nos
impone el propio mercado y no las empresas que operan en l. La economa de lleva a desarrollar nuevos diseos organizativos dentro de la actividad
mercado trata de garantizar una poltica social necesaria para que no existan empresarial, como pueden ser la movilidad rpida de las personas y de las
personas y actividades marginadas del mecanismo del mercado, basada en los estructuras2 que permitan trabajar con estructuras ms flexibles, y poder crear
principios de solidaridad y subsidiariedad, que van a imponer serias estructuras organizativas complejas para competir con ventaja en aspectos
restricciones, por ejemplo, en el calendario laboral del personal asignado a un globalizadores de la produccin. Esto supone crear una cultura empresarial
proyecto. Existen otra serie de factores que son necesarios en la economa de nueva que se oriente a los procesos y no a las funciones, con una coordinacin
mercado, como son una cierta estabilidad monetaria que permita la regulacin permanente y estableciendo una divisin del trabajo que permita obtener, en
de las operaciones por medio de un sistema financiero controlado por el cada momento, productos de mayor calidad y en el menor tiempo posible.
sistema poltico participado por el estado. Tambin se puede producir la
intervencin de los estados en la creacin de estructuras y tejido comercial,
para facilitar el desempeo de las funciones propias de la empresa y que
permitan reducir los costes externos. Otro factor dependiente sera la existencia 1 Las causas de la Globalizacin de la economa se deben fundamentalmente a la eliminacin
de barreras polticas, aduaneras, financieras, culturales, etc.; as como a la descentralizacin
de un sistema educativo que contemplase la capacitacin de los individuos para
geogrfica 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 S T I N D E S IST E M A S IN F O R M T IC O S _________________________ C A P T U L O I: IN T R O D U C C I N
Un proyecto que ocupa a una persona durante ocho meses es un proyecto de produce una lnea base o configuracin ele referencia que es tomada como
ocho programador-mes. Pero quizs, no pueda terminarse en cuatro meses por plataforma para las actividades de la siguiente etapa.
dos personas o, peor an, en dos meses por cuatro personas. La cada de
productividad a medida que el tamao del equipo se incrementa es tan El mantenimiento del software puede entenderse como el proceso de
dramtica, que equipos de tamao medio o grande pueden no llegar a producir modificar un sistema o componente software despus de la entrega aI cliente o
absolutamente nada til (Sommerville en Software Engineering). usuario para corregir defectos, mejorar el rendimiento o atributos, adaptarlo a
un cambio de entorno o ampliar su funcionalidad [IEEE, 1993]. En este
En muchos casos se puede atribuir la disminucin de la productividad a los contexto, una lnea base puede considerarse como un producto o especificacin
problemas de comunicacin entre los miembros del equipo. En este sentido, se que ha sido formalmente aprobado por los miembros del proyecto de desarrollo
puede afirmar que cuantas ms personas involucradas, ser necesario utilizar y slo podr cambiarse mediante procedimientos formales de control de
ms tiempo en la comunicacin entre los miembros del equipo; as, en un cambios. De una manera ms sencilla se puede tomar como una fotografa
equipo de tres personas hay tres canales de comunicacin entre esas personas, aprobada del sistema en un momento dado de su configuracin.
pero en un equipo de cuatro hay seis canales de comunicacin. Siguiendo esta
progresin se puede entender que en equipos muy grandes, a pesar de las
estructuras jerrquicas que se decidan para la administracin del proyecto, las
vas de comunicacin crecen desorbitadamente en nmero, con lo que la 1.3 LA P L A N IF IC A C I N Y G E ST I N E N LA IN G E N IE R A DEL
comunicacin entre los miembros del equipo se hace cada vez ms importante S O FTW A R E
y a la vez ms trabajosa. La Ingeniera del software se cre como un intento para resolver los habituales
problemas que se plantean en las organizaciones dedicadas al desarrollo de
Como el nmero de canales de comunicacin crece ms deprisa que el software o sistemas de informacin, entre los que se encuentran los siguientes:
nmero de personas involucradas, un equipo de desarrollo de tamao mediano
o grande emplea proporcionalmente ms tiempo coordinando (y menos tiempo La imposibilidad de satisfacer en unos plazos razonables las crecientes
progresando) que un equipo pequeo. Como el tamao del equipo crece en necesidades marcadas por sus clientes, cuyas expectativas hacen que
algunos puntos crticos del proyecto, todo el tiempo se emplea en cada da el desarrollo sea ms complejo.
comunicacin entre miembros y en acomodar lo ya producido a las estructuras
recientemente acordadas, y no se deja tiempo para el progreso real. Los altos costes de mantenimiento debido fundamentalmente la escasa
o nula documentacin de los sistemas.
En el pasado, las tareas de los programadores consistan exclusivamente en
codificar y depurar, sin dar importancia a disear el software antes de La necesidad de terminar el producto, en muchos casos a cualquier
desarrollarlo. En general, no se usaban modelos para asegurar que el resultado coste, en un periodo limitado de tiempo debido, sobre todo, a problemas
final se ajustase al propsito inicial, o para definir una estructura de programa de competitividad.
prctica y mantenible.
Se trata, por tanto de llevar a cabo una produccin industrializada del
De esta forma los cambios producidos por la adaptacin al Euro o la software para as mejorar la calidad total de los productos y disminuir los
problemtica del ao 2000 han hecho que una gran cantidad del software costes de mantenimiento. Esto implica tambin la necesidad de plantear una
antiguo existente haya sido imposible de modificar; y es que, cuando se autntica ingeniera de procesos, estudiando, planificando y definiendo los
desarrollaron los grandes programas que an permanecen funcionando, fueron mtodos de trabajo y sus flujos para conseguir maximizar la eficiencia e,
pobremente estructurados y escasa o nulamente documentados, de tal suerte indirectamente, los resultados econmicos.
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 Por todo ello, las actividades de gestin destinadas a la planificacin, el
la aparicin de la Ingeniera del Software, los ingenieros aprendieron a seguimiento y control de los procesos y recursos, tanto humanos como
desarrollar los grandes sistemas en una serie de etapas, cada una de las cuales materiales, que intervienen en un proyecto software tambin han de
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 F O R M A T IC O S __________________________________________ C A P T U L O I IN T R O D U C C I N ______ __________________________ 15
considerarse como actividades de la Ingeniera del Software, que debern actividades de ingeniera de proceso, encargadas de la planificacin y control
integrarse con las de desarrollo para conseguir conjuntamente la obtencin de de las anteriores. Sin pasar por alto, la conveniencia de que tal metodologa
un producto software de calidad, fcilmente mantenible y a un coste y en un incluso supere los lmites de un proyecto en particular, y contemple tambin la
tiempo razonables. definicin de los procesos de planificacin estratgica de las empresas que
permitan prever su evolucin tecnolgica a medio o largo plazo.
En la figura 1.2 se muestra la integracin de los dos tipos de actividades.
En el caso de las actividades de gestin, en primer lugar se realiza la
planificacin del proyecto, en la que se definen las condiciones de trabajo, los
recursos, las fechas y se estiman los costes. A continuacin comienza el
desarrollo segn el plan establecido y, en paralelo, las actividades de
seguimiento y control para vigilar el avance del proyecto.
0 a o
Planifie Seguimiento
acin => y Control
CAPITULO 2
DEFINICIONES BSICAS
ofrecidos por las distintas empresas: Se luchaba por la calidad a la vez que por automtica y se obtienen grandes resultados basados en la eficiencia de los
la produccin en masa que haca el producto ms competitivo en un mercado medios empleados.
global.
Los sistemas de produccin por lotes son los ms frecuentes y son los que
En los aos siguientes las empresas enfocaban sus productos hacia la per se producen utilizando los mismos medios para producir bienes distintos a lo
sonalizacin o variedad. Las empresas ponan a disposicin de sus clientes un largo del tiempo. Como ejemplo se puede considerar una empresa de tipo
catlogo de productos lo mas variado posible como fuerza de ventas. Era taller de mecanizados que un da tiene un encargo de fabricar una cantidad
necesario haccr proyectos diferenciadores de la competencia para poder seguir de piezas concretas y, algunas horas ms larde, otro tipo de productos
manteniendo el pulso de la produccin industrial. utilizando las mismas herramientas y el mismo personal. El aspecto ms
importante para la rentabilidad de este tipo de sistemas de produccin es la
ltimamente el mercado exige novedad. El cliente con capacidad econ flexibilidad. Cada ensayo sufrido valdr para incorporar una nueva experiencia
mica de comprar un producto desea algo tecnolgicamente novedoso, y los para el futuro. Los sistemas son adaptables y se reutiliza la tecnologa
equipos de diseo hacen productos enfocados en esta vertiente. aprendida en la fabricacin de cada producto.
Pero desde los principios de la organizacin empresarial se ha visto que es En contraposicin a los sistemas anteriores, los proyectos informticos
necesario introducir una cierta previsin de lo que suceder. As podemos normalmente son no repetbles, en el sentido de que su naturaleza suele ser
definir la previsin como la accin y efecto de ver con anterioridad o nica, y los medios para alcanzar ese bien futuro suelen ser nuevos cada vez, lo
conjeturar con ciertas seales lo que suceder. Es decir, hablamos de anticipar que implica que exista una considerable expectacin sobre los pasos a seguir, y
el futuro en base a cierta informacin, ya que no se trata de tener una frmula que supone, por tanto, un cierto riesgo a sufrir.
mgica que adivine el futuro.
Es necesario, en base a las consideraciones anteriores, establecer una dife
En este sentido es necesario hacer una pausa y considerar cmo son los rencia clara entre lo que son los productos, los resultados del proyecto y el pro
proyectos que se realizan en las distintas fbricas u oficinas, y considerar las yecto en s mismo: as podemos definir los productos como esos bienes futuros
diferencias que existen entre los proyectos y los sistemas de produccin. a obtener, es decir, los bienes o servicios que la organizacin fabrica segn la
Podemos establecer, siguiendo este razonamiento, tres categoras dentro de la naturaleza de sus objetivos, y que para fabricarlos se necesita de los resultados
totalidad de los sistemas de produccin existentes en el mundo actual: por una del proyecto. Estos resultados se definen por los objetivos mismos del proyecto
parte estara la categora de produccin en masa, por otra parte las factoras que y suelen formar parte del conocimiento de las propias empresas por lo que,
hacen produccin por lotes y, finalmente, aquellas industrias que realizan normalmente, no se ceden a terceros.
proyectos normalmente no repetitivos, mejoras, adaptaciones.
En el caso concreto de los proyectos, debido a que son actividades inicia
Los sistemas que circundan la produccin en masa se disean para optimi das para obtener un bien futuro, no se puede asegurar que los planes y
zar cada una de las fases o tareas con objeto de reducir costes, aumentar la estimaciones sean correctos, pero es posible ir formando una base de
calidad y mejorar los procesos. As las fbricas tienen sus ingenieros del conocimiento para aplicarla a futuros proyectos ms o menos afines.
departamento de mtodos y tiempos, o algn nombre similar, que estudian la
duracin de cada fase, los materiales que se emplean, sus utillajes, etc. En otras palabras, cuando hablamos del futuro que deseamos lo tenemos
entendiendo que optimizando cada uno de estos elementos atmicos se mejora que configurar desde el presente y, en el mejor de los casos, a lo ms que pode
la calidad del producto. La ventaja de este tipo de produccin es que obtiene mos aspirar es a hacer pronsticos en los resultados obtenidos hasta el
datos de la experiencia anterior y continuamente trabaja por la mejora continua. momento actual y en la buena medida efectuada sobre esos resultados.
Es normal que cada una de las fases est perfectamente informada por un
sistema de gestin que recoge estadsticas para ayudar a la toma de decisin de Por otra parte, se habla de un conjunto de procesos o actividades..., es
las posibles debilidades y mejoras a introducir. Los datos se capturan de forma decir, son ms 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
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 F O R M A TICOS C A P T U L O 2: D E F IN IC IO N E S B S IC A S 23
recursos disponibles en el momento en el que ms nos puedan interesar. Esta condiciones administrativas y su implicacin con los otros proyectos, o con
consideracin es importante porque, como se ver a lo largo del libro, se actividades coyunturales que puedan surgir.
necesitan cualidades para poder controlar cada una de estas actividades.
Es necesario conocer de forma detallada las condiciones de contorno, en
Otro aspecto importante, sobre todo de la ltima definicin, es la palabra particular las prioridades del proyecto y, a ser posible, tratar de tener un
dirigidas y tambin se hablar de forma detenida de lo que se entiende por calendario en el que se fijen los hitos ms importantes del mismo. Hay que
direccin desde el punto de vista de timn que controla el rumbo del considerar la poltica de la propia compaa respecto a este Proyecto porque
proyecto. Pero el director (o gestor) del proyecto necesita del poder de decisin puede definir la atencin que se puede esperar de sus directivos. En algunos
necesario para poder administrar un determinado marco de referencia. 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
Tambin ha surgido el trmino control, que en su momento ley o contradecirla por no conocerla.
entenderemos que es la posibilidad de saber en cada momento la posicin
exacta en que nos encontramos en el desarrollo del proyecto. No es posible Un nfasis especial tendremos que dar a las necesidades de comunicacio
separar la palabra gestin del trmino control debido a que no se puede gestio nes que los entornos modernos demandan. En este sentido se debe de
nar algo con ciertas garantas de xito si no se controla. considerar la posibilidad de disponer de herramientas de gestin automtica de
bases de conocimiento y mensajera para todo el grupo de desarrollo que, en
algunos casos, puede estar constituido por personas fsicamente distantes lo
que nos puede llevar a considerar la necesidad de infraestructura adicional,
2.2 T IP O S D E P R O Y E C T O S como puede ser videoconferencias, correo electrnico, y, en general, la
disponibilidad de tejido industrial
Podemos clasificar los proyectos segn varias vertientes o aspectos:
Con este tipo de informacin la Direccin de la empresa aborda la decisin
Tcnicos y no tcnicos de comenzar el proyecto. En el captulo quinto se desarrollan los aspectos
Unipersonales y inultipersonales econmicos y algunos parmetros sobre el estudio de la rentabilidad.
Monodisciplinares y multidisciplinares Ejemplos de proyectos pueden ser:
Monocontrato o multicontrato
La sustitucin de un sistema informtico en una empresa.
Resultados: tangibles o intangibles
El traslado de un determinado departamento de una planta a otra.
Rentabilidad econmica o rentabilidad social
La fabricacin de un nuevo electrodomstico en una fbrica de
Con fines claros: proyectos espaciales
lavadoras.
Las caractersticas de cada tipo de proyecto nos pueden servir para estudiar El desarrollo e implantacin de un nuevo Sistema de Informacin para
el entorno entendido como el conjunto de condiciones en las que se va a el departamento de ventas de una organizacin.
realizar el proyecto. El entorno puede cambiar en funcin de otro tipo de La migracin de un sistema informtico basado en terminar orientado a
prioridades ajenas al propio proyecto. Una de las amenazas ms fuertes sobre carcter a consultas tipo web.
el proyecto es el contexto socio-econmico, por lo que tendremos que La implementacin de un sistema de e-businnes.
formularnos preguntas del tipo Podemos cambiar el entorno del proyecto a La contratacin de un sistema de soporte para una determinada planta
nuestra voluntad? Se modificar el proyecto si cambian las condiciones de fabricacin industrial.
extemas?. El establecimiento de una serie de indicadores de captura automtica
que midan la evaluacin del desempeo del personal.
Igualmente, en funcin 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 segn el presupuesto previamente establecido, las
PL A N IFIC A C I N Y GESTIN DE S IS T E M A S INFORM TICOS C A P T U L O 2: D EFIN IC IO N ES BSICAS 25
24
Una vez fijados los aspectos generales vamos a tomar tierra' con los procesos T
de ingeniera del software entendidos como las etapas que debe satisfacer un PSl 4
PSl 6
D is e o i f / o d d o
ld n l^ i c c i& n d *
proyecto de informtica para llegar a su fin. En este sentido es necesario que el 0# S 't l e m a s d e
in fo rm a c i n
En este sentido tiene capital importancia seguir las pautas de: Figura 2.1 Secuencia de actividades segn Mtrica V.3
Estructura funcional: Las tareas del proyecto, las funciones y las Entre las cualidades que se deberan buscar para el Director del Proyecto
actividades se clasifican en categoras diferenciadas entre s y se cabe destacar las siguientes:
ordenan en funcin del objetivo a cubrir por el proyecto.
Mente estructurada y lgica
Estructura de autoridad: Se establece una jerarqua entre el personal Liderazgo y Aceptacin por el grupo de trabajo
determinando las responsabilidad de cada uno y sus controles. Conocimiento del sector de la actividad del proyecto
Madurez
Estructura de decisin: Cada persona, segn la autoridad que posee, Formacin especfica en aspectos gerenciales (direccin por objetivos)
tiene la capacidad de adoptar una u otra decisin
En concreto es necesario mantener un cierto equilibrio entre directivo y
En este apartado no podemos olvidar los principios organizativos clsicos tcnico. Es de considerar que el principal reto personal del director est en
que hacen que el grupo de proyecto funcione debidamente: encontrar ese difcil equilibrio entre sus funciones directivas -m uy importante-
y el papel tcnico. De hecho si aspira a un puesto superior dentro de su
Principio de objetivo: Cada componente del proyecto tiene que organizacin debe de tener preparado un sucesor lo suficientemente preparado
contribuir a conseguir el objetivo fijado por dicho proyecto. 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.
Principio de definicin: Es necesario especificar al mximo las tareas
que cada persona tiene que desempear y qu responsabilidades tiene La direccin es tcnica, ciencia y artel. En este sentido es necesario, en las
en ese sentido. empresas actuales, que los empresarios y directivos sean capaces de guiar a su
empresa u organizacin en un proceso de continua transformacin que, para
Principio de autoridad: Es necesario limitar el nmero de personas con adaptarse a su entorno, necesitarn afrontar debidamente. Pero para poder guiar
el que nos tenemos que relacionar. Limitar las relaciones entre personas o conducir a sus empresas, se necesitan de unas dotes de liderazgo para que su
y funciones. personal confe en ellos y les tenga como referencia en el bien hacer las cosas.
Sin embargo las caractersticas de los lderes sueles ser distintas, sobre todo si
Principio de responsabilidad: La responsabilidad de cada directivo
abarca tambin la responsabilidad de los subordinados. 1 Arte: Conjunto de reglas o preceptos para conseguir hacer bien una cosa (Diccionario de la
Real Academia de la Lengua Espaola)
28 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 F O R M T IC O S _________________________ C A P T U L O 2: D E F IN IC IO N E S B S IC A S 29
Disciplina
Concentracin
Paciencia
Preocupacin
Razn y humildad
Una serie de habilidades, entre ellas:
Liderazgo
Creatividad
Capacidad de integracin
Aficin al orden y al control
P la n ificac i n listn
Por otra parte, los criterios de terminacin son bsicos para poder A N A L IS IS D EL S IS T E M A
establecer las responsabilidades finales en una actividad que siempre va a tener
que estar siendo mantenida. Este factor ser mucho ms importante en tanto A jilisis d e
que la necesidad de un proyecto nazca de una empresa cuya relacin con el R eq u isito s
del S is te m a
grupo de desarrollo sea, o no, ajena al mismo. Estos factores, o criterios de
terminacin, deben de ser discutidos por ambas partes y consensuados para T T T
E specificacin
Funcional del
que, finalmente, quede perfectamente escrito en el documento de alcance o S istem a _
especificaciones del proyecto.
.-s r s r x r r - - " D iseo
d el S istem a
Con este documento, tanto la direccin como el grupo de desarrollo, debe
de tener suficiente informacin como para saber en qu se estn C o n s tru c c i n
del
comprometiendo, y si pueden o no aceptar el proyecto, sus plazos y sus
S is te m a
clusulas sin incurrir en penalizaciones que pueden ser muy perjudiciales tanto
para el equipo de desarrollo como para la organizacin origen del proyecto. Im p lan tac i n
del
S istem a
2.7 E L C IC L O DE V ID A I)E U N P R O D U C T O IN F O R M T IC O
El ciclo de vida es el conjunto de fases por las que debe pasar un proyecto de Figura 2.3. Fases del ciclo de vida de un Sistema de Informacin
desarrollo de un sistema de informacin desde su concepcin inicial hasta que
el sistema deja de utilizarse o se transforma en otro.
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 F O R M T IC O S C A P T U L O 2: IJH F IN IC IO N H S B A S IC A S 35
34
Aunque en la segunda parte de este texto se describen con detalle todas las Tambin se planificarn las pruebas que deber superar el
actividades a realizar en cada fase, a continuacin se indica someramente el sistema, se estimar la relacin coste/beneficio para comprobar
objetivo de cada una de ellas: si interesa su construccin y se establecern los plazos de
entrega del sistema. Todo ello se recoge en dos documentos,
Planificacin Estratgica: No se considera estrictamente como una denominados "Documento de Especificacin Funcional del
fase del ciclo de vida, ya que su existencia es opcional (no es necesaria Sistema" (DEFS) y "Documento de Pruebas del Sistema"
si se desarrollas un sistema aislado), y no afecta a un slo sistema. Si (DPS).
existe, su objetivo es adecuar los objetivos estratgicos de la
organizacin (de usuario) y la informacin necesaria para soportar Fase de Diseo (conocida tradicionalmente como "Anlisis Orgnico"):
dichos grandes objetivos. Para tal labor se hace necesaria una El objetivo de esta fase es obtener un conjunto de especificaciones que
metodologa de planificacin de sistemas que abarque a toda la contemplarn los aspectos fsicos del sistema, considerando las
organizacin y exija considerar una serie de conceptos que desbordan el caractersticas tecnolgicas del entorno especfico en el que se
marco especfico de una Metodologa de Desarrollo de Sistemas, por lo implantar, que constituirn el punto de partida para la construccin del
que no se tratar en este texto. No obstante, si se ha llevado a cabo, el sistema. Al final de esta fase se obtienen el "Documento de Diseo
producto final que se habr generado, ser la definicin de los sistemas Tcnico" (DDT) y el anterior "Documento de Pruebas del Sistema"
de informacin que se deben desarrollar para satisfacer los objetivos (DPS) con las ampliaciones relativas a la definicin del entorno de
estratgicos de la organizacin. Por tanto, la parte de este documento pruebas.
que haga referencia al sistema concreto que se vaya a desarrollar, puede
ser el punto de partida para la siguiente fase, la de Anlisis del Sistema. Fase de Construccin: El propsito de esta fase es, a partir de las
especificaciones de diseo, la obtencin del sistema completamente
Fase de Anlisis: El objetivo de esta fase es el estudio de las construido y probado, listo para ser implantado en la organizacin de
necesidades de informacin que debe satisfacer el sistema a desarrollar, usuario. Tambin durante esta fase se desarrollar el conjunto de
elaborando una serie de especificaciones formales que describan la procedimientos y se llevar a cabo la formacin necesaria que
funcionalidad del mismo y que permitan abordar con garantas la permitir, tanto al personal del rea de usuario final como al personal
siguiente fase (Diseo). Esta fase de Anlisis se puede estructurar en del rea de explotacin o proceso de datos (si existe), la utilizacin
dos sub-fases claramente diferenciadas, en las que se lleven a cabo tales ptima del sistema. Adems del software correspondiente, al final de
actividades: esta fase tambin se obtendrn los siguientes documentos:
"Documentacin Tcnica de Programacin" (DTP), "Manual de
o Anlisis de Requisitos del Sistema: Se trata de establecer el Usuario" (MU), "Manual de Explotacin" (ME), "Documento de
alcance, los objetivos y requisitos del sistema, examinando las Pruebas del Sistema" (DPS), ampliado con los informes de las pruebas
posibles alternativas que podran solucionar las necesidades del unitarias, de integracin y globales.
usuario (cliente) y recomendar una de ellas. Al final de esta sub-
fase se obtiene un documento denominado "Documento de Fase de Implantacin: El objetivo de esta ltima fase es la puesta en
Requisitos del Sistema" (DRS). servicio del sistema construido y conseguir su aceptacin final por parte
de los usuarios del mismo, para lo cual se tratar de hacer ver a stos,
o Especificacin Funcional del Sistema (conocida mediante demostraciones formales (pruebas de aceptacin), que el
tradicionalmente como "Anlisis Funcional"): Una vez aceptado sistema cumple todos los objetivos y requisitos para los que fue
formalmente el documento anterior por las partes (organizacin desarrollado. En esta fase se incluye la ejecucin y el mantenimiento
de desarrollo-organizacin de usuario), se elabora un conjunto del sistema, con lo que su duracin se prolongar hasta que el sistema
de especificaciones formales que describan la funcionalidad del deje de utilizarse o sea sustituido por otro.
sistema, estableciendo los subsistemas en que se descompondr,
definiendo los datos que utilizar y las interfases de usuario.
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 F O R M TIC O S
CAPTULO 3
FACTORES DE DIMENSIN
Con este documento podr hacer una estimacin razonada del esfuerzo a
realizar en cada una de las etapas del ciclo de vida del proyecto, es decir, que 3.1 E SF U E R Z O T O T A L D E D IC A D O A L SO FTW A R E
tiempo estima que se ha de dedicar al anlisis funcional, cuanto al diseo,
cuanto al desarrollo, etc. 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
La segunda fase para efectuar una posible planificacin del proyecto es la objetivo final del cliente o de la organizacin usuaria del sistema de
estimacin de los recursos que son necesarios para acometer el esfuerzo de informacin. En general todo se traduce en precisar un equilibrio en el
desarrollo de software anteriormente sealado: por una parte los recursos tringulo del triple compromiso: Calidad, coste y calendario.
mquina o herramientas necesarias para facilitar el desarrollo de las distintas
tareas y, por otra parte, las personas que utilizan esas mquinas y/o
herramientas. Cada recurso se debe especificar por cuatro caractersticas:
Las dos ltimas caractersticas son en s una tabla mltiple y, veremos ms Figura 3.1 El tringulo del triple compromiso
adelante, que tales fechas y duraciones son fluctuantes en un tiempo concreto
debiendo ser su disponibilidad -referida a esa fecha- lo ms pronto posible.
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
40 ______________ 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 F O R M T IC O S _________________________ 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 41
el estudio de los avances surgidos en esta rea de inters junto con las
presiones de la alta competitividad y la naturaleza de adaptacin al cambio a Hemos sealado en el captulo anterior la necesidad de poner lmites al
los que estn sometidas la mayora de las Organizaciones. Este entorno fuerza proyecto y, en particular, tenemos que delimitar el mbito del software en el
a que cada da se consideren con mayor nfasis el requerimiento de disponer de sentido de marcar claramente lo que se quiere que efecte el nuevo sistema y lo
sistemas de informacin muy flexibles para poder adaptarse a las exigencias que no se desea mecanizar en el proyecto actual ya que muchos proyectos 110 se
que demanda el mercado y con una rapidez de adaptacin hasta ahora casi terminan, o se terminan fuera de plazo, por 110 saber cunto falta para que se
inimaginable. termine de desarrollar. E11 este sentido tenemos que manifestar que el proyecto
termina cuando se ven satisfechos todos y cada uno de los requisitos (software
En particular, dentro del apartado Planificacin de Sistemas de o de cualquier otra ndole) del sistema.
Informacin, Mtrica v.3 establece una serie de actividades, que se describen el
la figura 3.2, para alcanzar un objetivo claro que es "la obtencin de un marco Para efectuar la planificacin del proyecto se debera disponer de una serie
de referencia para el desarrollo de sistemas de informacin que responda a los de datos cualitativos y cuantitativos en forma de requisitos (tiempo mximo de
objetivos estratgicos de la organizacin . transaccin, nmero de usuarios mximos, interfases grficas...) que
desgraciadamente no se conocern hasta una vez avanzada la planificacin, y
Este alineamiento de los Sistemas de Informacin con la estrategia de la sin embargo, dentro de nuestra disciplina, tendremos que efectuar ms de
organizacin donde se implica directamente la alta direccin en la propuesta de alguna planificacin tentativa antes de conocer el proyecto con a un nivel de
solucin va a presentar una serie de ventajas, como son: detalle suficiente. Tendremos que aventurarnos efectuando algunos tipos de
consideraciones sobre el tipo de proyecto que se quiere realizar y, en muchos
Se crear una perspectiva ms horizontal de los procesos dentro de la casos, fundamentalmente en fases tempranas de la planificacin, tendremos
Organizacin donde los interesen generales tendrn una mayor que efectuar ensayos de distinto tipo de actuaciones para acometerlo.
importancia en contra de cada uno de los intereses particulares que
podran desvirtuar los objetivos estratgicos y que obligar a un estudio Con el documento de requisitos (ms o menos detallado) y con la lista de
minucioso de los procesos. objetivos, as como con un posible calendario forzado, el director podr
estimar, en una primera fase, el esfuerzo a desarrollar en cada etapa. Con
La implicacin de alta direccin permitir disponer de los recursos posterioridad podr obtener una especificacin de los recursos que sern
suficientes que permitir ofrecer resultados dentro del calendario necesarios para acometer el proyecto.
acordado.
Con las ideas anteriores podemos lanzarnos a tratar de efectuar un primer Antes de continuar con la especificacin de recursos vamos a ensayar una
esbozo de lo que ser el proyecto, al menos en sus lmites, para poder efectuar clasificacin de los proyectos de ingeniera del software segn su dimensin.
un clculo inicial del esfuerzo necesario para poder desarrollar eficientemente Para ello vamos a considerar las necesidades de recursos segn el tipo de
el proyecto. De esta forma nos encontramos en disposicin de introducir el problema a resolver.
trmino de Planificacin del Proyecto entendida como la ciencia que suministra
un escenario al director para poder efectuar estimaciones razonadas de los Decamos, cuando habbamos del tringulo del proyecto, que las
recursos, poder efectuar un presupuesto de costes, obtener visibilidad para dimensiones de todo proyecto son calendario, coste y cantidad de producto. La
determinar los mtodos necesarios a utilizar para terminar el proyecto y, en dimensin del proyecto puede determinarse dentro de las variables de
resumen, poder disponer de todo lo anterior para realizar el proyecto con un complejidad, de riesgo, de calidad y de tamao, como veremos a continuacin.
mximo de eficiencia.
44 P L A N IF IC A C I N Y G EST I N D E S IS T E M A S IN F O R M T IC O S 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 45
El factor complejidad puede ser tratado, a su vez, desde varios puntos de caracterstica suele ser con la que ms frecuentemente se clasifican los
vista: Por una parte podemos hablar de la complejidad de datos, de mtricas, proyectos a la vez que anticipamos que a mayores proyectos en tamao ms
algortmica o de operaciones, ciclomtica y de la arquitectura en s. La probabilidad de no cumplir los plazos de entrega del proyecto.
complejidad de datos normalmente expresa la dificultad, o sencillez, de un
determinado mdulo que se mide en funcin 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 clasificacin de los proyectos por categoras. Lo mismo ocurre 3.4 DISTRIBUCIN DEL TIEMPO A LO LARGO DEL CICLO DE
con la complejidad algortmica y la ciclomtica que trata de ver la complejidad VIDA DE UN SISTEMA INFORMTICO.
de la lgica de uno o varios programas. Otro caso es la complejidad de la
arquitectura del sistema y las relaciones de dependencia que se pretendan En los proyectos informticos se da el hecho de que la cantidad de recursos
establecer1 que definen un cierto acoplamiento que es importante a la hora de puestos a disposicin del director no es constante a lo largo del tiempo. Suele
valorar los proyectos. ser normal que las primeras fases de tanteos de bsqueda de solucin,
presupuestos iniciales no definitivos y valoracin del alcance, lo realice un
La dimensin del producto visto desde la perspectiva del factor riesgo trata nmero muy reducido de personas. El objetivo fundamental de este reducido
de clasificar los proyectos segn la probabilidad de impacto en el negocio y las equipo de personas ser tratar de fijar el proyecto y establecer, dentro de lo
consecuencias que de cumplirse el impacto se derivaran del sistema de posible, las lneas bsicas de actuacin. Como objetivos secundarios se
informacin que se desea crear frente a la organizacin. Considerar los riesgos intentar recoger toda la informacin del cliente tratando de alcanzar las lneas
dentro de la fase de ejecucin del proyecto es muy importante ya que, de generales de sus necesidades para dar cumplimiento de ciertas consideraciones
satisfacerse el riesgo, posiblemente toda la planificacin del proyecto se vera comerciales entre las que se encuentra elaboracin de la posible oferta
afectada por el propio impacto de una serie de amenazas en los puntos ms econmica de servicios, las reglas que detallen la forma de facturar y se
vulnerables. ensayar, igualmente, a establecer los criterios de terminacin. En esta fase se
suele exigir, por parte del contratista, que se establezcan ciertos patrones de
El factor calidad puede clasificar los proyectos segn el resultado en calidad, de seguimiento y de seguimiento del proyecto a fin de garantizar el
cuanto al buen funcionamiento en el tiempo del sistema de informacin creado. perfecto desarrollo del mismo dentro de los patrones de seguridad de la
As no es lo mismo los requisitos de calidad que se establecen en la empresa.
construccin de un software comercial como en el software que gobierna una
planta nuclear donde, por ejemplo, un mal funcionamiento de algn En esta fase de conocimiento de las necesidades del cliente suelen tener
componente puede acarrear problemas de salud a los individuos. Normalmente una importancia muy alta las gestiones comerciales y los acuerdos tcitos que
las mximas exigencias de calidad se demandan en software empotrado en se alcancen. Es normal que se establezcan penalizaciones en caso de no
ciertos equipos electrnicos que, en caso de funcionamiento errneo o cumplimiento de alguna de las partes y que se contemplen todas las
indisponibilidad, pueden traer como consecuencia, la prdida de vidas especificaciones del contratista y se describa un primer documento con la
humanas. especificacin del producto haciendo un buen desglose del proyecto.
La dimensin tamao es la mejor pauta para clasificar los distintos tipo de Una vez que el proyecto avanza y se cuenta con la aprobacin del cliente
proyectos dentro de una empresa que normalmente efecta trabajos ms o trataremos de adecuar los objetivos estratgicos de la organizacin y la
menos parecidos dentro de las mismas prcticas ingenieriles. De esta forma es informacin necesaria para soportar esos objetivos. El proceso anterior puede
posible hablar de proyectos grandes, medianos o pequeos, en funcin del ser un punto de partida para la Metodologa de Desarrollo de Sistemas. Con
nmero o cantidad de funcionalidades previstas, del nmero de lneas de esta informacin se intuye una posible luz de salida, se incorporar ms
programa fuente a producir, del tiempo de desarrollo y, en general, de la gente a realizar labores de anlisis, que an constituir un grupo pequeo de
cantidad de esfuerzo a invertir en el proyecto. Es de sealar que esta personas, cuyo espacio en el tiempo puede dilatarse pero que no supone el total
de las fuerzas del equipo del proyecto.
1 Zhao J. On assessing the Complexity o f Software Architectures, Proccedings o f Lnteligent
Software Archileclure, ACM, pp. 163-167, Orlando, Florida, 1998.
46 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 F O R M T IC O S 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
La duracin de esta fase es bastante ms medible que la anterior. El Dentro de los recursos nos encontramos con dos tipos fundamentales de
director ya 110 tiene que someterse a un nmero alto de variables cuya respuesta recursos:
est en manos del cliente y, estudios realizados demuestran que los recursos
trabajan en el proyecto con ms continuidad. Recursos humanos
Recursos materiales
En la fase de diseo arquitectnico el grupo es ms numeroso, aunque
todava es pequeo comparado con el personal que interviene en el diseo Dentro de los recursos humanos, nos ocupamos de las personas que
detallado. Posteriormente se incorpora un nmero alto de personas y el trabajan para nuestra organizacin y de la que necesitaremos tener informacin
proyecto trabaja con un mximo de recursos que poco a poco se irn sobre su formacin, su capacidad y su actitud frente al proyecto para poder
reduciendo hasta la puesta en marcha del sistema y el posterior mantenimiento. determinar el tipo de tareas que se les puede asignar de forma individual y
colectiva. Esta informacin se puede organizar en forma de fichas,
Es de sealar que la etapa inicial de mantenimiento puede requerir un mecanizadas o no, sobre las que se tengan datos de la persona en s misma, de
nmero elevado de personal, aunque este nmero deber disminuir en poco su disponibilidad tanto general como particular para el proyecto, lo que llevara
tiempo, si no existen mejoras o adaptaciones importantes, permaneciendo a poder informar de las distintas fechas en las que se le requiere cada recurso
constante con tendencia a la disminucin a partir de un cierto momento. para cada proyecto concreto o, en su caso, la duracin a partir de cada fecha de
comienzo.
Como se ver en el captulo noveno la distribucin de esfuerzos frente al
tiempo en el desarrollo de sistemas informticos sigue el modelo de la funcin Existen muchos factores que inciden en los recursos humanos como
de Rayleight representada en la figura 3.2. pueden ser la motivacin, la especializacin 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 autonmicas se deben de considerar en la
planificacin 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.
Entre los recursos materiales deberemos de considerar, fundamentalmente En general el proyecto se puede gobernar cuando existe informacin
el entorno de desarrollo y el ordenador objetivo que, con sus particularidades compartida del mismo, de tal modo que todo el equipo, segn su
de sistema operativo y bases de datos, puede no tener la misma configuracin responsabilidad, tenga conocimiento de las tareas programadas y del estado de
que las herramientas del banco de trabajo" donde se desarrolla el sistema de las tareas realizadas, para lo cual son muy tiles los mtodos tcnicos que en
informacin. En otros casos se consideran recursos algunos elementos forma de normas y procedimientos, marcan la ruta a seguir en el avance del
hardware que se integrar dentro del proyecto pero que su disponibilidad, por mismo.
diversas causas, no es inmediata.
En los captulos ocho y diez volveremos sobre el uso de los recursos y la
Dentro de las posibilidades de utilizacin de algunos recursos que no estimacin de los costes con mtodos estadsticos; haremos estimacin de los
disponemos est la de alquilar horas de recurso material (normalmente costes en funcin del tipo de recurso, la cantidad de recursos, de la duracin de
hardware) en alguna instalacin similar a la de la organizacin cliente donde, la actividad, todo ello con tcnicas de estudio fijando los escenarios ms
de forma programada, se puedan probar los mdulos que se estn construyendo probables, ms pesimistas y ms optimistas. Todo ello, junto con el tratamiento
y donde se pueda verificar el avance del proyecto. de los costes directos: precio, cantidad, eficiencia, duracin de la tarea,
oportunidad del momento, etc.., nos llevar a la asignacin al proyecto.
Una importancia extraordinaria en la construccin de sistemas de
informacin modernos tienen las herramientas software con las que
construimos el nuevo sistema que, posiblemente, a lo largo de la fase de
construccin del sistema tengan que ser sustituidas por otras herramientas
futuras, lo que nos llevar a estimar esfuerzos de conversin y de formacin en
las nuevas versiones de software de base.
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 tendramos 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.
(
<
50 PL A N IFIC A C I N Y G ESTI N DE SISTEM A S INFORMTICOS
(
CAPTULO 4
FACTORES DE PRODUCTIVIDAD
(
52 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 F O R M A T IC O S 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 53
letra esta afirmacin de Lord Kelvin pero lia trado algunos desencantos que Frente a los objetivos del negocio podemos asegurar que la iniciacin de
han suscitado una gran polmica. programas de mtricas del software, proveer la asistencia de asegurar,
monitorizar e identificar acciones de mejora para alcanzar un conjunto de
Pero cuando tratamos de realizar un nuevo proyecto, normalmente objetivos de calidad y productividad de la compaa.
irrepetible, no valen de mucho los mtodos empricos sino ms bien el
conocimiento histrico. Preguntas del tipo Cmo se ha comportado mi equipo El programa de mtricas, a su vez, camina muy relacionado con el proceso
de desarrollo en anteriores proyectos? Los datos anteriores cmo pueden ser de desarrollo ya que las mtricas se definen para medir caractersticas
extrapolados ahora? cuantitativas de rendimiento en determinados puntos del proceso.
En la exposicin de la presente leccin se har una presentacin de las Es importante considerar que el proceso de implantacin de mtricas
distintas mtricas del software para entender en que puntos se ajustan mejor las deber ser realimentado de tal suerte que los datos obtenidos de la medida
medidas de productividad. Pero debemos de considerar las razones la medida provean una gua para mejorar la identificacin de acciones a mejorar en el
del software: El software se mide para: proceso de desarrollo de sistemas de informacin1.
propsito, su funcin en el marco de las actividades comerciales, su respaldo automaticen los trabajos de desarrollo y mantenimiento del software. Aunque
informtico y su relacin con otros iconos. El texto explicativo contiene de esta forma se facilita la implantacin de soluciones, su principal aportacin
informacin suficiente para deducir las caractersticas fundamentales del objeto se refiere a las mejoras en la productividad y calidad en todos los aspectos del
real representado por el icono. desarrollo, abarcando todas las fases del ciclo de vida, permitiendo la
aplicacin real de las tcnicas recomendadas por la metodologa utilizada; algo
Las metodologas de modelizacin permiten encauzar la elaboracin de que de forma manual sera muy difcil de llevarse a cabo debido a la gran
modelos representativos de las actividades empresariales y el desarrollo de cantidad de informacin, esquemas y documentacin que se debe generar.
sistemas. Sin embargo, los modelos comerciales exigen frecuentemente
modificaciones como resultado de la evolucin del negocio. Si los modelos se Se han desarrollado herramientas CASE que automatizan muchas de las
construyen a mano, esos cambios requieren considerables esfuerzos; en metodologa conocidas empleadas para el modelado. Esas herramientas aplican
consecuencia, los modelos trabajosamente elaborados a mano se vuelven muchos de los principios de la CASE desde el momento en que aportan
pronto obsoletos. Por otra parte, si se invierten grandes esfuerzos en la tcnicas de diagramas acompaadas de textos explicativos. Muchos sistemas
construccin de un modelo manual, se tiende a no invertir ms trabajo en todo CASE funcionan en ordenadores personales, requirindose un ratn para
lo que suponga modificarlo. La modelizacin representa simblicamente las manejar los de mayor orientacin grfica. Los mandatos se introducen
distintas facetas del negocio con vistas a su estudio y subsiguiente mejora, mediante mens o teclas de funcin estando reservada parte de la pantalla para
antes de comprometerse formalmente en la elaboracin del modelo. El cambio, introducir la especificacin oportuna de los modelos.
por tanto, es inherente al modelado, de ah que haya que facilitarlo al mximo.
Dentro de las metodologa ms grficas automatizadas a travs 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
4.3 LOS CASE. comercial en fase de modelado.
En la actualidad ya no se concibe el desarrollo de Sistemas de Informacin sin Estos textos explicativos se introducen en la parte del sistema CASE
utilizar herramientas de ayuda para automatizar gran parte de las tareas del conocida como "diccionario" (algunos sistema CASE poseen gestores de bases
ciclo de vida. Esto ha dado lugar al nacimiento de la Ingeniera del software de datos incorporados que realizan esta funcin). El diccionario contiene
Asistida por Ordenador o tecnologa C ASE (Computer Aided Software pantallas preformateadas asociadas a los distintos iconos, pantallas que
Engineering), que consiste en una combinacin de metodologa de desarrollo suministran una informacin muy valiosa acerca de los aspectos del negocio
de sistemas (UML, OMT, SSADM, METRICA,...) y herramientas orientadas a simbolizados por los iconos. El diccionario contiene adems un directorio que
facilitar dicho desarrollo basado en esas metodologas concretas (Rational muestra las relaciones existentes entre determinados diagramas, iconos y textos
Rose, Predict CASE, Excelerator, Designer 2000..). explicativos.
La tecnologa CASE utiliza el ordenador como herramienta tanto para el La mayora de las organizaciones se enfrentan a una crisis del software y
establecimiento de modelos descriptivos de las empresas que se van a tienen, generalmente, una gran cantidad de proyectos esperando a ser
automatizar como para documentar el desarrollo de los Sistemas Informticos desarrollados. Es necesario, por tanto, resolver este grave problema,
implicados, desde el momento de su planificacin hasta su implantacin final. obteniendo sistemas de mejor calidad y en menor tiempo.
En este sentido, dicha tecnologa permite resolver el conflicto existente entre el
dinamismo de la actividad empresarial y la dificultad que entraa el desarrollo Una importante parte del xito de la implantacin de la CASE es
de nuevos Sistemas Informticos que se adapten a tal dinamismo. determinar lo qu se debe hacer y cmo para resolver el problema planteado
dentro de la organizacin. Debido a que cada organizacin vive el problema
La tecnologa CASE reemplaza el papel y el lpiz por el ordenador para desde un punto de vista distinto, se deben determinar con detalle las
hacer del desarrollo del software un proceso ms productivo. El objetivo necesidades y las prioridades de la misma que se deben cubrir.
fundamental de la CASE es proporcionar un conjunto de herramientas que
56 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 F O R M T IC O S _________ C A P IT U L O 4 F A C T O R E S DI- P R O D U C T IV ID A D 57
Aproximacin en cascada. Tcnica rgida, su filosofa es completar un Aproximacin evolutiva. Similar a la de prototipos, intenta un sistema
paso con un alto grado de exactitud, antes de empezar el siguiente. flexible con una gran capacidad de expansin de tal forma que se van
Adecuado para el desarrollo de sistemas con especificaciones muy obteniendo versiones del prototipo cada vez ms parecidas al sistema
elaboradas desde el principio. Los proyectos raras veces siguen el final. El prototipo no se desecha, incluso los requisitos de fiabilidad y
modelo secuencial que se supone, pero si es aplicable a un proyecto, su rendimiento se implementan desde el principio. Mientras que en la
planificacin y su gestin son mucho ms fciles y no suele haber aproximacin por prototipos se asume que existe una serie de requisitos
desviaciones. En general presenta desventajas como: que no estn claros para disear el prototipo, esta aproximacin se
disea en base a los requisitos que estn claros y se pretende descubrir*
o La versin operativa de los programas no est disponible hasta los dems. Cada vez se desarrolla una nueva versin de todo el sistema.
que el proyecto est muy avanzado,
o No contempla iteraciones y paralelismos potenciales entre las Aproximacin incremental. Se comienza el desarrollo para satisfacer
fases. Algunos integrantes del equipo han de esperar a otros una parte de los requisitos especificados. Se van aadiendo mas
para completar tareas pendientes, requisitos en futuras versiones. Se logra una pronta disponibilidad
o Un error importante puede ser desastroso, si se descubre al final parcial del producto que, si bien es incompleto, puede ser utilizable y
del proceso. satisfacer algunas necesidades de informacin. Se desarrolla cada vez
o En muchas ocasiones no es posible disponer de unas un nuevo sistema sin modificar el anterior aadiendo nuevas funciones.
especificaciones correctas desde el primer momento, porque Tiene una desventaja importante: los errores en los requisitos (o errores
puede ser difcil para el usuario establecer al inicio todos los de anlisis), si aparecen tarde, son graves, es decir, son difciles de
requisitos. corregir.
58 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 F O R M T IC O S C A P T U L O 1: F A C T O R E S D E P R O D U C T IV ID A D 59
Aunque depende en gran medida de la envergadura, complejidad y deber ser independiente de aquel, de la misma organizacin, que
caractersticas del sistema a desarrollar, puede establecerse de forma general compone el equipo de desarrollo del sistema.
que en todo proyecto de desarrollo de un sistema estn implicados, por una
parte, personas pertenecientes a la organizacin usuaria o promotora del Equipo de Desarrollo: Est constituido por las personas que se van a
proyecto, la que utilizar el sistema cuando ste se construya y, por otra, la encargar directamente del desarrollo. Pertenecern a la organizacin
organizacin de desarrollo o empresa contratista a la que la primera encarga la contratada para desarrollar el sistema; aunque si se trata de un
realizacin de tal sistema. desarrollo interno, los miembros del equipo pertenecern a la propia
organizacin usuaria. Normalmente, si el desarrollo es externo
Puede ocurrir, no obstante, que se trate de un desarrollo interno de la (empresa contratista) y la organizacin usuaria dispone de
propia organizacin usuaria, a travs de su propio departamento de proceso de Departamento de Informtica, algunas personas de tal departamento
datos (o departamento de informtica). En tal caso, la organizacin de pueden considerarse tambin del equipo, participando, por tanto, en el
desarrollo se correspondera precisamente con este departamento. desarrollo.
Aunque no suele ser habitual su presencia en la mayora de los proyectos, Al frente del Equipo de Desarrollo se sita el Jefe del Proyecto,
puede determinarse por parte de ambas organizaciones (de usuario y de persona con amplios conocimientos informticos y experiencia en el
desarrollo), la contratacin de una tercera firma, especialista en auditoria desarrollo de este tipo de sistemas. El resto de personal implicados en el
informtica e independiente de ambas, que intervenga en aquellos casos en los desarrollo sern:
que se hayan previsto procedimientos extraordinarios de control (auditorias).
Analistas: Personal con conocimiento de la metodologa de desarrollo a
El personal perteneciente a las anteriores organizaciones que interviene en utilizar y de las herramientas que permiten automatizar este desarrollo.
un proyecto determinado es el siguiente: Se encarga del estudio de los requisitos, objetivos y funciones a realizar
por el sistema, documentando todos estos aspectos segn la
Comit de Direccin: Est constituido por los responsables de la metodologa establecida.
organizacin usuaria o promotora del proyecto y de la organizacin u
organizaciones encargadas de su desarrollo. Al frente de este comit se Diseadores: Suele tratarse del propio analista anterior. Se encarga de
encontrar el Director del Proyecto. establecer la estructura del software y de los datos que constituyen el
sistema.
Director del Proyecto: Se trata de un directivo de alto nivel, con
amplia experiencia en planificacin y gestin de Sistemas de Programadores: Codificarn, mediante un lenguaje de programacin
Informacin, nombrado por acuerdo entre las organizaciones concreto, los componentes software establecidos por los diseadores.
implicadas. Normalmente se trata un directivo de la organizacin
encargada del desarrollo del sistema. Tcnicos de Sistemas: Personal experto en software de base (sistemas
operativos, software de red,..) y equipos informticos, que ofrece apoyo
Comit de Garanta de Calidad: Est integrado por personal, con tcnico a lo largo del desarrollo.
conocimientos y experiencia en metodologas de desarrollo, del
departamento de informtica, si existe, de la organizacin usuaria o, en Personal del Area de Explotacin: Se trata de personas del
caso contrario, de una organizacin externa, independiente de la que departamento de informtica o proceso de datos de la organizacin
desarrolla el sistema. Este comit se encargar de controlar la evolucin usuaria, con conocimientos sobre el entorno en el que se explotar el
del proyecto a travs del anlisis de los productos generados a lo largo sistema cuando se instale. Estas personas colaborarn con el equipo de
de las diferentes fases de desarrollo. En el caso de pertenecer a la desarrollo, para concretar determinados aspectos relacionados
organizacin usuaria, el personal encargado de este control de calidad principalmente con la definicin del entorno tecnolgico del sistema
(equipos, software de base,..) y con la construccin de la base de datos
62 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 F O R M T IC O S
5.1 EL A N L ISIS PR EV IO Y EL C O N T R O L DE L A IN V ER SI N .
Parte importante de este tema es que el lector adquiera una visin clara de la situacin del
director de proyecto dentro de la empresa en la cual presta sus servicios. Deber aprender el
cmo y el por qu de efectuar presupuestos, controlar los gastos y preparar informacin estra
tgica 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 D B S IS T E M A S IN F O R M T I C O S 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
Estudios tcnicos sobre el estado del arte de la materia a proyectar Normalmente la inversin se realiza en trminos de capital entendido como
Estudios economtricos y comerciales sobre el universo en el que se un conjunto de derechos de propiedad que se pueden cambiar (invertir) por
implante, o comercialice, el producto a obtener otras propiedades: en nuestro caso se cambia dinero por un bien futuro que
Estudios financieros sobre la inversin necesaria, cadencia de pagos, puede ser, por ejemplo, un sistema de control de la produccin con el que se va
costes financieros y previsiones de venta. a obtener ms beneficios.
Estudios de recuperacin de la inversin y de rentabilidad.
En general se puede considerar que toda inversin en un determinado
Estudios sobre el efecto de no realizar el proyecto
proyecto viene dado por el trinomio formado por un desembolso inicial, un
rendimiento y una duracin.
Con los estudios anteriormente citados se procede a efectuar una
valoracin, o mejor an, un proceso de valoracin entendido como un
Formalicemos estos conceptos, y otros ms que nos servirn de apoyo,
proceso formal segn el cual se asignan unas magnitudes monetarias a
utilizando la notacin estndar3:
determinados procesos o hechos econmicos con objeto de hacerlos calculables
para un determinado fin. Es necesario que existan varias formas de datar el
Capital circulante: el que necesita todo negocio para afrontar su actividad
precio de un producto o de un servicio y si bien todos sabemos que el valor de
normal despus de realizar la inversin.
un bien depende de la necesidad humana que va a satisfacer podemos
establecer, bsicamente, dos mtodos a la hora de establecer el precio. De una
V alor residual: Valor del producto cuando se decide liquidarlo.
parte se puede utilizar un criterio que sea consecuente con los procesos de
pagos y cobros, considerando ciertas implicaciones con algunas funciones de
Periodos a contem plar (/;): Es el nmero de periodos que vamos a
los sistemas de escasez o de boyanta, a este sistema se les reconoce con los
contemplar desde que se efecta la primer inversin hasta que el producto deja
criterios pagatorios, como decimos, basados en una corriente real de pagos y
de ser un bien til o cuando de decide liquidarlo a cambio de cierto valor
cobros, es decir, estudiando el coste real del bien.
residual. Suele coincidir con los periodos durante los cuales el proyecto genera
flujos de caja.
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
V alor Esperado M onetario (VEM) Es el sumatorio de la renta que se
que se establece un mercado en el que se equilibre la oferta y la demanda,
espera obtener en cada alternativa4 multiplicada por la probabilidad de que esa
puede funcionar con un cierto nivel inflaccionista2.
renta se produzca.
Ya hemos utilizado una serie de conceptos que, si bien no han sido
rigurosamente definidos, de alguna forma estamos familiarizados con ellos: VEM = p r o b a b i l i d a d J x rentaesperada
Memos hablado de inversin y siempre que utilizamos este trmino nos
referimos a un cierto desembolso inicial que, normalmente, es econmico.
Siempre que se realiza una inversin esperamos un cierto rendimiento Rentabilidad prevista (RP): Es el cociente entre la diferencia del Valor
conocido como rentabilidad en un cierto tiempo. Pero cuando invertimos en un Esperado Monetario menos el Coste de la Inversin dividido por el Coste de la
determinado bien, por la naturaleza finita del dinero, renunciamos, de forma Inversin:
implcita, 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 ms framente posible. 3 Gotlieb utiliza estos conceptos en su obra "Economics o f Computers, The Cost, Benefits,
Policies and Strategies", Prenlice-Hall, 1985.
4 En muchos libros de texto considera periodos como forma de simplificacin de las alternati
2 Vcase el libro Direccin de Proyectos Informticos: Una gua prctica del Jefe de Proyecto; vas, nuestra consideracin es que se deben de considerar distintas alternativas como una gene
dePlam Thu Quang y Jean-Jacques Gonim. Gestin 2000, 1994. ralizacin de los periodos considerados por otros autores.
66 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 5: ASPECTOS GERENCIALOS 67
Rr VEM-CI Para calcular el Valor Esperado Monetario ( VEM) de cada proyecto aplicaramos la
f rm u la y diramos:
CI
VEM(l) = 72 x 0,2 + 80 x 0,7 + 93 x 0,1 = 79,7 (
3.- Crear un sistema de gestin de cobros que permita flexibilizar las entregas gracias a un i
control puntual de la bondad financiera " de los clientes. Esto se puede realizar con una
inversin de 52 millones de pesetas y, como contrapartida, se obtendran unos beneficios,
incluyendo la menor cantidad de efectos que hasta el momento resultaban ser impagados, de
83 millones de pesetas. RP( 3) = 8 0 ,8 ~ 52 = 0,55
52
La direccin cree que las previsiones se han realizado basadas en unas hiptesis de estimacin
de probabilidad 0,7, pero cree posible que, debido a coyunturas econmicas adversas, podra O bservam os, que desde el p u n to de vista de rentabilidad el proyecto m s interesante
darse el caso desfavorable de que esto no suceda as (con una probabilidad de 0,2) de tal <
es el segundo de ellos.
form a que sus resultados comerciales fueses de 72, 45 y 57 millones de pesetas
respectivamente en cada proyecto. Igualmente, y por eliminacin, cree que el escenario podra
ser m uy favorable, con probabilidad 0. i, y los resultados respectivos de las tres opciones (
podran ser de 93, 87 v 113 millones de pesetas. En cualqttier caso cree que los costes de
implementacin siempre se mantendran fijos sea cualfuese el escenario. En el caso de haber considerado que los costes de producir el bien tambin
tuvieran un valor concreto en cada escenario de probabilidad tendramos que ^
Estimar, en base a la informacin facilitada qu proyecto es el ms aconsejable segn el valor
obtener un valor resultante del coste del proyecto efectuando su media
esperado monetario y la rentabilidad prevista.
ponderada.
Construiramos, con la ayuda de una hoja de clculo, una tabla con los datos aportados por el
proyecto Continuamos definiendo otros trminos de importancia en el control de
proyectos como puede ser el periodo de recuperacin de la inversin; aspecto
Hiptesis baja Hiptesis media Hiptesis aita importante para poder abordar un nuevo proyecto, para lo cual nos apoyaremos
Probabilidad Probabilidad Probabilidad en un segundo supuesto.
0,2 0,7 0,1 Coste
Portal de ventas 72 80 93 47
Ayuda distribucin 45 70 87 35 Supuesto prctico 5.2: La compaa descrita en el supuesto prctico 5.1
decide ampliar su estudio y saber cual es el tiempo de retorno de su inversin
Gestion de Cobros 57 83 113 52
como un nuevo parmetro para la toma de su decisin de qu tipo de proyecto
acometer con prioridad uno. Para ello indica que la inversin en cada uno de
los tres proyectos la realizar al principio del periodo (podran 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 C A P T U L O 5: A S P E C T O S G E R I-N C 1 A L E S 69
O btendram os que, para el prim er proyecto, el tiempo de retorno sera del Cuando entra en juego la lasa de inflacin, el PB se obtiene en el momento
cociente de dividir la inversin entre el flu jo de tesorera p o r se r constante, es en el que se iguala la siguiente expresin:
decir:
f PT, =f 1,
PR(1) = 4 7 / 1 0 = 4 , 7 p o r lo tanto se recupera en el quinto ao de 7{\ + r ) h { \ +r)
explotacin.
siendo /, el valor de la inversin que se efecta en el periodo t5.
PR(2) = 3 5 / 7 5
Normalmente la restriccin del proyecto viene impuesta por una condicin
En el tercer caso se recupera en el ao sexto y a que ese ao el importe de
del tipo que el P B sea menor de x aos.
la inversin, que eran 52 millones, est horquillado entre una flu jo de
tesorera del quinto ao que no llega a cubrir los costes y un sexto ao en que
El PB se suele considerar de una nica inversin inicial y, en este caso, el
se supera la inversin. PB se obtiene de la frmula:
Q = 2 + 4 + 7 + 1 2+ 1 5 = 40 y PB JP 'T
y =i
Qi+, = 2 + 4 + 7 + 1 2 + 1 5 + 14 = 54 /=o (1 + r)
Con la inform acin obtenida hasta el m om ento podem os decir que los Si hubiera distintas inversiones anuales hasta el ao N , el PB sera mayor de
p rim ero s proyecto s son ms interesantes, fre n te al periodo de recuperacin, N y se calculara como:
que e l tercero.
PB f T 'T N T
Flujos de Tesorera (FT)\ Son las entradas y salidas de caja en cada (I + m ) = (I + 0 (1 + 7 7 ? /,)
periodo, as FT es el flujo de caja del periodo n.
Valor Actual Neto ( VAN) de una inversin: representa el valor monetario Dentro de la documentacin que se suele acompaar al lanzamiento del
neto en un momento dado. Se calcula como la diferencia entre los flujos de proyecto es interesante conocer los conceptos de Perfil y de Portafolio.
tesorera actualizada a la tasa de inters prefijado y las inversiones actualizadas
a esa misma fecha. As un VAN positivo indica que la inversin en el proyecto Perfil: Es un estudio en el que se valoran todos los elementos que forman
es rentable o, al menos, es mejor que la tasa de referencia. parte de un proceso (componentes/elementos): calidad, precio, competencia,
coste, producto, diferenciacin, tiempo, etc... Con estos datos se establece una
Se calcula mediante la frmula: escala mtrica y en cada componente se asigna un valor con lo que
obtendremos el perfil del proceso.
Fe i,-'/- p ii i
Frente al personal del equipo del proyecto hubo xito si se han satisfecho Si no existe presupuesto se hace difcil la gestin del proyecto.
sus necesidades personal, en concreto si: Si hay presupuesto pero la gestin es mala, tarde o temprano los
resultados sern malos.
Hubo comunicacin con los usuarios Los costes de un sistema informtico son cada vez ms altos.
Las especificaciones fueron revisadas y aprobadas Las reas usuarias (o clientes) deben de soportar los costes.
Se evaluaron los cambios
La direccin estuvo continuamente implicada La gestin debe iniciarse con una buena eleccin del presupuesto, y los
gastos e inversiones deben de justificarse en relacin con el "negocio". El
Aument nuestra experiencia y confianza
presupuesto debe abarcar todas las partidas para tener controlado todo el
Proyecto Informtico para saber puntualmente lo que estamos gastando
globalmente en los distintos conceptos.
Frente a los que operan el sistema, o en casos de proyectos subcontratados,
frente a los que tendrn responsabilidad en el mantenimiento del mismo:
Respecto a la filosofa de como se deben de realizar los presupuestos se
debe decir que no hay un mtodo nico, que se defienden varias teoras y que
Est bien documentado
se pueden combinar as, por ejemplo, se puede:
Es fcil de operar
Fue bien probado y no tiene sorpresas. Partir de unas directrices (Top-down), basadas en porcentajes sobre
Tiene una excelente capacidad de recuperacin y, ante posibles cadas proyectos similares ms recientes.
del sistema, permite un rpido rearranque.
Elaborar un borrador segn determinados criterios (Bottom-up
condicionado) justificando lo que exceda un determinado porcentaje de
En general, como lneas maestras, toda la organizacin piensa que la las directrices.
realizacin 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
Entre las partidas ms importantes a incluir en el presupuesto, cabe
producto de calidad que satisface a los usuarios. destacar:
Instalaciones:
o Alquileres,
5.4 LA INFORMACIN COMO ACTIVO ESTRATGICO
o Gastos.
o Consumos (agua, electricidad,...)
El acceso a la informacin, en las empresas de hoy da, es una de las tareas ms
o Mobiliario
difciles de los directivos en sus diarios procesos de toma de decisiones. Hoy
da no es posible esperar de un empresario, que ya de por s necesita tener un
Suministros (papel, soportes magnticos, cintas entintadas,...) y
gran conocimiento sobre el funcionamiento de la empresa, del posicionamiento
servicios contratados:
de sus competidores frente a un mercado altamente cambiante, de la
o Consultores,
informacin que poseen sus tcnicos, de los gustos de sus clientes,.... Esto nos
o Auditores.
condice a que, para que algunas empresas puedan sobrevivir, necesitan
o Administracin de Seguridad Informtica,
incorporar lo que, en trminos generales, se conoce como las nuevas
o Tcnicos de desarrollo,
tecnologas de la informacin. Y esto por qu? Porque, hoy ms que nunca, la
o Entrada de datos,
informacin es un valor para la empresa, es un activo de prim er orden que
o Transportistas, mensajeros.
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
Oficinas de servicios.
competencia. En este sentido hacemos nfasis en el activo estratgico que
supone, no el hecho de tener mucha informacin, sino el poder utilizarla, de la
Impuestos. forma ms eficientemente posible, para que sea un verdadero conocimiento que
sirva como factor productivo de explotacin.
Seguros.
En este sentido podemos afirmar que una buena gestin en la informacin
Intereses (si hay partidas que financiar). que soporta una empresa a nivel globalizado, que pone la informacin en el
punto y en el momento en que sea preciso consultarla, que perm ite obtener un
mayor rendimiento en sus empleados al disponer de esa informacin puntual al
6 Grupp, B., "La cuestin del departamento de informtica". Hispano Europea, 1985.
76 P L A N IF IC A C I N Y G E S T I N DF. S IS T E M A S IN F O R M T IC O S _________________________ C A P T U L O 5. A S PE C T O S G E R F -N C IA L E S 77
momento, es un activo extraordinariamente importante como para que los dentro de la Direccin de Proyectos, su funcionamiento debe de ser como si el
directivos la consideren como una de las responsabilidades de primer orden. Es "Proyecto" fuera una unidad diferente y, si fuera necesario, se creara un centro
tal la importancia de este tipo de activo que el empresario o el director no de coste para la gestin en s.
podr delegar este tipo de tareas en ningn caso. Es ms, existen sectores de
actividad, como pueden ser las empresas dedicadas a los sectores tursticos o Una consecuencia beneficiosa de la repercusin de costes es la necesidad
de seguros, donde el verdadero factor productivo es la buena gestin de sus de dar buen servicio8 ya que un usuario que no obtiene un nivel de respuesta
sistemas de informacin y en los que la inversin en este tipo de activos tendr aceptable, un servicio pobre, o cuyas peticiones no se tengan en cuenta,
una influencia directamente relacionada con sus resultados de explotacin. protestar ante unos cargos que pueden considerar injustificados o excesivos
introduciendo nuevamente unos factores de productividad que ejercern
nuevamente una dinmica hacia el cambio correctivo y, finalmente, hacia la
mejora en el servicio.
5.5 N E C E SID A D DE E L A B O R A R P R O Y E C T O S PA R A
A D E C U A R L O S SIST E M A S DE IN F O R M A C I N A L A S TO M A S
DE D E C IS IO N E S EN UN M E R C A D O C A M B IA N T E
CAPTULO 6
Por otra parte, el software interacciona con otros elementos del sistema
informtico. El planificador debe de considerar la naturaleza y la complejidad
de cada interfaz para determinar cualquier efecto en los recursos, costes y
mtodos de desarrollo. La descripcin de los interfases, considerados como
hardware, software y personas que lo utilizan, deben de estar perfectamente
documentados.
En un principio el proyecto ha nacido como una idea que trata de obtener un mbito
bien futuro y que, de alguna forma, ha sido presentado a la alta direccin para Factibilidad tcnica
solicitar su posible aprobacin pero que an se mantiene en la fase de lo que Los recursos a emplear
podramos denominar fase conceptual. Los ejemplos que podramos citar de Las responsabilidades de cada participante
proyectos que no pasan de esta etapa son numerosos; los tcnicos que se han Las Directrices generales de la compaa
afanado en el proyecto, y no ven continuidad a algo que para ellos parece Los factores de productividad
trivial, les posiciona en un punto de incomodidad que debe de entenderse como Los criterios de terminacin
las posibles dudas que actan en la mente del empresario o del cliente que tiene
que financiar la operacin y que, sin lugar a duda, estar forzado a correr un Con el anlisis de cada uno de los puntos anteriores se debe de llegar a
cierto riesgo. tener dispuesto el documento listo para la firma en el cual se deben de haber
despejado las incgnitas que hacen que el proyecto sea creble y dnde se
Es esta la mejor solucin al problema?Es el momento adecuado? Para pueda evaluar claramente el riesgo que se correr con el proyecto en cuestin
poder despejar este tipo de dudas ser necesario obtener ms conocimiento en cado de seguir adelante y en el caso de no seguir.
sobre el proyecto en s: Ser necesario efectuar una definicin formal de las
necesidades de la organizacin para poder estudiar el mejor proyecto de una En cada una de las fases o reuniones que se hayan ido produciendo hasta
posible gama de soluciones. afinar el documento de objetivos, el director del proyecto habr ido
actualizando la lista de control del riesgo y el plan de actuacin a la vez que ir
Para poder llevar este estudio por vas controladas efectuaremos un primer eliminando la lista de control de revisin de objetivos.
anlisis sobre el estudio del problema a detalle para lo cual comenzaremos por
describir una serie de necesidades identificadas que quedarn documentadas en El documento de objetivos deber tener una lista de objetivos de proyecto
un informe que todos los miembros implicados conocern, discutirn y claros. Estos objetivos son muy importantes porque, como hemos visto en el
manejarn como punto de partida para nuevos avances del proyecto. captulo 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
Como decamos anteriormente del estudio del informe de necesidades puede medir sin lugar a confusin que beneficiara al director de proyecto poco
identificadas se pasar a ensayar un borrador de objetivos del proyecto que eficiente que tratar de buscar excusas para justificar su ineptitud. Por lo tanto
mediante una serie de reuniones peridicas en las que se busque la solucin se debern evitar objetivos con doble interpretacin o con interpretacin muy
ms adecuada y en la que cada parte establecer sus necesidades se intentar generalista del tipo se podr consultar la informacin con agregacin de
llegar a un informe de objetivos que nuevamente ser cuestionado, atendiendo cualquier dato de la compaa. En este sentido debemos considerar que los
en especial a las recomendaciones tcnicas y al posible plan de implantacin objetivos deben de ser:
definido por la direccin de la empresa hasta conseguir un documento de
objetivos terminado que servir, a su vez de revisin, hasta conseguir su total Cuantificables, lo que conlleva que sean controlables.
aprobacin por las partes implicadas. Realistas, alcanzables.
Omnipresentes a lo largo del proyecto: tienen que constituir las lneas
En la fase de revisin del documento de objetivos, el director del proyecto,
maestras de referencia.
ir creando una lista de puntos de control de las reuniones sucesivas: En
Jerarquizables entre s.
especial mantendr registros vivos, de una reunin a otra, de los puntos que
Deberan de ser, en medida de lo posible, independientes del entorno.
puedan suponer un riesgo especial del proyecto e ir perfilando un posible plan
de actuacin que continuamente se ir perfilando hasta conseguir una Permanentes mientras no se decida el cambio, es decir, no son
definicin lo suficientemente clara como para iniciar otra fase del proyecto. En modificables sin una justificacin slida.
82 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 F O R M T IC O S C A P T U L O 6: D E F IN IC I N D E L P R O B L E M A Y ESTR A T E G IA S D E S O L U C I N 83
6.3 LOS REQUERIM IENTOS DE LOS INTERESADOS. Se facilitarn instrucciones de la forma de presentacin de las ofertas
buscando una uniformidad para que podamos deducir las capacidades
Para que los objetivos resulten eficaces, es importante que todos los de cada contratista.
participantes del proyecto estn oficialmente de acuerdo con ellos. A menudo, Se incorporar la lista de requisitos as como los condicionantes
el administrador del proyecto crea un documento de objetivos que se convierte detectados en la fase de decisin de realizar el proyecto.
en una parte permanente del proyecto. Se pueden pedir pruebas y cruces de datos para asegurarnos de la
veracidad de la informacin aportada por los contratistas.
Pero es muy importante a la hora de la realizacin del proyecto saber si se
va a contratar total o parcialmente porque determinar unos criterios que en
algunos casos debern imponerse, como pueden ser aspectos metodolgicos de
auditoria y control o la importancia de los riesgos por posibles indefiniciones 6.4 BSQUEDA DE UNA ESTRATEGIA DE SOLUCIN Y SU
de los objetivos o productos que alterarn directamente la cuenta de DESARROLLO.
explotacin del propio producto. Igualmente es importante saber si se va a
aplicar al proyecto un equipo de control y en caso afirmativo tendremos que Para llevar a buen trmino los directores de proyectos tratan de cumplir los
conocer la intensidad del mismo. En este sentido tendremos que considerar la objetivos generales acordados con sus "clientes, en general tratar de obtener
dedicacin a la direccin de un proyecto o las direcciones parciales o el producto deseado, dentro de un plazo de ejecucin pactado y dentro de los
compartidas de proyectos con la problemtica que acompaa a estas costos establecidos. El objetivo quedar definido como una funcin de estos
situaciones. tres aspectos:
de crisis en el desarrollo del proyecto. En este apartado se incluyen todo tipo de Para tratar de efectuar la oferta, la empresa contratista deber fijar una
esfuerzos que se han de dedicar para desarrollar el producto, la documentacin persona responsable de prepara la oferta que ser la encargada de estudiar los
tcnica asociada, las exigencias de calidad impuestas y, si as se ha pactado, la grados de libertad del cliente expresados en el Pliego de Condiciones. As
puesta en marcha o arranque inicial del sistema. mismo descompondr el Pliego en hitos, fases y tareas (lo que compone en s el
anlisis de la oferta). En algunos casos deber negociar la asignacin de las
Es importante entender que, al ser el objetivo funcin de estas tres fases a las distintas reas de la empresa para que estimen el trabajo que debern
variables, cualquier cambio en los objetivos se ver afectado por, al menos, una realizar y ofrecer datos de valoracin de cada fase y valorar econmicamente
de las variables que logran el vector resultante. Y si se quiere modificar alguna las tareas de integracin de las fases considerando los esfuerzos de
de las variables para lograr el proyecto en alguna cuota, esto se producir a coordinacin. Con este estudio tendr que obtener el precio del coste del
base de modificar alguna de las otras variables. producto y de los plazos de realizacin remitiendo al demandante los puntos no
incluidos.
En el caso de que el concurso sea presentado por las administraciones Penalizaciones por incumplimiento de las fechas lmites (menos
pblicas y que nos interese concursar tendremos que presentar una serie de frecuente los premios por terminar antes de una fecha prevista)
documentos que legalmente se demanden generalmente segn marca la Ley de Frmulas para solucionar cualquier tipo de incidencia dentro de los
Contratos del Estado. Los documentos que normalmente se demandan para plazos establecidos por causa ajena a proveedor o contratista o frmulas
presentarse a concursar son los siguientes: de arbitrio en caso de litigio entre las partes antes de acudir a los
tribunales si no figura en el Pliego de Condiciones.
Carta de acompaamiento de la oferta firmada por alguna persona
responsable (poder notarial, bastanteo, etc.). En un tercer sobre se presentan los documentos de tipo econmico, entre
Justificante de existencia de la Sociedad y de que puede realizar la los que se encuentran:
actividad demandada.
Compromiso de adherirse a lo indicado en la oferta en concreto suele Alcance global de la oferta
exigirse un compromiso firmado de mantener secreto de la tecnologa Descomposicin en precios unitarios por si se emplean mayor magnitud
que se ceda, del estado de la tecnologa, etc. de cifras poder regularizar segn un patrn establecido.
Justificantes de estar al corriente de determinados impuestos y tasas Calendario de finalizaciones parciales y de cobros.
cuando el contratante es la Administracin.
Aval que garantice que el ofertante no se retirar en caso de ganar la Una vez terminado el plazo de presentacin se procede a la fase de
oferta hasta formar el contrato que se suele elevar al doble en ese evaluacin de las ofertas en donde se realizar, primeramente, una
momento para garantizar que termina la obra. comprobacin de que cada ofertante cumple los requisitos legales para poder
En algunos casos se exige compromiso de no poder ofrecer trabajo a ser contratados. A continuacin se cede la documentacin tcnica a los
personas de la empresa propietaria del contrato durante cierto tiempo evaluadores para que analicen las posibilidades de cada una de las empresas,
(esta opcin a veces es recproca). estudiando su estructura, su potencia y su organizacin. Igualmente se
Domicilio legal.... efectuar un anlisis de la calidad que se estime van a cumplir cada una de las
empresas ofertantes efectundose una valoracin del riesgo que se corre por
Normalmente, en sobre aparte si se trata de la administracin pblica, se elegir una empresa u otra en funcin de una de una mtrica establecida basada
presentan los documentos de tipo tcnico del concurso entre los que se suelen en factores y pesos para clasificar las ofertas segn una determinada
incluir: valoracin. Tambin se valorarn, siguiendo la misma regla, los aspectos
tcnicos a establecindose el detalle de cada uno de los puntos de valoracin.
Datos econmicos de la compaa y currculum de las personas que van -4
a participar en el proyecto Finalmente se elabora un informe de valoracin donde quede muy claro los
Descripcin de realizaciones similares efectuadas anteriormente criterios tomados y en el que se propone un orden de adjudicacin,
indicando compaa y fecha. normalmente con una puntuacin ponderada, y una lista de empresas excluidas
Alcance de la prestacin de servicios indicando los criterios para la con su justificacin.
finalizacin del trabajo as como la documentacin final
Declaracin de conformidad con el pliego de prescripciones tcnicas de Ser, finalmente, la direccin de la empresa u organismo o una comisin
formada por la misma, la que, bajo un posible nombre como Mesa de
contrato, o, en su caso, las alegaciones que se consideren convenientes.
Contratacin estudiar los aspectos tcnicos mostrados en el informe de
Planificacin del trabajo y garanta de calidad, as como las medidas de
valoracin anterior que junto al precio del producto o servicio de cada empresa
control que estima prudentes.
les servir de base para la posible adjudicacin.
Justificacin de tener recursos suficientes para poder aplicar en el caso
de que sean necesarios.
En algunos casos, ms en la empresa privada que en la pblica, se
Justificantes de estar registrados, como empresa, en alguna
comienza una fase de negociacin de la oferta que se suele delegar a personas
organizacin de calidad.
del sector comercial con plenos poderes, grandes cualidades de la venta y
90 P L A N IF IC A C I N V G E S T I N D E S IS T E M A S IN F O R M T IC O S C A P TU LO 6: D E F IN IC I N D E L P R O B L E M A Y E S T R A T E G IA S D E S O L U C I N 91
conocedores de tcnicas de cierre de ofertas. Adems, es importante, que La definicin de interlocutores nicos tanto por parte de los contratistas
conozcan la importancia estratgica de la empresa en el contrato a obtener, los como de los proveedores.
criterios de evaluacin y la situacin de los competidores frente al contrato en El establecimiento por ambas partes de una organizacin adecuada con
curso personal suficiente para realizar el proyecto.
La existencia de unos contratos claros en los que se fijen las
En caso de resultar exitosa la oferta, o en caso de que la alta direccin obligaciones de todas las empresas presentes en el Proyecto.
decida la realizacin del proyecto, se celebrar una reunin de lanzamiento del
proyecto que sirve para establecer las ideas generales respecto a los objetivos a En cuanto al momento de la entrega se puede considerar la entrega con un
alcanzar, los requisitos contractuales en configuracin, calidad, plazos y costos, protocolo provisional en el que el proyecto se acepta casi finalizado a falta de
es estudio de la organizacin existente as como de los recursos con los que se subsanar algunos detalles a satisfacer en un tiempo prudencial o un protocolo
cuenta. En esta misma reunin se puede prefijar el director del proyecto y los definitivo que se limita a dejar constancia de que la lista anterior ha sido
puntos de inspeccin a realizar quedando todo debidamente soportado por una finalizada a satisfaccin. En ambos casos se fija la entrega del producto que a
documentacin apropiada. su vez puede ser parcial o total, o con un sistema de datos funcionando, lo que
supone que se efecte en caliente o en fro, es decir, sin carga de datos.
En esta reunin de lanzamiento o en otra inmediata posterior, se Igualmente es necesario considerar en el arranque la seguridad lo que nos har
considerar la existencia de unos contratos claros en los que se fijen las considerar nuevamente que se han cumplido las especificaciones del proyecto
obligaciones de todas las empresas presentes en el Proyecto, el establecimiento y, de forma particularmente importante, se estudiar el hecho de no influir en la
de interlocutores nicos, tanto por parte de los contratistas como de los produccin en curso. Es necesario, ya que a lo largo del tiempo ha supuesto
proveedores, junto con el compromiso de establecer, por ambas partes, una mucho dao a la industria informtica, no aceptar la finalizacin del proyecto
organizacin adecuada con personal suficiente para realizar el proyecto y los mientras no se tengan los manuales o normas de funcionamiento.
protocolos de recepcin del producto el da que se finalice.
En algunas situaciones, en el proceso de arranque, ser necesario estudiar la
A partir de la reunin de lanzamiento entramos en la fase de construccin. posibilidad de recurrir a grupos de apoyo para que puedan ayudar en las fases
Es fundamental en esta fase aplicar lo proyectado por el departamento de iniciales de la explotacin del proyecto ya que, es muy posible que se necesiten
ingeniera y no modificar nada que no sea accidental, y de hacerlo, consultar trabajos de formacin o entrenamiento del personal que se ocupar de la
con ingeniera, respetando el equilibrio entre coste, tiempo y calidad. La ejecucin del proyecto. La formacin se podr realizar bien en instalaciones
incidencia econmica debida a los cambios en esta fase es muy importante y similares, con soporte de hipermedia, con simuladores o simplemente siendo
podemos reflejarla en el siguiente grfico: conducidos por otro personal experto en la propia instalacin donde los
operadores estn vigilados por el personal ajeno hasta que demuestren un
dominio de las tcnicas empleadas en el nuevo proyecto.
CAPTULO 7
7.1 ESTRATEGIA DE LA EMPRESA Y SISTEM AS DE los flujos y registros de informacin necesarios para llevar a cabo las funciones
INFORMACIN de cada empresa en consecuencia a sus propias estrategias de negocio.
La estrategia de la empresa y los sistemas de informacin nacen como Cada empresa puede tener sus propias estrategias de negocio, es decir, sus
consecuencia de una simbiosis de ambos procesos. La empresa recibe pedidos propias formas de hacer negocio que le servir para diferenciarse de las
de sus clientes, lo que puede suponer un comienzo de un sistema de dems y as obtener su margen de explotacin. En algunos casos la estrategia
informacin, estos documentos son procesados para satisfacer dichos pedidos de negocio puede ser asegurar los cobros de los clientes al mximo posible,
convirtiendo un documento en otro, en el caso actual en un albarn de entrega, otra estrategia puede ser tener ajustadas las existencias de almacn al mnimo
mas la entrega fsica del producto. La estrategia de la empresa, a nivel necesario aunque en algunos casos no pueda suministrar productos de forma
esquemtico, puede ser la consecucin de sus beneficios debidos a satisfacer inmediata, en otros casos todo lo contrario. Lo que si es claro es que la
pedidos de clientes pero, entre tanto, se deben de comprobar una serie de mecanizacin de los sistemas de informacin mediante las tecnologas actuales
estados dentro de la empresa. Es decir, la estrategia de la empresa y la situacin es una fuente de proyectos que se debe considerar como de alta necesidad.
fsica puntual de la misma obligar a que mediante un cierto sistema de
informacin se comprueben, por ejemplo, al menos dos situaciones: Si el
cliente tiene crdito y si tenemos disponibilidad de producto en nuestro
almacn. 7.2 ESTUDIO DE LA CONVENIENCIA Y VIABILIDAD.
Para saber si el cliente tiene crdito tendremos que saber si ha pagado los Sin embargo, no todo sistema de informacin deber ser realizado con las
compromisos anteriores, lo que supone tener que acceder a documentos tecnologas de la informacin modernas. Ser necesario en cada caso buscar la
contables en los que analizar dicha situacin. Este proceso se puede realizar de mxima eficiencia y considerar que en algunos casos ser ms rentable utilizar
forma manual o de forma automtica y, en el segundo de los casos, este medios manuales que medios automticos, sobre todo si estos medios no se van
proceso puede ser mucho ms eficiente si los pedidos de los clientes son muy a utilizar muchas veces, o, en otras palabras, si no va a producir una reduccin
numerosos lo que supondr que la estrategia de la empresa frente al riesgo de posterior en los costos que justifique la inversin del nuevo proyecto.
cobros de clientes exigir un sistema de informacin concreto soportado por las
tecnologas de la informacin. La justificacin de la viabilidad en utilizar tecnologas de la informacin
en aquellos casos en los que es difcil la justificacin puramente contable se
En cuanto a la disponibilidad de stock podra suceder muchas cosas: la suele dar desde el punto de vista del control y del proceso de toma de las
empresa tiene stock suficiente para poder servir el pedido con lo que se deber decisiones. En este sentido se debe considerar el coste del no control o de no
rebajas el stock contable en las cantidades de producto pedido para mantener la poder utilizar las TIs para obtener exactitud en los importes econmicos
igualdad entre el stock fsico y el stock contable. Si, como consecuencia de la globales de la empresa y, en particular, de la cadena de valor creada.
entrega de un pedido, se rebaja una cantidad establecida como stock de
seguridad se deber de iniciar otro proceso de compra de nuevos productos El margen de explotacin de las empresas viene dado por la correcta
para satisfacer la demanda de los clientes, se debern informar, al menos, de las utilizacin de los recursos utilizados para llevar a cabo sus labores propias y de
condiciones de entrega y de pago, y se le deber asignar una ubicacin en el los que debemos considerar dos tipos fundamentales de actividades: Las de
almacn. Si no existe producto suficiente se deber decidir si se retiene el lnea que son las que tienen relacin directa con la creacin de la cadena de
pedido hasta una posible fecha de acopio o, en algunos casos, hasta saber la valor, como pueden ser los procesos de fabricacin o prestacin de servicios, y
fecha de aprovisionamiento en funcin de la disponibilidad frente a otros las de soporte que son las tareas en las que se apoyan las anteriores para
pedidos de otros clientes que solicitaron el producto con anterioridad. compartir informacin, coordinarse y no tener que crear estructuras paralelas
para cada tipo de negocio.
Al final, esperamos que estas simples transacciones nos sirvan para
comprender como los sistemas de informacin son los encargados de coordinar Las actividades de soporte se denominan infraestructura de la empresa y,
como consecuencia del punto anterior, todas las actividades de lnea necesitan
96 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 F O R M T IC O S C A P T U L O 7: F A SE S DE U N P R O Y E C T O 97
de una infraestructura que d soporte a informacin distribuida y a funciones - Construccin por fases: De todo el sistema a desarrollar se obtendrn
de apoyo. El problema para justificar esta infraestructura, que realmente son una serie de hitos con sus prioridades y prerrequisitos concretos que, con la
los sistemas de informacin, es saber que dimensin se la debe de asignar para ayuda de un planificador de proyectos, se optimizarn para reducir el tiempo de
cumplir las estrategias de negocio de forma eficiente; es decir, obteniendo el desarrollo y el coste logrndose una planificacin previa que sucesivamente se
mximo de resultados con el menor coste posible1. ir refmando en funcin del cumplimiento de los puntos de control que el
director del proyecto establezca.
Este binomio se puede trasladar al estudio de la conveniencia y la
viabilidad de la utilizacin de las tecnologas de la informacin para dar Control de cambios: Es inevitable, por muchos controles que se hayan
soporte a algn proceso de negocio: Es conveniente realizarlo? Se puede incorporado, que surjan cambios en la planificacin o, incluso, en las funciones
realizar? Existe alguna alternativa que pueda resultar ms eficiente? Al fin y a desarrollar. Estos cambios pueden alterar considerablemente el proyecto por
al cabo son preguntas que tendremos que formularnos en cada una de las pequeos que parezcan, por ello, es necesario tener un buen control de los
posibles mecanizaciones cambios y efectuar una revisin de la planificacin cada vez que surja alguno.
( www.iso.ch). Ha sido traducido en Espaa y es norma UNE de AENOR 7.5 ACTIVIDADES DE DESARROLLO, SEGUIMIENTO Y
(www.acnor.es). Este estndar define 17 procesos agrupados en tres categoras: CONTROL
principales, organizacionales y de apoyo.
Dentro de las actividades propias de la fase de desarrollo, podemos distinguir
Los estndares de procesos no establecen el orden y la relacin entre (siguiendo la ISO 12. 207) los siguientes procesos:
procesos ni las tcnicas ni mtodos para llevarlos a cabo. Aqu entran las
denominadas metodologas de ingeniera del software o de desarrollo del Proceso de adquisicin, que consiste en realizar las actividades de la
software. En la fase de definicin de cualquier proyecto software hay que organizacin que adquiere un sistema o producto software, que
establecer y difundir la metodologa a utilizar. Estas metodologas son un incluye la peticin de propuestas y el seguimiento del suministro.
conjunto integrado de tcnicas y mtodos que permiten obtener de forma
homognea y abierta cada una de las actividades del ciclo de vida del software. Proceso de suministro, en el que se realizan las actividades de la
La metodologa establece: organizacin que proporciona un sistema o producto software, como
definir requisitos y comunicacin con el cliente y facilitar la entrega
como dividir el proyecto en etapas, del producto.
que trabajos se llevan a cabo en cada etapa,
que productos se salida se producen en cada etapa, Proceso de desarrollo, que engloba las actividades de la organizacin
que tcnicas se utilizan en cada etapa, que define y desarrolla un sistema o producto software. Este proceso
que restricciones se aplican (de tiempo, coste, objetivos, etc.), se divide en las siguientes actividades:.
como se integran las actividades de gestin y control.
o Anlisis de requisitos del sistema,
Existen muchas metodologas ampliamente extendidas, aunque tambin o Diseo de la arquitectura del sistema,
hay muchas empresas que desarrollan su propia metodologa o adaptan alguna o Anlisis de los requisitos del software,
ya existente. Entre las ms utilizadas podemos distinguir entre aquellas o Diseo de la arquitectura del software,
oficiales, patrocinadas por gobiernos, como: o Diseo detallado del software,
o Codificacin del software y pruebas,
Mtrica (Espaa); o Integracin del software,
Merise (Francia); o Prueba de cualificacin del software,
SSADM (Reino Unido), o Integracin de sistemas,
o Prueba de cualificacin del sistema,
y las no oficiales, desarrolladas por universidades, empresas, expertos, etc. o Ayuda a la aceptacin.
Por ejemplo:
Proceso de documentacin, en el que se realizan las actividades para
YOURDON; registrar la informacin producida por cada proceso del ciclo de
UN1FIED PROCESS (Roumbaugh, Booch, Jacobson). vida.
Asignacin de trabajo a los miembros del equipo. Apartado especial, de gran importancia en esta fase, son las pruebas de
implantacin y aceptacin. Las primeras deben controlar aspectos tales como
Gestin de incidencias (por ejemplo: retrasos, fallos del hardware, las comunicaciones, la gestin del volumen real de datos en produccin, los
bajas laborales, etc.) tiempos de respuesta, seguridad, interfaces, etc. Respecto a las pruebas de
aceptacin, estas se realizan por y para los usuarios. Tienen como objetivo
Gestin de cambios en los requisitos: Por su gravedad, es el ltimo validar formalmente que el sistema se ajusta a sus necesidades.
recurso al que hay que recurrir para resolver un problema.
En cuanto a las actividades de gestin su objetivo es dar por concluido el
proyecto (una vez aceptado por el usuario). Podemos destacar, dentro de las
Actualizacin de la planificacin (replanificacin, si es necesario).
actividades de finalizacin del proyecto, las siguientes:
Gestin de la configuracin: Esta actividad puede ser considerada
Registrar (archivar) toda la informacin (documentacin), de forma
fuera de las propias del seguimiento y control, segn el estndar ISO
accesible para futuros proyectos.
12207, la importancia de esta actividad exige que exista un proceso
especfico de gestin de configuracin adems de un proceso de Realizar el balance final del proyecto. Es importante detallar y
gestin. Su objetivo es mantener la integridad de los productos que discutir con todo el equipo de proyecto: las desviaciones, los
se obtienen a lo largo de un proyecto, garantizando que no se problemas, y las soluciones tomadas.
realizan cambios incontrolados y que todos los participantes en el
desarrollo del software disponen de la versin adecuada de los
productos que manejan. Dada su importancia tendr un captulo
especial en este libro. 7.7 OPERACIN Y MANTENIMIENTO
La fase de mantenimiento consiste en obtener nuevas versiones del sistema Las tareas a realizar en la fase de mantenimiento se inician con la
a partir de las peticiones que los usuarios realizan con motivo de un problema recepcin de una peticin de mantenimiento. Es fundamental llevar un registro
detectado en el sistema o por la necesidad de una mejora del mismo. De forma de dichas peticiones para su control y posterior anlisis que obtenga datos
resumida, mantenimiento es el proceso de cambio de un sistema despus de estadsticos de las peticiones recibidas y tratadas, el tiempo empleado, los
haberlo entregado. mdulos o subsistemas afectados, etc.
Las tareas de mantenimiento son las ltimas dentro del ciclo de vida del En el momento de registrar una peticin debemos establecer el tipo de
software, pero no las menos importantes. De hecho el mantenimiento del mantenimiento que se trata, entre los siguientes tipos:
software se ha convertido en la principal actividad en cuanto a recursos
necesarios y coste. Estadsticamente podemos decir que el coste de Correctivo. Cambios que corrigen errores del producto.
mantenimiento de un producto software a lo largo de toda su vida til supone Evolutivo. Cambios para cubrir nuevas necesidades del usuario o
ms del doble de los costes de desarrollo. El coste relativo del mantenimiento expansiones del sistema.
respecto al total del coste del software representa actualmente ms del 90% del Adaptativo. Cambios que afectan al entorno del sistema, como
total. La siguiente tabla nos ilustra segn estudios de diversos autores, en comunicaciones, hardware, gestor de bases de datos, etc.
distintos aos, como va aumentando a lo largo del tiempo. Perfectivo. Cambios que mejoran la calidad interna del sistema,
como reestructuracin del cdigo, optimizacin del rendimiento, etc.
ANO PROPORCION DEL AUTOR
COSTE DE
En contra de lo que podra parecer no es el mantenimiento correctivo el de
MANTENIMIENTO
mayor actividad, sino que la mayor parte del mantenimiento es del tipo
2000 >90% Erlikh (2000) evolutivo. El siguiente grfico muestra como se distribuye el esfuerzo total de
1993 75% Eastwood (1993) mantenimiento entre los distintos tipos.
Perfectivo
5%
Correctivo
17%
De momento no nos ocupamos con preguntas del tipo quin tiene que
Una vez comprometidos todos los expertos de las distintas reas afectadas hacerlo? Ya que es esta actividad la abordaremos ms tarde junto a un
se podr comenzar a disear un eficiente plan de trabajo, para ello, un mtodo establecimiento de niveles y cuentas para poder responder de los costes.
consiste en establecer plazos de entrega parciales, al anlisis de estos plazos de
entrega parciales surgirn nuevos trabajos a realizar y as trabajando en espiral Es necesario que las tareas sean totalmente claras en cuanto a saber cuando
se podr llegar a completar esas fases, al mismo tiempo se pueden ir plasmando termina de tal forma que si en algn caso no se tiene idea clara de cuando
en un primer esbozo de red sin atender al grado de control que se realizar terminar se deber descomponer en tareas concretas mucho ms claras. En el
posteriormente. caso de obtener alguna tarea de duracin muy larga deberemos volver a
descomponerla en varias tareas ms cortas cuya finalizacin pueda ser
En primer lugar deberemos establecer la forma de ordenar las fases controlada temporalmente.
fundamentales del proyecto para lo cual, el director del proyecto, deber prever
cualquier tipo de actividad que le facilite la correcta ejecucin del proyecto en Existen algunas tareas que se pueden clasificar como recurrentes y que
s, de esta forma crear tareas y las subtareas que las conforman con criterios algunas herramientas de ayuda a la gestin de proyectos nos ayudarn a crear y
de orden en el tiempo para lo cual se ayudar por alguna de las metodologas a controlar con un mnimo esfuerzo por lo que tendremos que identificarlas
existentes en la empresa o en la comunidad cientfica. para que, por su repeticin, nos descargue de tareas de definicin en cada
momento de utilizarlas.
Una fuente de ordenacin de las fases fundamentales puede ser la lista de
etapas que a nivel global se han de recorrer pues nos servir para establecer los
hitos1 del proyecto con sus posibles fechas tpe de ejecucin.
8.3 DEPENDENCIA ENTRE TAREAS
Una vez relacionadas las tareas nos queda determinar las dependencias entre
8.2 RELACIN DE TAREAS ellas. Estas dependencias nos guiarn en su ordenacin y planificacin. En la
tarea de identificar y documentar dependencias debemos distinguir cinco clases
Una vez que se han obtenido las fases fundamentales, para acometer el trabajo diferentes:
de planificacin del proyecto, tendremos que obtener las tareas del proyecto,
entendiendo que una fase est formada por varias tareas. La forma de obtener Restricciones. Son los factores que limitan las opciones del equipo de
la lista de tareas puede ser de forma analtica, que son las formas conocidas en desarrollo y viene impuestas por el cliente o la direccin de la empresa
ingeniera como de arriba abajo, o por tcnicas guiadas por fines que son las desarrolladora. Ejemplos de este tipo de dependencias puede ser el
ms utilizadas en las metodologas de construccin de sistemas, en el caso de lenguaje de desarrollo, el entorno hardware, el personal que formar el
informtica. En cualquier caso lo que tendremos que contestarnos a preguntas equipo de trabajo, las fechas de entrega definidas por el cliente, el
del tipo qu hay que hacer para establecer las fases necesarias para poder llegar calendario laboral, etc.
a realizar el proyecto. En este nivel trataremos de descomponer el proyecto en
tantas fases como niveles de control deseemos implementar y, a ser, posible, de Supuestos. Son las decisiones que se toman en el momento de planificar
tal forma que cada fase corresponda a labores realizadas por el mnimo nmero pero de las que no estamos totalmente seguros. Constituyen
de personas posibles. suposiciones que estn directamente relacionadas con el riego del
proyecto y tiene una probabilidad de no cumplirse durante el desarrollo
del proyecto tal y como se definieron durante la planificacin. Ejemplos
de supuestos pueden ser la disponibilidad de un usuario experto durante
1 Real Diccionario de a Lengua Espaola: Del latn /id u s (fijo). Como sustantivo: Firme, Jijo. el desarrollo del proyecto, la disponibilidad de un ordenador en casa del
Tambin se define como blanco o pimo adonde se dirige la vista o puntera para acertar el cliente, la disponibilidad constante del servidor de desarrollo (no habr
tiro". En nuestro caso los Hitos son tareas a las que no se les asigna un plazo concreto pero que
marcan puntos de inters en el desarrollo dei proyecto.
averas ni cortes de mantenimiento), la estabilidad del personal
110 P L A N IF IC A C I N Y G E S TI N D E S IS T E M A S IN F O R M T IC O S C A P T U L O 8: H IT O S . D O C U M E N T O S Y R E V IS IO N E S 111
disponible, la 110 modificacin de la versin del software de base utilizar; las tareas se representan con una longitud proporcional a su duracin
durante el desarrollo, etc. mediante barras horizontales.
L-r
lgico con el usuario, etc. ' i
J
{JC , i
; i ral
establecido, el director pueda tener un soporte para su toma de decisiones a tenga claro que la segunda de ellas 110 puede comenzar hasta que comience la
implementar para tratar de atajar la desviacin. precedente. Un ejemplo podra ser el hecho de poder cargar programas en una
mquina a partir del momento en que se activen las lneas de comunicaciones.
El tipo de informacin que necesita el gestor del proyecto puntualmente Se representa por una flecha que parte del inicio de la tarea precedente hacia el
ser del tipo En qu afecta el retraso? Qu sucede si esta tarea finaliza antes inicio de la sucesora.
de lo que inicialmente estaba planificado? Si tal tarea se retrasa en cunto se
retrasa todo el proyecto? Cmo afectar econmicamente al desarrollo?. Los vnculos definidos de final a final se establecen cuando se quiere
Como puede adivinarse el nmero de controles a establecer en la ejecucin del indicar que una tarea precedente no puede finalizar antes que la sucesora. Por
proyecto puede desbordamos si no sigue una tcnica apropiada y es necesario ejemplo, no se puede realizar la entrega de un mdulo software sin que el
informar correctamente de los condicionantes de cada tarea para poder cliente formalmente lo recepcione. La representacin grfica en el diagrama de
adelantarnos a la multitud de cuestiones que necesitaremos responder para que Gantt se realiza con una flecha que parte del final de la barra de la tarea
el efecto de un incidente no altere, o altere de forma mnima, la ejecucin del predecesora y que finaliza al final de la barra de la tarea sucesora.
proyecto.
Finalmente, el caso de vnculo de comienzo a final depende el final de la
Las relaciones entre tareas se definen a travs de vnculos. Estos vnculos predecesora con el comienzo de la sucesora. La representacin grfica, en este
nos permiten definir en qu condiciones puede comenzar una tarea respecto a caso, consiste en fijar el inicio de la flecha al principio de la barra de la tarea
otra; por ejemplo, no podremos probar un mdulo de programa mientras ste predecesora, y el final de la flecha al final de la barra de la tarea sucesora.
no est compilado. En este sentido una tarea que est vinculada a otra anterior
se denomina sucesora y la primera, respecto a la segunda, sucesora. Con estos Una vez definidos todos los vnculos podemos obtener un diagrama de
vnculos definimos que una tarea no puede comenzar si la predecesora no ha Gantt que nos orientar en una planificacin inicial de las tareas a realizar an
finalizado quedando el concepto anterior o posterior relegado a otro nivel. Es no sometido a las restricciones de los recursos a emplear.
decir el orden de ejecucin de algunas tareas no tendr necesariamente nada
que ver con el orden definido por los niveles de vinculacin.
Hemos empleado el trmino finalizado como momento en el que puede 8.5 LOS HITOS Y SUS FECHAS LMITE.
comenzar la tarea sucesora para un mejor entendimiento del tema, sin embargo
el orden de vinculacin puede ser de los siguientes tipos: Con la descomposicin del proyecto en fases con su duracin de trabajo
deberemos ver si esta primera estimacin es suficiente para lo cual marcaremos
Final a comienzo sobre el diagrama los hitos que deben de cumplirse en cada fecha de tal forma
Comienzo a comienzo que se podamos considerar, en al caso de no disponer de tiempo suficiente, que
Final a final tareas se debern acortar a base de dedicar mayor nmero de recursos. Esta
Comienzo a fin labor nos permitir establecer un primer paralelismo de tareas para poder
acortar la duracin del proyecto. An no sabemos cundo debe de efectuarse
El primer caso de los anteriores es el ms normal y marca que la actividad cada una de las tareas, hemos establecido los prerrequisitos en forma de
sucesora podr comenzar cuando de haya finalizado la actividad predecesora; vnculos y, ahora, debemos estudiar el calendario del proyecto.
por ejemplo para instalar el sistema operativo de un ordenador es necesario que
previamente se disponga del ordenador. En los diagramas de Gantt, este tipo de Los hitos los introduciremos como tareas de duracin nula, pero al fin y al
vnculos se representan por una flecha que tiene por origen el final de la barra cabo se debern considerar como una tarea ms con algunas consideraciones
de la tarea precedente, y como destino el principio de la tarea sucesora. respecto a cundo debe de comenzar o terminar. En el fondo lo que vamos a
imponer es una nueva serie de restricciones al proyecto para que el programa
Es posible que varias actividades puedan comenzar al mismo tiempo o con que se utilice nos ayude a tomar decisiones ya que, al final, los proyectos se
un intervalo mnimo entre ellas. Lo importante es que conceptualmente se plantean, o bien para terminar en una fecha dada o para comenzar a partir de
(
114 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 F O R M T IC O S C A P IT U L O S: H IT O S . D O C U M E N T O S Y R E V IS IO N E S
una fecha concreta, y esto condiciona los recursos ya que se pueden programar Es necesario tener en cuenta que la mayor parte de las herramientas
para finalizar lo ms tarde posible dentro del tiempo del proyecto. informticas de ayuda a la gestin de proyectos, facilitan informacin relevante
sobre las desviaciones que pueden producirse en el desarrollo del calendario
En este sentido definiremos una serie de delimitadores que nos ayudarn a del proyecto, y que, gracias a su fuerte potencia de clculo, permite estimar
encuadrar el proyecto dentro de un calendario concreto: objetivos rpidamente en el sentido de solucionar respuestas a preguntas de la
forma qu pasa si...?
LMPI: La tarea debe comenzar "lo ms pronto posible"
LMTP: La tarea debe comenzar "lo ms tarde posible"
Empezar en: El inicio de la tarea es fijo Empezar Antes: El inicio de la
tarea se programa LMPP y puede retrasarse por precedencia o por 8.6 DIAGRAM AS DE CARGA.
nivelacin slo hasta la fecha de inicio obligado.
Empezar despus: La tarea se retrasa hasta la fecha obligada de inicio, Partiendo del diagrama de Gantt es posible obtener una representacin grfica
aunque tambin se puede retrasar despus por precedencia o nivelacin. del uso de un determinado recurso en un proyecto. Este tipo de representacin
Es til en tareas en las que se conoce la fecha mnima de inicio se denomina diagrama de carga del recurso. Es muy til para:
permitida.
Empezar antes de: La tarea se retrasa hasta la fecha obligada de inicio, Comunicar a los participantes el uso de un recurso compartido que
aunque tambin se puede retrasar despus por precedencia o nivelacin. puede ser crtico, como el administrador de las bases de datos o el
Es til en tareas en las que se conoce la fecha mnima de inicio usuario experto.
permitida. Verificar que se utiliza de forma equilibrada a lo largo del tiempo.
Acabar en: El final de la tarea es fijo; debe terminar necesariamente en Verificar que no se utiliza ms de lo posible, es decir su carga sea
la fecha de fin obligado, y no puede sufrir retrasos posteriores por superior a sus horas de dedicacin al proyecto o vaya ms all del
precedencias o nivelacin. momento en que termina su dedicacin al proyecto.
Acabar antes: La tarea comienza LMPP y puede sufrir retrasos por
precedencia o nivelacin slo hasta que su final alcance la fecha de Fin Ejemplo 1: A partir del siguiente diagrama de Gantt que refleja el
Obligado. tipo de recurso y la cantidad necesaria en cada actividad
Acabar despus: La tarea se retrasa hasta que su final concuerde con la (A=Analista; P=Programador) se desea ver la asignacin de
fecha lmite obligada. programadores a1proyecto:
Trabajar entre: La tarea se retrasa hasta la fecha obligada de inicio, y
se puede retrasar posteriormente por precedencia o nivelacin, pero
slo hasta que su final alcance la fecha de Fin Obligado.
En primer lugar se deben seleccionar aquellas tareas que utilicen el contrato al cliente y se firm a definitivamente.
recurso a estudiar. En nuestro ejemplo estn marcadas con una P.
2. Las dos semanas siguientes se dedicarn al anlisis y especificacin
A continuacin obtenemos el diagrama de carga de la necesidad del de requisitos. Esta actividad se dividir en las siguientes tareas:
recurso en el tiempo. Para ello sumamos por periodos la cantidad de 2.1. Anlisis de requisitos con el cliente (2 horas). Todo el equipo
recursos que necesita cada tarea que debe desarrollarse en ese periodo. junto con el cliente comienza a analizar y valorar el sistema en
general y se prof undiza en algunos aspectos.
2.2. Reunin del equipo con miembros de otros proyectos
relacionados (4 horas). Despus de la tarea anterior, pero en distinto
da se lleva a cabo una reunin con los otros proyectos relacionados
para acordar ciertos aspectos comunes y de interaccin. Para esta
reunin interviene de nuevo todo el equipo, as como tambin
representantes de los otros proyectos.
2.3. Especificacin base de datos (11 horas aprox.). Para llevar a
cabo la tarea de la especificacin de la base de datos, se volvi a
En este diagrama el eje horizontal representa el tiempo, en este caso reunir todo el grupo para decidir cual podra ser el mejor diseo para
meses, y el eje vertical representa la necesidad del recurso, en este ella.
caso el nmero de programadores, aunque tambin es muy habitual 2.4. Reunin del equipo con miembros de otros proyectos
representar las horas o das de dedicacin del recurso. relacionados sobre la base de datos (4 horas) A la vez que se realiza
la tarea anterior, se desarrolla esta otra tarea en el 2 o da de la tarea
anterior para corregir los posibles errores e intentar llegar a un
acuerdo sobre aspectos coincidentes y compartidos de a base de
Ejemplo 2: Se decide iniciar un proyecto de desarrollo de un sistema datos. Interviene todo el equipo y miembros de los otros proyectos.
software integrado en otros sistemas existentes y se detallan las 2.5. Especificacin protocolo de comunicaciones (4 horas aprox.)
actividades iniciales del proyecto que sern llevadas acabo por el jefe Durante esta fa se todo el equipo trata el tema del protocolo de
de proyecto, un analista encargado de definir los requisitos y otro de comunicaciones.
la especificacin del proyecto. Se pide un diagrama detallado de las 2.6. Reunin del equipo con miembros de otros proyectos
actividades y la carga de los recursos para las actividades definidas. relacionados sobre el protocolo de comunicaciones (5 horas). Se
vuelve a reunir todo el equipo con miembros de os dems proyectos,
Las actividades iniciales detalladas son las siguientes: para decidir aspectos comunes del protocolo especificado en la tarea
anterior.
1. Se dedicar la primera semana a la firm a del contrato. El cliente 2.7. Integracin interna de requisitos y especificaciones (aprox. 40
nos indica que solo estar disponible los lunes y los jueves. Esta horas). Para llegar a la conclusin de este documento intervienen el
actividad se dividir en las siguientes tareas: analista encargado de los requisitos (aprox. 15 horas) y el analista
1.1. Reunin con el cliente (2 horas). Todo el equipo se rene con el responsable de la especificacin (25 horas aprox.).
diente, para aclarar necesidades generales y concretar algo ms sus 2.8. Finalizacin de definicin del nuevo sistema (requisitos y
objetivos. especificaciones (2 horas aprox.). Una vez que el documento est
1.2. Redaccin del contrato (7 horas). Todo el equipo escribe el finalizado, todo el equipo lo revisa.
contrato aportando ideas obtenidas de la tarea anterior.
1.3. Revisin del contrato (2 horas). Todo el equipo revisa el contrato
escrito en la tarea anterior. El primer paso en la resolucin de este ejercicio es el diseo del
1.4. Aprobacin del contrato (2 horas). Todo el equipo presenta el diagrama de Gantt de las actividades detalladas teniendo en cuenta lo
(
(
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 F O R M T IC O S C A P T U L O 8: H IT O S . D O C U M E N T O S Y R E V IS IO N E S
1.3
Analista de la especificacin:
1.4
......
2.1
2.2
2.3 ............
....... ;..... - ... . . . .. . .
.........
2.4
2.5
- ...- .........
2.6 --- 1 .....-
2.7
2.8 i
Jefe de proyecto:
j
8 j
?
?
7 i
i 8.7 LA DOCUM ENTACIN TCNICA COMO HERRAMIENTA
6 !
DE SEGUIM IENTO DE LA PLANIFICACIN.
5
Los ajustes a la planificacin sern constantes y actuarn en forma de Cualquier tarea pasada por alto inadvertidamente durante el periodo de
espiral hasta lograr la mejor planificacin del proyecto. estimacin, dar como resultado un menosprecio del proyecto en su totalidad,
este hecho, a su vez podra comprometer la planificacin del factor tiempo y de
los recursos que se deben utilizar y, lo que es peor, habr que pagar un trabajo
omitido, no en base al presupuesto, sino en base a los beneficios esperados.
1 El ttulo del libro donde Boehm nos facilita un mejor conocimiento de su pretensin.
124 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 F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 125
niveles segn la complejidad de los proyectos aportando herramientas para de calidad, de la integracin del sistema, del entrenamiento y de la
controlar el coste, no slo del diseo y desarrollo del sistema, sino que cubre documentacin. Los costes del personal relacionado se estiman mediante el
todos los aspectos en la estimacin de todo el proyecto a lo largo de su ciclo de examen del coste de proyectos anteriores que resulten similares.
vida, excepto el estudio de viabilidad, puesta en marcha y mantenimiento.
En la estimacin jerrquica hacia arriba, primero se estima el coste del
desarrollo de cada mdulo o subsistema, tales costes se integran para obtener
un coste total. La tcnica puede fallar al no considerar los costes del manejo de
9.1 M O D E L O S EM PR IC O S la configuracin o del control de calidad, pero tiene la ventaja de enfocarse
directamente a los costes del sistema.
Una vez asentados sus conocimientos sobre las fases en que se divide un
proyecto software desde las perspectivas de los distintos paradigmas de la Podemos establecer una clasificacin de los llamados modelos empricos
Ingeniera del Software se considera, en lneas generales, que todo proceso de de estimacin de costes basados en la experiencia:
desarrollo de software est compuesto por tres fases genricas que son:
definicin, desarrollo y mantenimiento, y en todos ellos tenemos que Juicio de experto. E11 esta categora un experto o grupo de expertos
considerar los modelos de estimacin de costes, que si bien en Informtica 110 estudia las especificaciones y hace su estimacin (jerrquica hacia
son relativamente novedosos, ya que los primeros esbozos en estudiar este arriba o hacia abajo) en base a sus conocimientos previos. Cuando hay
problema comenzaron hace poco ms de dos dcadas, la implantacin real en un nico experto se denomina juicio experto puro y la empresa corre el
la industria no se ha realizado de forma masiva hasta que se ha dado el hecho riesgo de confiar una tarea tan importante a una nica persona. Si
de que el software se ha convertido en el factor mas costoso de un sistema de desaparece el experto se deja de estimar. Si es un grupo de expertos el
informacin; es ms: la desviacin producida por los costes de software en el que estima se suele utilizar el mtodo Delphi o juicio experto. Este
desarrollo de un proyecto tena poca incidencia en el coste total, cosa que no mtodo consiste en que el grupo se rene para dar sus opiniones sobre
ocurre hoy da ya que un error de estimacin del tiempo de desarrollo puede la estimacin. Las conclusiones individuales se envan al coordinador
colocar el proyecto entre el beneficio y la prdida econmica. del grupo que las compara entre s. Si los resultados son parecidos la
estimacin se da por buena, si no es as cada estimador recibe
Los modelos de estimacin tienen aplicacin dentro de la fase de informacin sobre su estimacin, y las ajenas pero de forma annima.
definicin de un sistema software. En esta fase lo que se define es el qu, es Cada uno revisa su propia estimacin y la enva de nuevo al
decir, se intenta identificar en ella qu informacin va a ser procesada, qu coordinador. Se repite el proceso hasta que la estimacin converge de
funcin y rendimiento se desea, qu interfaces han de establecerse, qu forma razonable. Es posible realizar nuevas reuniones del grupo si el
ligaduras de diseo existen y, por ltimo, qu criterios de validacin se coordinador lo considera oportuno segn la divergencia de las
requieren para definir un sistema correcto. estimaciones recibidas Tiene la ventaja de que las estimaciones de un
grupo suelen ser mejores que las individuales y que el experto nico no
Dentro de la mayor parte de las organizaciones, la estimacin de costes de se convierte en un recurso crtico imprescindible.
un sistema software est basada en experiencias pasadas. Los datos histricos
se usan para identificar los factores de coste y determinar la importancia Analoga. Consiste en comparar las especificaciones de un proyecto,
relativa de los diversos factores dentro de la organizacin. Lo anteriormente con las de otros proyectos similares segn el tamao, complejidad,
expuesto implica que los datos de coste y productividad de los proyectos nmero y tipo de usuarios y otros factores como sistemas operativos,
actuales deben de ser centralizados y almacenados para su empleo posterior. La hardware, personal, etc.
estimacin de costes puede llevarse a cabo de forma jerrquica hacia abajo
(Top-Down) o jerrquica hacia arriba (Bottom-Up). Distribucin de la utilizacin de los recursos durante el ciclo de vida.
Este mtodo solo se puede aplicar cuando el proyecto ya ha comenzado
La estimacin jerrquica hacia abajo se enfoca primero a los costes a nivel y se ha desarrollado alguna de sus fases. Usualmente las organizaciones
del sistema, adems de los costes del manejo de la configuracin, del control tienen una estructura de costes similar entre las distintas fases del ciclo
126 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 F O R M T IC O S C A P T U L O 9: EL M T O D O D E C O S T E S 127
de vida (especificaciones, anlisis, diseo, construccin, prueba e aplicar y que puede ser calculada fcilmente en base a la experiencia y que
implantacin) de sus proyectos. Si en un proyecto ya hemos realizado existe una gran cantidad de informacin basada en las LDC. Sus detractores
algunas fases, es de esperar que los costes se distribuyan de manera dicen que las LDC dependen del lenguaje de programacin, que perjudica a los
proporcional en las fases siguientes. programas ms cortos pero mejor diseados y que su utilizacin requiere un
nivel de detalle que puede ser difcil de conseguir.
Existen otros mtodos de estimacin emprica menos utilizados pero que a
veces se utilizan como soporte o en combinacin con otros. Entre ellos estn El anlisis de los puntos funcin se basa en establecer relaciones entre los
componentes bsicos de cada tarea y el esfuerzo requerido en desarrollarlos. El
Mtodo basado exclusivamente en los recursos. En la estimacin procedimiento a seguir para calcular los puntos funcin consiste en ir
consiste en ver de cuanto personal disponemos para el proyecto y rellenando los datos de una serie de tabla, basada en la experiencia, en las que
durante cuanto tiempo se dispone de l. Estos sern los recursos a se introducen algunos datos respecto a variables del proyecto como pudieran
utilizar. Se basa en la siguiente premisa El trabajo se expande hasta ser el nmero de entradas, el nmero de salidas, la cantidad de ficheros que
consumir todos los recursos disponibles (Ley de Parkinson). trata la aplicacin, el tamao de los ficheros en nmero de campos, la cantidad
de consultas que se pretenden efectuar, etc. Cada uno de estos valores se
Mtodo basado exclusivamente en el mercado. Parte de que lo ms clasifica en tres categoras respecto a la complejidad que puede ser alta, media
importante es conseguir el contrato. El precio se fija en funcin de lo o baja. Igualmente se establece una segunda dimensin en cuanto al tamao de
que creemos que esta dispuesto a pagar el cliente. La estimacin de cada elemento, clasificndolos en pequeo, medio y grande. En ambas
costes del proyecto ser el precio a pagar por el cliente menos los clasificaciones siempre ser ms importante seguir criterios de consistencia
beneficios econmicos que se desea obtener. sobre criterios de precisin; es decir deber imperar el mtodo de clasificar en
grandes grupos todos los elementos de la configuracin.
9.2 PUNTOS FUNCIN Caso prctico: Creacin de una tabla para medir los puntos
funcin asociados al esfuerzo necesario para definir y documentar
Las Mtricas Orientadas a la Funcin se basan en estimar no el nmero de los ficheros maestros y los grupos principales de datos del usuario:
lneas fuente del programa (LDC) sino su "funcionalidad". Estas mtricas,
propuestas inicialmente por Albretch en 1979 y 1983, intentan buscar un factor Factor de tamao:
de productividad del software mediante el mtodo denominado de anlisis de Pequeo: menos de 15 campos por registro
los puntos funcin2. Los puntos de funcin se obtienen como consecuencia de Medio: entre 15 y 50 campos por registro
haber estudiado distintos proyectos de software y haber aplicado sobre ellos Grande: ms de 50 datos por registro.
una mtrica basada en la complejidad y el tamao de la funcin realizada.
Esta clasificacin por tamao del registro en cuanto al nmero
La medida del punto funcin se ha aplicado con xito en sistemas no de campos no debe confundirse con los datos que realmente tendr
empotrados y concretamente en sistemas comerciales y puede no ser relevante el fichero en explotacin que se considerarn como aspectos
en otros sistemas de ingeniera. relacionados con el rendimiento que definiremos en la siguiente
clasificacin. EL orden actual define esfuerzos de creacin y
Las mtricas orientadas al tamao son bastante polmicas y no estn documentacin de registros, o tupias de bases de datos, desde el
aceptadas universalmente como el mejor mtodo para medir la productividad punto de vista de su intensin, o esquema, y no de su extensin.
en el desarrollo del software ya que el nmero de lneas de cdigo escrito no
parece una buena medida. Sus defensores dicen que esta medida es fcil de Factor de complejidad
Sencilla: un solo tipo de registro sin problemas de
2 El trmino en ingls es Function Point Anlisis (PFA).
rendimiento
128 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 F O R M T IC O S C A P T U L O 9: EL M T O D O D li C O S T E S 129
Normal: intermedia Esta misma labor se realizar para cada una de las tareas a satisfacer en
Alta: varios tipos de registros y consideraciones de cada fase, se analizar el esfuerzo requerido en el anlisis del sistema, en la
rendimiento determinacin de los requerimientos, en el diseo lgico del producto, en la
codificacin, en las pruebas de integridad y en la implementacin de tal forma
Con el orden anterior tendremos un primer grupo, que que al final tenemos el esfuerzo total en nmero de puntos.
clasificaremos corno de complejidad sencilla, es el que se
aglutinar todo el esfuerzo para definir ficheros planos, es decir, Cuntas tablas de puntos funcin tendramos que utilizar para obtener la
formados por un tipo de registro nico, y que no tiene problemas ni estimacin? Depende del nivel de detalle y de la consistencia de la
de espacio, por ser pequeo el nmero de registros, ni de organizacin que crea el software. De entrada se debera partir de pocos
volatilidad, por lo que no hay que hacer consideraciones modelos: es decir, se puede partir de una estimacin para ficheros o almacenes
importantes en el rendimiento cuando sea accedido. Tendremos un de datos, de pantallas de entrada o consulta de datos, de los informes que se
segundo grupo (complejidad normal), es similar al anterior pero producirn y de los tipos de procesos. Sobre estos modelos se incluirn todos
con un tamao de registros amplio, por lo que se debe de empezar a los esfuerzos adicionales no contemplados de tal manera que la suma total de
considerar problemas en el rendimiento. Y, finalmente, un tercer puntos funcin satisfaga la totalidad del esfuerzo.
grupo que estara formado por los ficheros que deben de ser
estudiados cuidadosamente bien por que tengan varios tipos de Estudios posteriores al modelo de los puntos funcin incorporaron unos
registros, porque sean muy voltiles, porque sean muy grandes o parmetros de ajuste de toda la estimacin anterior a las caractersticas propias
porque se estime que deben de satisfacer una condiciones de cada uno de los sistemas concretos a construir atendiendo a su complejidad.
especiales de rendimiento. Estos pueden ser, por ejemplo:
Una vez definidas las medidas a aplicar introducimos en Requisitos especiales en comunicaciones de datos
nmero de puntos que cuesta realizar cada funcin concreta Valoracin del rendimiento global del sistema
segn su tamao y su complejidad. Supongamos que nuestra Frecuencia de transacciones
compaa dispone de alguna de ellas y tiene los valores sealados Requisitos de operacin o de usuario final
en la figura siguiente (matriz de estimacin de pesos en el diseo Complejidad en los procesos internos
de ficheros). Facilidad de mantenimiento
instalacin en varias localizaciones distintas
Complejidad Incorporacin de funciones distribuidas
Baja Media Alta Entrada de datos interactiva
Tamao Pequeo 10 15 22 Existencia de procesos de actualizacin on-line
Medio 19 23 34 Coexistencia de mdulos con otros sistemas
Grande 27 34 45 Otros aspectos a valorar
Donde b es el valor mximo del peso dado a los parmetros de ajuste que, por
tanto, tendrn un peso entre 0 y b\ FC es el valor asignado a cada uno de los n Pantalla de ay uda: Clasif como salida: MEDIA
factores de ajuste, y n es el nmero de factores de ajuste. Clasif como entrada: SIMPLE
As, si, por ejemplo, tuviramos un proyecto de 2.304 puntos funcin y Consideremos que la organizacin que realiza la estimacin utiliza
queremos aplicarle doce factores globales de ajustes con un valor mximo de los siguientes datos base en la aplicacin de! mtodo de puntos de
ocho puntos para cada factor de complejidad cuando se considera complejidad funcin:
muy alta para cada uno de ellos, cuatro puntos en el caso medio y cero en el
caso de mnima complejidad, obtendremos un abanico de posibilidades que Simple Media Compleja Total
irn desde 1.497,6 puntos funcin ajustados hasta 3.110,4 en funcin de los Cantidad X Peso Cantidad X Peso Cantidad X Peso
pesos dados a cada uno de los factores individuales de ajuste. Entradas X3 X4 X6
Salidas X4 X5 X7
Consultas X3 X4 X6
Ejemplo: Calcular los puntos de funcin de una aplicacin si se Fich.Intcr. X7 X 10 X 15
establecen as siguientes funciones y clasificacin de las mismas. Fich.Exter. X5 X7 X 10
Suponer que los factores de complejidad a utilizar son tres: Total puntos de funcin sin ajustar
posibilidad de mxima facilidad de cambios, entrada de datos
totalmente on-line y lgica de proceso interno de media complejidad: Las entradas de la tabla anterior tienen el siguiente significado
Entradas. Son todos aquellos procesos que hacen llegar
Archivos lgicos internos: datos a la aplicacin desde el exterior, desde un usuario u
Registro Productos: Clasificacin: SIMPLE otra aplicacin.
Registro Proveedores: Clasificacin: MEDIA Salidas. Son todos aquellos procesos que hacen legar
Registro Pedidos: Clasificacin: SIMPLE datos desde a aplicacin hacia el exterior, a un usuario o
a otra aplicacin.
Archivos de interfase externa
Consultas. Son todos aquellos procesos que estn
Histrico Pedidos: Clasificacin: SIMPLE
formados por una combinacin de entradas y salidas,
Contraseas: Clasificacin: SIMPLE
produciendo una consulta a los datos. La complejidad de
la consulta viene dada por la mayor entre la entrada y la
Entradas
salida.
Alta de Productos: Clasif: SIMPLE
Ficheros internos. Es un grupo de datos relacionados, tal
Modificacin Productos: Clasif: SIMPLE
como los percibe el usuario y que son mantenidos por la
Eliminacin Productos: Clasif: SIMPLE
aplicacin.
Ficheros Externos. Es un grupo de datos relacionados, tal
Salidas
como los percibe el usuario, referenciados por la
Listados por Productos: Clasif: MEDIA
aplicacin y que son mantenidos p o r otra aplicacin.
Listados por Proveedores: Clasif: MEDIA
A los factores de ajuste se les da una puntuacin de 0 (bajo) a 5
Consultas
(alto).
Consulta Productos: Clasif como salida: SIMPLE
Clasif como entrada: SIMPLE
Consulta Proveedores: Clasif como salida: SIMPLE
____________ ___________C lasif como entrada: MEDIA____________
.1
132 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 F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 133
PFA = (0,65+((0,7x(5+5+3))/(5x3)))x64 = (0,65+((0,7xl3)/15))x64 = En nuestro caso, y segn experiencias anteriores, se sabe que la media de
(0,65+0,60)x64 = 80 nuestros ltimos trabajos ha supuesto que la fase de diseo supone un
porcentaje del tiempo total invertido en cada proyecto con independencia del
tamao, y cada una de las fases se distribuye segn el porcentaje expuesto. Con
Los factores de ajuste, e incluso la forma de asignar los pesos de los estos criterios se puede estimar, por medio de la extrapolacin, la duracin total
puntos funcin, pueden ser responsabilidad de cada una de las empresas, sin del proyecto cuando se ha ejecutado alguna de sus partes.
embargo, en 1984, el International Function Point Users Group3, emiti un
primer documento oficial para intentar normalizar el uso de los mismos valores Este mtodo tiene serios inconvenientes, sobre todo cuando los proyectos
en la comunidad de desarrolladores de proyectos que se ha ido actualizando a no son del mismo tamao, ya que no es normal que se disponga de tablas
lo largo del tiempo. adecuadas para cada tipo de proyecto suficientemente actualizadas. No
obstante se utiliza bastante como control de validez del mtodo de los Puntos
Posteriormente Jones, en su libro Programming Productivity propone Funcin de Albretch, sobretodo cuando se comparan los porcentajes de ambos
una equivalencia entre puntos funcin y lneas de cdigo fuente producidas mtodos, ya que nos puede ayudar a estudiar dnde se producen las mayores
segn cada lenguaje de programacin empleado; de esta forma se puede desviaciones por si se trata de errores de clculo o si se han omitido alguna de
estimar, por ejemplo, que cada punto funcin oficial equivale a 91 lneas de las fases.
cdigo fuente en Cobol ANSI. En este sentido se puede llegar a establecer una
equivalencia entre puntos funcin y lneas de cdigo fuente pudindose, por Para efectuar esta comparacin se tabulan sobre una hoja de clculo los
tanto, estimar el esfuerzo en ambas medidas. resultados de cada fase del ciclo de vida y se decide estudiar a detalle aquellos
hitos que tengan una desviacin superior al 15%.
1
134 P L A N IF IC A C I N Y G E S T I N D B S IS T E M A S IN F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 135
Una posible tabla de comprobacin de los esfuerzos necesarios para la procesos establecidos en la mayor parte de las metodologas de desarrollos de
construccin de software, obtenida por mtodos estadsticos, de una compaa sistemas informticos clsicas. Las fases que cubre el modelo de Boehm son
podra ser la siguiente: todas las descritas en el ciclo de vida de productos software con la excepcin
del estudio de la viabilidad y el anlisis de requerimientos, los cuales se
estiman como un apartado cuantitativo del software de desarrollo. Sin embargo
FASE Esfuerzo
si se incluyen todos los costes incurridos en cada fase
FASE DE 20%
DISEO
Definicin de requisitas 8%
COCOMO es el modelo emprico para la estimacin de los costes de
Orientacin 4,6% produccin de software ms utilizado por los equipos de desarrollo de sistemas
Definicin de requisitos 3,4%
informticos de tamao grande, sin embargo, se deben tener en cuenta los
Diseo del sistema 12%
Diseo externo 7% propios comentarios de Boehm sobre COCOMO y por extensin sobre todos
Diseo interno y 5% los modelos: "Hoy en da, un modelo de estimacin de costes est bien
planificacin
Diseo interno 4% realizado si puede eslimar los costes de desarrollo de software dentro del 20%
de los costes reales, del 70% del tiempo y en su propio cam po (o sea dentro de
Planif. de la 1%
implantacin los tipos de proyectos en los que ha sido calibrado). Esto no es tan preciso
FASE DE 80% como quisiramos, pero es lo suficientemente preciso para proporcionar una
IMPLANTACIN
Desarrollo de programas 69%
buena ayuda en el anlisis econmico de la ingeniera del software y en la
Diseo en detalle y 11% toma de decisiones
orientacin
Orientacin 2%
Diseo en detalle 9% Boehm considera que la funcin de distribucin de Rayleight, definida
Codificacin 12%
como:
Pruebas de unidades 22%
Integracin y pruebas de 14%
K -ttt
subsistemas E s fuerzo = r t e ~
Pruebas y demostracin 12%
del sistema
Documentacin de usuario 19%
donde tj es el momento en el que se introduce un esfuerzo mximo, es un
F ig u r a 9.1 E je m p lo d e lista d e c o m p r o b a c i n d e l e s fu e rz o estimador exacto para los requisitos de personal para el ciclo de vida del
desarrollo (desde el diseo arquitectnico hasta las pruebas del sistema siempre
que usemos la porcin de curva entre 0,3td y 1,7 tj ).
El coste de cada fase incluye lodos los costes incurridos durante la fase.
Los costes de actualizacin del plan de integracin y prueba y la
aceptacin completa de los planes de prueba estn incluidos en la fase
de diseo detallado.
Antes de abordar el modelo propiamente dicho, es preciso enumerar una
serie de definiciones y consideraciones en las que se basa Boehm para el Para que se cumplan los criterios de estimacin del ciclo de vida del
desarrollo del modelo, como son: desarrollo de software es necesario resaltar las siguientes caractersticas:
El clculo del coste primario est basado en el nmero de instrucciones Se debe de prestar especial cuidado a la definicin y validacin de
fuentes desarrolladas en el proyecto sin incluir las lneas de la especificacin de los requerimientos software por un grupo de
comentarios, pruebas, documentacin, etc., a no ser que se escriban con personas relativamente pequeo con anterioridad a la entrada en la
un fin expreso y cuidado. fase de diseo.
El periodo de desarrollo cubierto por el modelo comienza al iniciarse la Posteriormente se debe de someter la definicin y validacin del
fase de diseo y termina al finalizar la fase de integracin y prueba. El diseo del sistema software a un grupo de personas algo ms grande
coste y calendario de otras fases se estiman por separado. como actividad anterior a la entrada en la fase de diseo detallado y
de la codificacin.
El modelo cubre nicamente las actividades indicadas dentro del equipo
de desarrollo de actividades o procesos del ciclo de vida. Por ello, El diseo detallado, la codificacin y las pruebas de unidades sern
incluye el esfuerzo de organizacin y documentacin, pero excluye desarrollados por un grupo grande de programadores trabajando en
algunos esfuerzos tales como la planificacin de la instalacin, esfuerzo paralelo, y siguiendo una lnea base slida que suponga un
de conversin, etc. desarrollo incremental de la planificacin.
Las soluciones se expresan en criterios de la forma hombres-mes La integracin y prueba de cada incremento en el sistema est
refirindose a 152 horas de tiempo de trabajo al mes desarrollado por basada en una gran cantidad de planificacin de pruebas tempranas
las personas del equipo de desarrollo. Este factor se ha calculado y en la eliminacin de casi todas las unidades defectuosas por
teniendo en cuenta la experiencia en los distintos proyectos medio de cuidadosos y completos recorridos de las unidades
desarrollados y considerando el tiempo de vacaciones. desarrolladas.
El modelo considera que el proyecto es bien dirigido tanto por el Una parte importante del esfuerzo de documentacin (por ejemplo
desarrollador del mismo como por el cliente, existiendo por ello muy los borradores de los manuales de usuario) se desarrollarn en fases
pocos tiempos perdidos en el anlisis de requerimientos del producto.
138 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 F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 139
tempranas para proporcionar a los usuarios (y desarrolladores) evaluacin subjetiva tanto del producto, como del hardware, del personal y de
informacin acerca de la naturaleza operacional del producto. los atributos del proyecto.
A raz de lo expuesto, se puede deducir que la cantidad de personal El modelo avanzado incorpora todas las caractersticas de la versin
requerido para el desarrollo de un proyecto no es constante. Generalmente, la intermedia con una evaluacin del impacto de las guas de coste en cada fase
planificacin y el anlisis lo realiza un grupo pequeo de personas, el diseo (anlisis, diseo, etc.) del proceso de ingeniera del software.
arquitectnico un grupo mayor, aunque como hemos indicado, todava es
pequeo comparado con el personal que interviene en el diseo detallado, que Igualmente, Boehm distingue tres tipos de modos de desarrollo en base a
es un grupo ms numeroso generalmente. As mismo, la etapa inicial de las caractersticas del producto software, para cada uno de los modelos
mantenimiento puede requerir un nmero elevado de personal, aunque este anteriormente definidos:
nmero deber disminuir en poco tiempo, si no existen mejoras o adaptaciones
importantes, permaneciendo el nmero de personal asignado a esta etapa Modo orgnico
pequeo y constante. Modo semiacoplado
Modo empotrado
Por ello, Boehm considera que la curva de distribucin de Rayleigh es un
estimador razonablemente exacto de los requisitos de personal para el ciclo de El modo orgnico se emplea en proyectos relativamente pequeos y
vida de desarrollo, desde el diseo arquitectnico hasta las pruebas del sistema, sencillos en los que pequeos equipos de trabajo, con buena experiencia en la
siempre y cuando se use la porcin de la curva entre 0.3td y 1.7td. Esta aplicacin, trabajan en un conjunto poco rgido de requerimientos y en un
informacin la justifica Boehm en base a estudios anteriores de Norden (1970) entorno casi familiar. Esto permite que mucha de la gente del proyecto pueda,
y Putnam (1978), que indican que el rea total bajo la curva Rayleigh es similar fcilmente, contribuir al desarrollo del mismo en las primeras etapas sin
o igual al esfuerzo requerido para el desarrollo del proyecto. Por ello, si se generar muchas canales de comunicacin y muchos requerimientos de
representa el esfuerzo de desarrollo frente al tiempo se obtiene la curva de bsqueda de informacin, ya que todo el entorno es bastante conocido por el
Rayleigh de la Figura 9.3. Donde td es el tiempo correspondiente al valor equipo de desarrollo. En los proyectos en modo orgnico es relativamente
mximo del esfuerzo en la curva Rayleigh y K es el esfuerzo total desarrollado, sencillo reunir los requerimientos e interfaces de especificacin del software y
el cual es igual al rea bajo la curva. ponerlos a disposicin del equipo de desarrollo.
Para ajustar mejor sus estimaciones Boehm creo tres escenarios de Otros factores caractersticos de los proyectos software en modo orgnico
estimacin clasificando su modelo de forma jerrquica y en base a la son la existencia de un entorno de desarrollo generalmente estable, con muy
complejidad y cantidad de informacin utilizada en la estimacin; a los que pocos desarrollos asociados a nuevo hardw'are y procedimientos operacionales
denomin modelos COCOMO que son: y con mnimas necesidades de innovaciones en la arquitectura del proceso de
datos y algoritmos. Adems existe un premio relativamente pequeo al
Modelo bsico completar ms pronto el proyecto y medidas de los proyectos relativamente
Modelo intermedio pequeas. Muy pocos proyectos en modo orgnico desarrollan productos con
Modelo avanzado ms de 50 KLDC de software nuevo. Estos factores contribuyen a la alta
productividad de estos proyectos.
El modelo bsico es un modelo esttico, evaluado de forma nica y que
calcula el esfuerzo y el coste de desarrollo del software en funcin del tamao El principal factor que distingue al modo empotrado es la necesidad de
del programa expresado en lneas de cdigo estimadas (DSI o LDC). operar dentro de una serie de restricciones. El producto debe operar dentro de
unas restricciones rgidas de hardware, software y procedimientos
El modelo intermedio calcula el esfuerzo de desarrollo en funcin del operacionales, tales como, por ejemplo, en un sistema de regulacin de trfico
tamao del programa y un conjunto de guas de coste que incluyen una areo. Debido a estas restricciones, los cambios posteriores que se tengan que
producir tienen un coste bastante grande. Generalmente, los proyectos en modo
140 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 9: EL MTODO DB COSTES 141
proyectos software. La tabla de la Figura 9.5 anterior resume la naturaleza de la La ventaja principal de estas bases de datos COCOMO es que todas las
base de datos COCOMO. entradas que se producen en ella son cuidadosa y consistentemente definidas
con respecto ai manejo de instrucciones fuentes deliberadas, estimaciones de
T am a o d e la m u e s tra P ro d u ctiv id ad (I.D C /M M J desarrollo, hombres-mes y otros datos parecidos.
B ase d e D a to s C o m p le ta 63 2 0 -1250 Una vez expuestas las lneas bsicas y generalidades del modelo de Boehm
para los tres tipos de modelos y, dentro de ellos, para cada uno de los modos de
M O D O : O rg n ic o 23 8 2 -1250 desarrollo podemos analizar las caractersticas particulares y las ecuaciones
S em i-ac o p la d o 12 4 1-583 utilizadas en las estimaciones.
E m potrado 28 2 0-667
L en g u a jes de
P rogram acin: 24 28-883 F igura 9.6 E cu a cio n es de esfuerzo y tiem p o en C O C O M O b sic o
FORTRA N 5 55-862
COBOL 5 45-583
JO V IA L 4 9 3 -1250
PL/I 2 336-5 6 0 El modelo bsico es bueno por su facilidad y rapidez para la estimacin a
P A SC A L i 124-300 groso modo de los costes del software objeto. Pero su exactitud est muy
O tro s H O L 20 20-667
E n sam b lad o r
limitada debido a que ignora factores como las diferencias en las restricciones
en el hardware, la calidad del personal, la experiencia del mismo y el uso de
F igura 9.5 N a tu r a le za dela B ase d e D a to s C O C O M O original tcnicas modernas, adems de otros atributos del proyecto objeto de estudio
que tendrn una influencia significativa en la estimacin del coste.
Como se puede observar la distribucin de proyectos en la base de datos Una vez estimado el esfuerzo y calendario de desarrollo de un producto
del ejemplo no es totalmente representativa de la variedad actual de proyectos desde el punto de vista del modelo bsico, pueden obtenerse otros datos sobre
software (p.e. no hay bastantes puntos de datos de proyectos en lenguaje CO el proyecto como pueden ser la productividad y el nmero de personal medio
BOL) o de los probablemente futuros proyectos software, no hay bastantes que trabaja a tiempo completo, al cual Boehm ha denominado FSP6. Los
puntos de datos de desarrollos para microprocesadores). Sin embargo, posee al valores pertenecientes a estos datos se muestran en la Tabla 9.8 en la que
menos algn punto representativo de todos los sectores principales del mundo aparecen los tres modos de desarrollo del COCOMO bsico para las distintas
del software. medidas estndares de productos.
352
Orgnico 400 376 219 327 N.C. E s f u e r z o to ta l ( M M ) ? 5.0 213 91 39 2
Seiniacoplado 308 258 139 186 158 P la n ific a c i n y re q u e rim ie n to s ! 0.3 1.3 ;.0 24
D is e o del p ro d u c to ; 0 ,8 3,4 15 63
( Empotrado 241 182 105 80
D is e o d e ta lla d o 1,3 5,3 22 90
C o d ific a c i n y p ru e b a unidad 2,1 8,5 34 141
(
C ALENDARIO (TDEV) In te g ra c i n y p ru e b a s ! 0 .8 4,1 20 98
(
C a l e n d a r l o t o t a l (m e s e s ) > 4 ,6 8,0 ,0 24
Orgnico 4,6 8.0 14,0 24,0 N.C.
P la n ific a c i n y re q u e rim ie n to s 1 0 V5 0,9 1,7 3,1
Semiacoplado 4,8 8,3 14.0 24,0 42,0 D is e o del p ro d u c to | 0 ,9 1,5 2 .7 4 ,6
Empotrado 4,9 8.4 14,0 24,0 41,0 P ro g ra m a ci n j 2 .9 4,7 7.7 12,2
s In te g ra c i n y p ru e b a \ 0.8 1.8 3 ,6 7,2
PERSONAL P e r s o u a l m e d io ( F S P ) j
MEDIO P la n ific a c i n y re q u e rim ie n to s j 0,< 1,4 2 ,9 8 ,0
(FSP) D is e o del p ro d u c to \ 0 ,9 2,3 5 .6 14
P ro g ra m a c i n 1 1.2 2 ,9 7,3 19
( I n te g ra c i n y p ru e b a { 1,0 2,3 5 .6 14
Orgnico 1.1 2,7 6.5 16.0 N.C.
Semiacoplado 1.4 3,7 10,0 29,0 77.0
( Empotrado 1.7 5,2 16,0 51,0 157,0 M E D I A D E L P R O Y E C T O (F S P ) 1 M 2.7 6.5 16
% d e m ed ia del p ro y e c to i
P la n ific a c i n y re q u e rim ie n to s \ 60 % 55% 50% 46%
D is e n o d el p ro d u c to - 84 84 84 84
Tabla 9.7: Detalle de las tabulacin de distintos proyectos COCOMO bsico P ro g ra m a ci n ! 108 110 113 116
In te g ra c i n y p ru e b a : 89 87 85 83
As, de la observacin se deduce que si se considera que se est D I S T R IB U C IO N D E L E S F U E R Z O TAM AO DEL PRO D U CTO
desarrollando un producto que es a veces ms grande que otro (p.e. 32 KDSI (K D S I )
MODO FA SES S Y M G E
frente 8 KDSI), la productividad en el producto de 32 KDSI ser del orden de 2 S 32 128 512
un 94% del valor de la productividad del producto de 8 KDSI. Este
O rg n ic o % P la n ific . y re q u e rim ie n to s 6 6 6 6
decrecimiento en la productividad para proyectos grandes se denomina, en D is e o d e l p ro d u c to 16 16 16 16
trminos econmicos, una deseconoma de escala. Las razones de esta P ro g ra m a c i n 68 65 62 59
In te g ra c i n y p ru e b a 16 19 22 25
disminucin, teniendo en cuenta que la productividad es igual a las lneas de
cdigo totales del proyecto dividido por el esfuerzo de desarrollo, son las S e m i-a c o p la d o % P la n ific . y re q u e rim ie n to s 7 ? 7 7 7
D is e o d el p ro d u c to 17 17 17 17 17
siguientes: P ro g ra m a c i n 64 61 58 55 52
In te g ra c i n y p ru e b a 19 22 25 28 31
Se requiere mayor esfuerzo en el diseo del producto para poder E m p o tra d o % P la n ific. y re q u e rim ie n to s 8 8 8 8 8
desarrollar un nivel de especificacin ms completo ya que se requieren D iserto de) p ro d u c to 18 1 18 18 18
P ro g ra m a c i n 60 57 54 51 48
actividades que desarrollan en paralelo por un nmero de In te g ra c i n y p iu e b a 22 25 25 31 34
programadores que es ms grande.
D IS T R IB U C IO N D E L C A L E N D A R IO KDSI
O rg n ic o % P la n ific . y re q u erim ien to s 10 11 12 13
Una consecuencia de lo anterior es que se necesitar mayor esfuerzo D is e o d el p ro d u c to 19 19 19 19
P ro g ra m a c i n 63 59 55 51
para verificar y validar los requerimientos y especificaciones de diseo. In te g r a c i n y p ru e b a 18 22 26 30
Las pruebas para la validacin y verificacin del producto software son Tabla 9.9 Distribucin p o r fa ses del esfuerzo y del calendario
ms extensas.
Cualquiera de las tablas descritas anteriormente pueden utilizarse
Y como ltimo dato, el que se produzca esta disminucin de la directamente para calcular la distribucin de los valores del esfuerzo y
productividad, se debe a que en proyectos grandes se produce un calendario para los tres modos de desarrollo, para cada una de las fases que los
aumento en el esfuerzo requerido para la organizacin del proyecto. componen y para diferentes tamaos. Hay que tener en cuenta que el
porcentaje de distribucin para productos de medidas no tabulados se obtiene
por interpolacin en dicha tabla.
Por ello, la ecuacin COCOMO para estimar el esfuerzo de mantenimiento Como se puede observar segn el modo de desarrollo del producto que se
anual bsico (MM)am viene dada en funcin del esfuerzo de desarrollo considere se obtiene una distribucin distinta de las actividades en las
estimado: diferentes fases para el modo empotrado, modo semiacoplado o modo
orgnico. Para explicar la tabla 9.10 nos centraremos en la columna ms a la
{ M M) a m = K x ( AC T) x {MM) d izquierda, la cual informa que en un proyecto de 2 KDSI, el 8% del esfuerzo
total se necesitara para completar la fase de planificacin y requerimientos, el
50% (o el 4% del proyecto total) se necesitara para desempear la tarea o
El coeficiente de correccin K suele emplearse un valor prximo a la
actividad del anlisis de requerimientos, estando sta compuesta por: anlisis
unidad.
del sistema existente, determinacin de necesidades de usuario, integracin,
documentacin, etc. Otro 12% del 8% total (o el 1% del proyecto total) se
utilizara para ejecutar las tareas de diseo del producto durante la fase de
150 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 F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S
planificacin y requerimientos como puede ser: la investigacin de la Diseo del producto =31FSP
arquitectura bsica del producto hardware-software, etc. Y as, se irn Programacin = 10FSP
deduciendo tareas en cada una de las actividades que forman parte de esta fase Planificacin de las pruebas = 6FSP
de planificacin y requerimientos. En la siguiente columna de la tabla se Verificacin y validacin = 7 FSP
observa que la distribucin de actividades es distinta para un proyecto Trabajos de oficina = 5FSP
intermedio de 8 KDSI que para el pequeo de 2 KDSI, teniendo el resto de la
Control de calidad = 2FSP
tabla una interpretacin similar.
Desarrollo de manuales = 5FSP
Utilizando la columna a la derecha de la columna de diseo del Otra de las limitaciones del modelo COCOMO bsico es la estimacin del
producto, se observa que un 10% de las 74 personas realizan personal medio en cada fase. Existen discontinuidades en los niveles de
funciones de anlisis de requerimientos, el 42% de las 74 personas personal en los lmites entre las fases, que siguiendo el modelo deberan ser
realizan funciones de diseo, etc. Si estos datos se expresan en planas y mantenerse constantes. Un ejemplo de estas discontinuidades se puede
funcin del nmero de personas que se encuentran realizando cada observar en la actividad de programacin durante la fase de integracin y
una de las actividades, se obtendr: prueba (Tabla 9.8), en la que al comienzo de la misma existe una gran cantidad
de personal desarrollando tareas de integracin, mientras que al final de la fase
Anlisis de requerimientos = 7FSP________ __________ _ este nmero disminuye considerablemente.
152 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 F O R M T IC O S C A P T U L O ): EL M T O D O D E C O S T E S 153
Sin embargo, la principal limitacin de COCOMO bsico es que no Hay muchos factores candidatos a considerar en el desarrollo de un mejor
incorpora los efectos de algunos modificadores de coste del software, tales modelo para la estimacin de costes de un proyecto software y que constituyen
como: restricciones del hardware, factores que afectan al personal, atributos los denominados "Multiplicadores de esfuerzo en el modelo COCOMO
ambientales, etc., los cuales sern incorporados en el modelo COCOMO intermedio. Los pioneros en el estudio de este tipo de multiplicadores fueron
intermedio donde el esfuerzo se mide en funcin del tamao del programa y a tcnicos de System Development Corporation que consideraron a mitad de
un conjunto de "guas de coste logrndose un sistema bastante mas fino que aos sesenta que haba ciento cuatro factores diferentes, todos ellos
el anterior pero su complejidad puede hacer que no sea necesario emplearlo si encaminados a determinar el coste de desarrollo del software. Consideraron
no se necesita una estimacin mas fiable. factores tales como: tipo de aplicacin, nmero de tipos de entradas y salidas,
porcentaje de entradas y salidas, instrucciones matemticas o de control en el
Las ecuaciones de estimacin en un modelo COCOMO intermedio se programa, experiencia media de analistas y programadores, configuracin del
muestran en la Tabla 9.10. ordenador, uso del lenguaje de programacin, etc. Estudios posteriores, tales
como los de Walston-Felix en 1977, encontraron factores adicionales que
tambin influan en el coste del software, tales como: la complejidad del flujo
MODO ESFUERZO CALENDARIO del programa, la presencia de restricciones en la seguridad, el uso de tcnicas
de programacin estructurada, inspecciones, desarrollo top-down, y otros. Para
Orgnico MM= 3.2 (KDSI)1'05 TDEV= 2,5(MM)"JS
reducir este gran nmero de factores a un nmero manejable que se pueda usar
Semi-acoplado MM= 3.0 (KDSI)1 12 TDEV= 2,5 (M M )1135 en una estimacin de costes de desarrollo de software prctica, se someten los
factores a dos criterios de seleccin:
Empotrado MM= 2.8 (KDSI)1'20 TDEV= 2,5 (MM),JJ
Relevancia general, en este caso se eliminan los factores que
T a b la 9.10 E cu a cio n es de esfuerzo y tiem po en C O C O M O interm edio tienen relevancia solamente en relativamente pequeas porciones
de situaciones especficas.
Independencia, en este caso se eliminan los factores que estn
Una estimacin del esfuerzo de desarrollo del software en el modelo
fuertemente relacionados con la medida del producto y al mismo
COCOMO intermedio comienza por generar una estimacin del esfuerzo
tiempo se tiende a englobar en factores simples a aquellos que
nominal, usando para ello ecuaciones de escala de los distintos modos como se
produzcan un efecto similar para las estimaciones, como ocurre
realizaba en el COCOMO bsico. Esta estimacin nominal est entonces
en el caso del uso de la programacin estructurada, inspecciones
preparada para aplicar un multiplicador del esfuerzo determinado por la clase
que se produzcan, y factores parecidos, los cuales se engloban en
de proyecto que se est considerando con respecto a los quince modificadores
uno simple que se denomina: uso de prcticas modernas de
de coste.
programacin.
En la Tabla 9.10 se representan las ecuaciones del esfuerzo nominal y el
Como resultado de aplicar dichos criterios se obtuvieron 15 factores o
calendario de desarrollo estimados para el COCOMO intermedio en los tres
atributos modificadores del coste que son los usados en el modelo COCOMO
modos de desarrollo considerados. En estas ecuaciones se observa que la escala
intermedio y se agrupan dentro de cuatro categoras, las cuales define Boehm
de factores (exponentes) para el modelo intermedio y para los tres modos de
como:
desarrollo son los mismos que para el modelo bsico, pero los coeficientes son
distintos. Esta diferencia se justifica en base a que se considera que el efecto
Atributos del producto software
que produce el multiplicador del esfuerzo no es el mismo para los tres modos
de desarrollo. Si se hubieran utilizado los mismos coeficientes del modelo Atributos del ordenador
bsico, los valores obtenidos para el esfuerzo estimado en el modo empotrado Atributos del personal
hubieran sido demasiado altos, mientras que en el modo orgnico hubieran sido Atributos del proyecto.
demasiado bajos.
154 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 F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 155
Ejemplo 1. Estimacin de recursos de una pequea aplicacin 4. Se realizan los clculos de esfuerzo nominal.
utilizando el COCOMO intermedio:
MM = 3,2 x 1,527I,0S = 5 personas/mes
1. Se analiza el entorno de desarrollo.
Se elige el modo orgnico debido a: Aplicando el factor:
Entorno de desarrollo estable
Mnimas necesidades de introducir algoritmos MM = 1,08 x 5 = 5,4 personas/mes
innovadores
Tamao del proyecto pequeo 5. Se calcula el tiempo estimado.
Programacin 2,5 p.
Aplicando el factor:
Integracin y pruebas 2p.
Por fases:
Planif. y requerimien. 0,10 x 7,22 = 0,72 meses
Diseo 0,19 x 7,22 = 1,37 meses
Programacin 0,63 x 7,22 = 4,55 meses
Integracin y prueba 0,18 x 7,22 = 1,3 meses
160 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 F O R M T IC O S C A P T U L O 9: E L M T O D O D E C O S T E S 161
El modelo detallado resuelve este problema proporcionando tres jerarquas K=L3 / (Ck3* h f)
de niveles del producto, siendo stas:
Nivel de subsistema, se consideran los efectos que varan menos Una vez estudiados los distintos modelos empricos de estimacin de costos
frecuentemente; es decir, varan de la misma manera para todos los vamos a sealar como est el estado del arte en la implementacin en
mdulos que componen un subsistema. programas de usuario:
-<g|>
REPORT COMPONENT ESTIMATE OflTRBflSE ULE ESOCancel data entry Kl .^-Hel
Est imate/ID:NoName Standard Component/IO:NoName
Database/ID:C0C0M0_87 1.00 Process Model Component of:
-Personnel- -Computer- -User Defined- -Model-
flCRP: nominal T IME:* noninal USR1:undefined Oetailed Model
flEHP: nominal S TOR: noninal USR2:undefined
PCflP: nominal T URN: nominal USR3:undefined -Mode-
VEKP: nominal V HVH: nominal Organic
LEKP:* nominal V MVT: nominal -Cost/SN-
RQCOST:* * 0
Product- -Project- PDCOST:* $ 0 -Maintenance-
:* nominal HODP: nominal DDCOST: $ 0 PRCT :* 0/.
: nominal TOOL: nominal CTCOST:* $ 0
: nominal SCED: nominal ITCOST:* $ 0 -Size-
: nominal SECU:* nominal HNCOST:* $ 0 DSI: 2000
-------- Development Summary (PD*DD+CT+IT) ---- Current ----
Duration (Months) 5.1 Total DSI DSI 2000
Productivity (DSI/SM) 301.9 Total Staff-Months S-Months 6.6
Unit Cost ($/DSI) 0.00 Total Cost (K$) Cost 0.0
--------------------------------- Costar Demo ---
IIIOME=comand line F i l l in nn 11) for the Current CoNDonentl
1 i Iin i l l 111
jjg...I
v. V
.|@1... Hait.
f
.
,
llK B A s ' ^ i*
.
|i XI %
Figura 9.14 Aspecto del program a CO STAR para MS-DOS. Figura 9.15 Aspecto de Costar II
Algunos avances sobre el modelo se pueden ver aplicados en el programa Otro producto interesante es el SL1M, basado en el modelo de Putnam que
COSTAR II, que es una ampliacin del programa anterior que soporta una permite obtener unos estudios de programacin lineal, la simulacin estadstica
mayor cantidad de modelos de estimacin, incluido el modelo C-OCOMO II, y los diagramas PERT en el mismo paquete.
Para facilitar la planificacin del proyecto, en esta versin del programa,
Costar II facialita el supuesto de anlisis de la forma qu pasara si? Adems Muchas instituciones y casa comerciales tienen herramientas en la red,
de comparar distintos planes de proyectos. La riqueza de informes y grficos alguna de ellas accesible va w'eb, como puede ser el caso de la NASA, vase la
hacen que Costar II sea, actualmente, la estrella de los programas de referencia httn://www.isc.nasa.aov/bu2/COCQMO.htinl. que presenta el
estimacin de esfuerzos. aspecto de la figura 9.16.
La versin de evaluacin permite estimar proyectos de hasta 5000 lneas Todos estos productos, hoy da disponibles en computadoras personales,
de cdigo fuente y permite efectuar supuestos sobre la duracin partiendo de permiten calibrar el entorno local de desarrollo y crear un modelo de
personal dedicado al proyecto y su inversa, es decir, qu personal se debe de informacin del software desarrollado mediante sus caractersticas bsicas, los
dedicar en cada una de las fases de desarrollo para satisfacer un calendario atributos de personal y las consideraciones del entorno.
previsto segn unas especificaciones dadas.
Si en su organizacin no se dispone de software de estimacin de
En la versin evaluada (6.0) se ofrecen numerosas posibilidades de proyectos, se pueden buscar sitios de la red que disponga de software que
intercambiar la informacin con otros programas de Windows, pudindose est ms o menos calibrado a nuestro entorno de desarrollo y a los usos y
obtener informacin grfica para insertar o adjuntar dentro de herramientas costumbres del grupo de trabajo concertadas en forma de metodologas.
ofimticas como puede ser Microsoft Word.
166 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 9: EL MTODO DE COSTES 167
BTIIBBHIHWff -IOI x|
i i Arthvo E<<Ko v?r FavpR'tt Ayu*fa
..............o El modelo de Barry W. Boehm proporciona una base firme para
4-Atjis * * IPavCTito* 9 h ^ * id
>1 ^>lf <J jviftijos >J; desarrollar una estimacin de costes en un sistema software, debido a su
'tflgicwtis Use ityourownri<L- Tlitietool*rewitteniu JiviSciipla x / i * i t o v r $ t with -iJ adaptabilidad a los distintos sistemas, a su fcil aplicacin y a la consideracin
;)a-s&<ViiI It'vou hve lioubl viewinc fu asme llt't*- iri-tnsiih the rWii.Oillv
fiiSitl.fJSAim.- ! por parte del modelo de la influencia de los factores ms importantes del
desarrollo de software.
Inputs
, Development j.
Aunque existen otros modelos de estimacin de costes, como el modelo
I>cbvered Source Instructions (thousands) (KDSI) -jl :i . J SLIM de Putnam, el modelo SDC (System Developmenf Corporation) de
'Developmfot Mode j Organic * : . p Nelson, etc., se ha desarrollado el estudio ms profundo del modelo COCOMO
Average- Cost Rate (tPM) yioooo debido a que es uno de los ms completos de los existentes, adems de uno de
Maintenance
los ms utilizados por las organizaciones para la estimacin de costes en la
jFJDSI added (annual) P ............. 1
produccin de grandes sistemas informticos.
IKDSI modified (annual) I |
Average Cost Rate ||OIXIO |
Reco'c | = ; ! - - . .
:
i1 ................ 5 i .r 1
?*] r ; $ ItferiHt
i*w cioj & j IfcpcspSd: ...||4r]CoMo... B jiX J **
CAPTULO 10
O ------5------- <D Se pueden crear actividades ficticias para solucionar algn tipo de
problema que pueda generarse considerando que este tipo de actividades
Figura 10.1 Representacin de actividades y sucesos ficticias no consumen ni tiempo, ni recursos; este sera el caso del ejemplo de
la Figura 10.4 donde la tarea F puede comenzar una vez finalizadas las tareas
Todas las actividades se deben de representar en el modelo que formar la A, B y C pudiendo comenzar las tareas D y E cuando hayan terminado las
red de actividades y sucesos considerando los siguientes puntos: tareas A y B.
Con todo ello se pueden crear un sistema que se debe enumerar mediante El algoritmo puede resultar algo complejo pero se aclara bastante su
el empleo de nmeros naturales para los sucesos con una numeracin comprensin con la ayuda de un ejemplo ilustrativo, por ello vamos a
ascendente de izquierda a derecha. La forma de leer el grafo es: A precede a B , considerar la matriz de encadenamiento de la Tabla 10.8 de la cual vamos a
a C y a D; B, C. y D preceden a E. Pero cuando el proyecto es muy numeroso se obtener su grafo asociado: (
recurre a su representacin mediante una tabla de precedencias, en nuestro
caso: (
<
Actividad Actividades Precedentes (
A <
B A
<
C A
D A
E B, C y D
Figura 10.7 Tabla de relacin de precedencia
1 El algoritmo de Denicucron nos facilita el nmero de niveles del grafo y qu sucesos se en- : '
cuentran en cada nivel siendo responsabilidad del jefe de proyecto representar el alcance de las (
actividades mediante las flechas correspondientes. / <
176 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 F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 177
Actividad siguiente
1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1* 2* 3* 4* 5* 6* 7* 8* (.)*
1 [o r 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 / 1 1 1 I I 1 I 0
2 0 0 1 0 0 1 0 0 0 0 2 2 2 2 2 1 I 0 X
2 0 0 1 0 0 1 ___
0 0 0 0
3 0 0 0 1 0 0 0 0 0 0 I i 1 1 0 X X X X
3 |o "0 *o' 1 0 0 0 0 o 4 0 0 0 0 1 0 0 0 0 0 1 i 1 0 X X X X X
4 0 0 0 0 1 0 0 0 0 0 5 0 0 0 0 0 0
0 0 1 0 1 i 0 X X X X X X
5 (* 'o 0 0 0 0 0 0 ~f 0 6 0 0 0 0 0 1
0 0 0 0 ! i 1 1 1 i 0 X X
6 0 0 0 0 0 0 1 0 0 0 7 0 0 0 0 0 0 0 1 0 0 1 i I 1 1 0 X X X
7 fo 0 0 0 0 0 0 1 0 0 8 0 0 0 1 0 0 0 0 1 0 2 2 1 1 0 X X X X
9 0 0 0 0 0 0 0 0 0 1 1 0 X X X X X X X
8 0 0 0 1 0 0 0 0 1 0
T ~ 10 0 0 0 0 0 0 0 0 0 0 0 X X X X X X X X
9 jo 'o ~0 "o" " 0 0 0 suceso 10 9 5 4 3.S 7 6 2 1
T a b la 10.8 M a triz d e e n c a d e n a m ie n to nivel IX VIII V il VI V IV III II I
Vamos a aplicar el algoritmo de Demeucron para lo cual ampliaremos la matriz El grafo asociado ser:
de encadenamiento en varias columnas nuevas al final de la tabla que
4 5
denominaremos 1*, 2*, 3*, hasta un mximo de 10*, nmero de columna que
en el caso ms desfavorable posible tendremos que utilizar.
actividades con el mnimo coste por unidad de tiempo c(i, j) , reduciendo esta
actividad hasta que alcance su lmite tope de duracin o hasta que aparezca 10.4 El PERT Y EL CPM.
otro camino crtico. As paso a paso hasta llegar a un camino crtico en la que
todas las actividades tengan una duracin tope. Como se habr desprendido de la lectura de los apartados anteriores estamos
partiendo de unos datos exactos en el sentido de que suponemos conocer con
En el caso del ejemplo se alcanzar el tiempo tope reduciendo, en primer total certeza en la que cada tarea finalizar. Esto en los proyectos reales no es
lugar, la duracin de alguna de las actividades B, C, D o /, de ellas reducir la as sino que tendremos que basar nuestra estimacin en una serie de
que me resulte menos costosa, en nuestro caso la /; con esto he acortado la suposiciones que, en algunos casos, podremos basar en datos estadsticos. El
duracin del proyecto en media jornada a cambio de pagar cinco unidades anlisis de redes de tiempos basadas en el sistema PERT necesita disponer de
monetarias. El camino crtico sigue siendo el mismo y, como no puedo reducir datos adicionales para efectuar su clculo basado en la duracin de cada
ms la actividad I, la decisin estar en recudir alguna de las actividades B, C o actividad en cuanto a tres fechas:
D; en nuestro caso elijo la D por ser la ms econmica, con ello llevo una
reduccin de jornada y media a un precio de 20 unidades monetarias. La Fecha ms probable
siguiente eleccin sera reducir B en dos jornadas a cambio de pagar 50 Fecha ms optimista
unidades con lo que la reduccin total del plazo es de tres jomadas y media. Fecha ms pesimista
Finalmente, por el momento, reduzco C que es la actividad ms cara en media
jornada, con lo que el proyecto se ha rebajado, en duracin, en cuatro das Se entiende por fech a ms probable (ni) aquella cuya ejecucin en el
teniendo dos caminos crticos. tiempo es la normal y cuya estimacin est basada en la repeticin continua de
actividades similares en las mismas condiciones de trabajo.
A continuacin podemos rebajar la actividad J e n media jornada por ser la
ms econmica con lo que la reduccin es de cuatro jornadas y media La fe c h a ms optimista (a) sera aquella en la que la duracin de la tarea se
continuando con dos caminos crticos. An se puede reducir C en media realizara si todo marcha en condiciones ptimas, es decir, sino se produce
jornada con lo que tendr que reducir media de E con un coste de 10 con lo que ningn tipo de improviso que pueda retrasar la tarea.
el proyecto ha quedado de la siguiente forma:
La fe c h a ms pesim ista (b) sera la duracin de aquella actividad que se
Actividad Duracin Coste extra realiza en contra de todo tipo de circunstancias normales que puedan suceder5.
A 1 0
B 2 50
C 2 30 Una vez que se hayan facilitado estas tres fechas obtendremos la
D 1 15 estimacin de la inedia de la actividad como:
E 2 0 ^ a + 4m + b
F 1 0
G 1 0
I) 1 0
I 0,5 5 La funcin de distribucin de la duracin de las tareas suele estimarse
J 0,5 10
TOTAL 7,5 110 mediante la funcin Beta, cuya distribucin de la variable aleatoria t
comprendida en el intervalo [a, b] es
Tabla 10.14 Tabla de actividades con costes extra y duracin optimizada
5 Se deben desestimar condiciones muy extremas que pueden hacer que la duracin de una
tarca sea infinita.
184 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 F O R M T IC O S C A P IT U L O 10: P L A N IF IC A C I N D E L T IE M P O 185
/ ( / ) = 0 ,/ < a
C -C
c ( i j ) = -------------T
------.
A0 = - D(,j)-d(i,j)
( b - a ) a***'p(a + U<p + l)
f(t) = 0,b<t
(p = 2 - 4
O se elige
a =2~4l
(p = 2 +
en otro caso. Figura 10.15 Relacin normal entre la duracin y el coste directo de una actividad
El valor de la varianza viene expresado por la frmula: Con esta nueva variable CPM estudia el proyecto tanto desde el punto de
vista de duracin ptima como de coste mnimo. El procedimiento para la
programacin con CPM consiste en partir de lo que se considera todo normal
en programacin temporal con lo que, despus de los ajustes iniciales, el coste
total suele ser mnimo y la duracin la ms larga.
Es importante resaltar que el valor ms probable ni, en la funcin de
distribucin Beta no se corresponde con el valor de la mediana, que
normalmente quedar a la izquierda de la fecha ms probable, por la asimetra Ejemplo 1
de dicha funcin de distribucin.
Representar de forma grfica, mediante el mtodo PERT, la siguiente tabla de*
Una vez obtenidos los valores Z), el mtodo PERT reduce el caso relacin entre actividades:
probabilstico a determinstico por el hecho de utilizar la media de las Actividad Actividad
Actividad
duraciones de todas las tareas como media del proyecto con la consiguiente Precedente Siguiente
simplificacin matemtica del problema al que se le puede aplicar la teora A CJO
mostrada en el apartado anterior. B - E,FtG
C A E
D A E,F
La programacin por CPM introduce la variable de costes que pueden
E B,CJD H
sufrir modificaciones por su alargamiento o acortamiento segn ciertas F BJD H
funciones de distribucin. De esta forma a una duracin tope de cada tarea del G B I
proyecto d (ij) se le asigna un coste tope CY, a una duracin normal, D (ij),iin H E,F I
coste normal Cv y a una duracin mnima un coste mnimo. El valor de los I H,G -
costes entre los tiempos normal y tope se suele calcular por interpolacin lineal
entre ambos extremos, as el incremento de coste
186 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 F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N D E L T IE M P O 187
La duracin de cada actividad la proporciona la tabla: En un nodo intermedio es el mnimo de los valores calculados para cada uno de
sus nodos antecesores. El valor calculado para cada uno es su fecha ms tarda
Actividad Optimo Psim o P robable Calculado menos el tiempo de la actividad que los conecta.
A 2 2 2 2
B 4 16 7 8 -Por ltimo la holgura.
1 9 2 3
En cada nodo es la diferencia entre la fecha ms tarda y la ms temprana.
C
D 1 10 4 4
D eterminar el camino crtico:
E 7 15 9 10
F 2 14 8 8 El camino crtico es el que determina la duracin del proyecto y esta formado
G 4 18 8 9 por el conjunto de nodos que determinan el camino ms largo.
H 2 3 2 2 Estos nodos tienen como caracterstica que su holgura total es cero y se les
I 6 10 9 8 llamaran sucesos crticos.
Vamos a tener en cuenta las normas de representacin siguientes: Obtencin del grajo:
Representacin de un nodo:
Clculo de los tiempos de los nodos: Para obtener las ocurrencias ms lejanas y ms tempranas hemos tenido que
aplicar el clculo de valores mnimos y mximos. Por ejemplo la ocurrencia
-Primero calcular las fechas ms tempranas. ms temprana del suceso 5 se calcula como el mximo de 9 (ocurrencia ms
En el nodo inicial es 1. temprana del suceso 3 + tiempo de la actividad F l) y 7 (ocurrencia ms
En un nodo intermedio es el mximo de los valores calculados para cada uno temprana del suceso 2 + tiempo de la actividad D). Otro ejemplo, la ocurrencia
de sus nodos predecesores. El valor calculado para cada uno es su fecha ms ms tarda del suceso 2 se calcula como el mnimo de 6 (ocurrencia ms tarda
temprana ms el tiempo de la actividad que los conecta. del suceso 4 - tiempo de la actividad C) y 5 (ocurrencia ms tarda del suceso 5
- tiempo de la actividad D).
-Despus calcular las fechas ms tardas.
En el nodo final es la misma que la ms temprana.__________________________ Camino crtico:
Cam ino 1 A D I J
D
Cam ino 2 B C E I J
C am ino 3 B C G H J
C am ino 4 B F H J
C am ino 1 1 0 0 1 0 0 0 0 1 1 60
Se construye una tabla donde se muestran cada una de las actividades del 10+15+10+25 = 60
proyecto. Existir en cada fila una columna de cabecera y el resto de datos. 50+20+5+10+25 = 110
A continuacin, en la fila siguiente, la palabra Duracin y la duracin de 50+20+40+30+25 = 165
cada actividad. 50+20+30+25 = 125
En las tres filas siguientes de la tabla, se definen el Nodo Inicial (el nodo de
comienzo de cada actividad) y el Nodo Final (el nodo de terminacin de cada El camino crtico es el tercero y est formado por las actividades: B, C, G, H y
actividad). _____________________________________________ J.
(
190 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 F O R M T IC O S C A P T U L O 10 P L A N IF IC A C I N D E L T IE M P O 191 f
Veamos un diagrama que nos muestra la construccin de un arco: Supongamos que podemos disminuir ciertas actividades en un periodo de
tiempo con un coste adicional, como muestra la tabla:
Coste
ACTIVIDAD Das
F.Ytffl
A: Lugar de emplazamiento 1
B: Hoyo cimientos B 4 2 40
C: Cimientos hormign B 3 2 20
D: Colocar plinto 2 1 10
E: Hoyo cimientos A 2 1 20
F: Cimiento hormign A
G: Preparar ton e A
H: Colocar tone A 1/2 10
Tenemos una tabla con sus actividades y duracin: I: Colocar torre B 1/2 10
Di as
J: Colocar el arco 1/2 10
ACTIVIDAD
A: Lugar de emplazamiento i
B: Hoyo cimientos B 4
C: Cimientos hormign B 3 Aplicando estas disminuciones de tiempo conseguimos un ahorro de 5 das,
D: Colocar plinto 2 realizndose el proyecto en 8 das, con un coste adicional de 120. Podemos
E: Hoyo cimientos A 2 verlo en la siguiente representacin:
F: Cimiento hormign A 1
G: Preparar torre A 1
H: Colocar torre A 1
I: Colocar torre B 1
J: Colocar el arco 1
En este caso hemos ahorrado tiempo fuera del camino crtico aumentando el
coste, a veces, esto no compensa. En este ejemplo la actividad I puede tardar
192 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 F O R M T IC O S C A P T U L O 10: P L A N IF IC A C I N 13l.il.T IE M P O 193
un da o medio, es indiferente, ya que en el nodo 9 el valor temporal ser 6,5 o A 6.-Estudio de ofertas y adjudicacin concurso (10 das).
7, segn el caso, siempre menor que 7,5 que es el tiempo por el camino crtico. A7.-Estudio de viabilidad (30 das).
Lo mismo ocurre con la actividad E que puede tardar uno o dos das, valores A 8 .-Formacin del personal (60 das).
que en el nodo 4 son indiferentes ya que el tiempo del camino crtico es 6 . A9.-Instalacin del equipo (5 das).
A 10.-Plazo de entrega del equipo seleccionado (40 das).
Obtenemos el siguiente grfico optimizado, en el que, sin cambiar el camino A l 1.-Preparacin cuaderno de especificaciones de H/S (10 das).
crtico disminuimos el tiempo total 5 das (tiempo del proyecto 8 das) con un A12.-Preparacin de la infraestructura necesaria para albergar el C.P.D.
coste de 90. (68 das).
A13.-Preparacin del Manual de Produccin (8 das).
A14.-Preparacin del Manual de Usuario (6 das).
A15.-Pruebas globales (10 das).
A16.-Seleccin de personal (10 das).
Ejemplo 4
A H
^ T
Figura 10.18 Demora en una relacin Comienzo-Comienzo o - ^ o
En esta figura la actividad B no puede comenzar hasta que pasen D
unidades de tiempo despus de empezar la actividad A, es decir, la actividad A
Figura 10.19 Representacin de las mismas relaciones entre actividades segn
debe comenzar D unidades de tiempo antes que la actividad B.
PERT/CPM y Roy
La figura 10.19 muestra algunos ejemplos de cmo se representan las
En un grafo del mtodo Roy para obtener los tiempos mnimos y mximos
mismas relaciones de precedencia entre actividades segn los mtodos
de com ienzo, la holgura y el camino crtico, seguimos bsicamente los mismos
PERT/CPM y Roy.
pasos que en el PERT/CPM:
t(J)<t(j)-t() [10.4]
(0) = 0, t(n) = / [10.5]
donde t (j) y t(i) son los tiempos lo ms pronto posible de terminar y comenzar
para el suceso (i, j) de una actividad determinada; t(n) es el tiempo lo mas
200 PLANIFICACIN Y GESTIN D E SISTEM A S INFORMTICOS CAPTULO 10: PLANIFICACIN DEL TIEMPO 201
pronto posible de terminar el ltimo suceso de la red con un proyecto de n+I y as nuestro problema se limita a resolver la programacin lineal
sucesos, como (())-() el tiempo en el ltimo suceso es / paramtrica. Para ello, en primer lugar generalizamos el problema a solucionar:
Se trata de encontrar el mximo de
La dificultad est en cmo encontrar un conjunto de t(ij) de la red con el
m axZ = a0lX , + tf02A \ + ... + c/0A'
coste directo total mnimo, para cada posible valor de /
donde
Vamos a replantear el problema en forma de programacin lineal
aliX ] + al2X 2+... + a]uX <ai0
paramtrica:
Partimos de unas condiciones fijas: Ct2^ \ j + Ojj X j + --- + OyltX tf C2Q
complementaria:
m a x^ciiJX iJ)
con las restricciones siguientes:
t ( i j ) +l ( i ) - t ( j ) < 0
-/(O ) + / ( ) < /
-l(iJ)< -d(J)
202 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 F O R M T IC O S C A P T U L O 10 P L A N IF IC A C I N D E L T IE M P O 203
YM+,l >
""0 1, r I-,2 >
0 ,... 1Y,,4,
> 0V
X+i = ,o + 'Y ja l, x ,
/=!
Con esto la funcin a maximizar se convierte en: Restando las variables complementarias Y, Y2>... Y n los primeros trminos
de cada inecuacin, quedan convertidas en ecuaciones:
+ 21^ll+2 + + ml^Ji+M ~ Y = 01
j=i
- y , - r 2 - y
- f j
00 0. 02 0 0
con sus condiciones restrictivas: j = Z o
K . i 10 u 12 % 1
a uKnl + 2 . ^ 2 + - + S 01 20 21 22 2 .,
y 2 J = * , . 2
n * ,o ,1 '2 J , = X n+l
a \nY+l +Cl2nY,,+2 + + a m,X,*m ^ 0
Y m a i i , , /,, = X+m
que puede sim plificarse como:
m f r e x , * 2 ^ 7 x .
w = con J = L2 ,...,h
7=1
Como puede apreciarse la dificultad del mtodo hace que para estimaciones
prcticas sea necesario el empleo de herramientas informticas de ayuda al
clculo de las redes CPM.
CAPTULO 11
PROGRAMACIN DE RECURSOS
organizacin productora, 110 queremos contrariar a nuestro cliente. En muchas detalle en que se deben de definir las tareas y el tiempo empleado en tal
ocasiones se subestima el proyecto porque inicialmente parece apetitoso por la definicin. En cuanto a garantizar la disponibilidad del recurso es importante
cantidad de dinero que se puede obtener del mismo sin efectuar ms conocer las responsabilidades relativas a la realizacin del trabajo en el sentido
investigacin sobre las posibilidades del mismo que el beneficio generado de poder obtener respuesta a la exigencia en caso de no haberse desarrollado el
directamente para cada uno de los participantes. Muchas veces sucede que un trabajo que, a su vez, por regla general, es que los recursos no estaban en el
proyecto comienza con una estimacin realista, tanto en plazos, costos y momento en que se necesitan. Todo ello nos hace preguntamos por tres
objetivos, pero se ve afectada por unos cambios que se van sumando a las cuestiones: Tipo de recursos a emplear, su calendario de utilizacin y la forma
prestaciones totales del sistema y que no permiten que se efecte una nueva de conseguir esos recursos con garantas.
planificacin porque, alguien, los considera de poca importancia. En otros
casos es el propio equipo del proyecto que valora errneamente el proyecto En cuanto al tipo de recursos que necesitamos podemos considerar dos
bien por falta de experiencia o bien porque desea obtener una contraprestacin tipos de recursos: recursos materiales y recursos humanos o de trabajo. Los
adicional. recursos materiales estn formados por todo aquello que supone una
infraestructura fsica para poder desarrollar el proyecto; es decir, las mquinas,
Con todo esto, a partir de una planificacin muy optimista, que no realista, lneas de comunicaciones, entornos software, consumibles, documentacin y
obtendremos una serie de consecuencias que se manifestarn si se quiere seguir todo aquello que se estime necesario para lograr el objetivo del proyecto con
esa planificacin: En primer lugar deberemos de citar que el primer sistema exclusin de las personas. Los recursos humanos (o de trabajo) son las
resentido de esta excesiva planificacin optimista es la calidad del propio personas que controlan las mquinas y desarrollan las labores de trabajo
producto y su propia planificacin. El hecho de tener unos hitos errneos har humanas necesarias, y que complementan a los recursos materiales, en la
que las revisiones y controles formales no se efecten a tiempo con el realizacin del proyecto.
consiguiente retraso y las posibles vistas gordas en tales procesos con tal de
garantizar el cumplimiento del tiempo. Esta falta de control en las etapas E 11 principio tenemos creada la lista de objetivos del proyecto y tambin
tempranas del desarrollo para tratar de ajustarse a esos tiempos de finalizacin las tareas que deben de cumplirse, junto a sus relaciones de dependencia, para
de tareas hace que en las pruebas finales se pierda mucho ms tiempo que el poder satisfacer el proyecto. Ahora tenemos que buscar los mejores recursos
que se hubiera perdido en la prueba de cada mdulo, su integracin y la para satisfacer cada una de las tareas. Tendremos que responder preguntas
adaptacin al usuario aunque nicamente sea en retocar los manuales de como disponemos del personal adecuado para realizar cada una de las
usuario1. Los retrasos que se producen por el hecho de tratar de apretar en la tareas?Tendremos que subcontratar tales actividades?Podemos emplear a
planificacin pueden llegar a ser tan importantes como el ciento por ciento del personas polivalentes que puedan realizar fases de trabajo distintas?Es
tiempo2 y hasta tres veces en el coste del producto. necesario adquirir licencias del entorno de desarrollo concreto?Es necesario
reservar tiempos de mquina en explotacin para realizar las pruebas?Puede el
La fuente de los problemas est en que los recursos necesarios para departamento cliente formar parte de las pruebas durante los das que el
realizar el trabajo no siempre estn disponibles y, en muchos casos, no estn calendario nos indique?Cul es el calendario de trabajo la empresa y hasta
debidamente controlados. Por ello, antes de asignar los recursos a las tareas dnde se pueden exigir el cumplimiento de horas extraordinarias si ello fuese
debemos efectuar una serie de preguntas relativas al grado de importancia de necesario?Se ha previsto que nuestro proyecto puede necesitar recursos que
efectuar un control y garantizar su disponibilidad. Efectuar el control otro proyecto de mayor importancia absorba en contra nuestra?Se ha previsto
exhaustivo puede ser interesante en algunos desarrollos en los que los recursos la cantidad de consumibles necesarios para el proyecto? Y una larga lista de
deben de estar fuertemente utilizados y no se pueden permitir tiempos perdidos preguntas que la experiencia e intuicin del director de proyecto deber de
en la entrega del trabajo lo que nos llevar, nuevamente, a definir el grado de desarrollar.
sus jefes y trate de afinar las respuestas porque en algunos casos las preguntas realizado por trabajo satisfecho suele ser a precio ajustado mensual que es
sin respuesta se deben a una planificacin no realista o confusa. distinto al pago por horas que se puede subcontratar con alguna empresa lo que
nos obligar a efectuar ajustes y consideraciones de rentabilidad que
Con las respuestas apropiadas decidimos quien, que y cuanto tiempo de consideraremos en el apartado siguiente.
calendario vamos a asignar para satisfacer cada una de las tareas considerando
el mejor rendimiento de las personas y de las mquinas. Es decir, salvo que se Una tarea importante del gestor es conocer cual es la disponibilidad de
quiera otra cosa, se tratar de emplear a las personas concretas en aquellos cada recurso tanto en cuanto a fechas topes como en el calendario individual de
trabajos que realizan de una forma ms eficiente. cada uno de los miembros de los grupos de produccin ya que los
compromisos particulares de cada uno de los trabajadores forman un conjunto
Tambin es necesario considerar que en la mayora de los proyectos de restricciones que se debe conocer lo ms pronto posible y, as, el director del
informticos, la relacin entre recursos humanos y recursos materiales suele proyecto no comprometer recursos en fechas que no podr asumir. En este
tener una relacin muy estrecha ya que de nada servira obtener ms puestos de sentido es muy importante disponer de un calendario de cada uno de los
trabajo para desarrollar con una determinada herramienta si finalmente no miembros del grupo recursos de trabajo que se vea influido por el horario
tendremos ocasin de tener esa misma cantidad de desabolladores o a la general de la empresa y del turno especfico del tipo de recurso. En este sentido
inversa: Puede no ser necesario utilizar una cantidad de programadores para recomendamos que se parta de un calendario base de la empresa sobre el que se
satisfacer las tareas de codificacin si el nmero de terminales disponibles no marcan las jomadas de trabajo y del que se excluyen todo tipo de fiestas,
puede ser superior o si no se pueden introducir ms puestos de trabajo por falta vacaciones y puentes que puedan producirse. A partir de este calendario base
de espacio, por ejemplo. de crean, inicialmente mediante una copia, los calendarios de cada recurso con
sus horarios de trabajo dentro de los das previstos de actividad. Posteriormente
Una vez afinados los recursos que deseamos incorporar para realizar las se copia el calendario del recurso en tanto calendarios individualizados para
tareas del proyecto nos puede convenir agrupar recursos por tipologas. Es cada uno de los recursos concretos que tengamos disponible. Finalmente, sobre
decir, que puede interesarnos crear grupos de recursos de tipo programadores, cada uno de los calendarios concretos de cada recurso anotaremos las
por ejemplo, para que la herramienta de planificacin de proyectos tenga incidencias concretas que se vayan produciendo facilitndose enormemente la
mayor libertad a la hora de sugerir mejoras en la planificacin. La asignacin gestin de avisos de incidencia y su posible resolucin.
de recursos a las tareas de tipo trabajo, recordemos que son las realizadas por
recursos humanos, conviene asignarlas por duracin como regla general, con lo Todo este trasiego de copias de calendarios las herramientas informticas
que se utilizarn unidades de tiempo, como pueden ser das, horas, etc. Los modernas nos facilitan su gestin no realizando copias fsicas en s sino
recursos materiales, por otra parte, se suelen emplear con medidas tipo asociaciones de estructuras de datos haciendo que un cambio efectuado sobre
cantidad como pueden ser veinte licencias del producto de bases de datos o el calendario base tenga una repercusin instantnea en los calendarios de
cuarenta cartuchos de toner para las impresoras. turno, de grupo de recursos y de recurso particular sin que sea necesario
efectuar ningn tipo de copia. Un ejemplo del aspecto de la herramienta Project
Con esta informacin comenzaremos a asignar recursos sobre las tareas 2000 para este tipo de gestin de calendarios puede verse en la Figura 11.2. En
teniendo en cuanta que no podemos cargar tareas con trabajos superiores al este caso se puede asociar un calendario de la empresa, del cual se hereda un
tiempo mximo establecido tratando de nivelar la carga de trabajo de forma calendario, por ejemplo, para cada tumo, y de cada turno, si fuera necesario, un
uniforme durante el mayor tiempo posible del equipo y de forma equilibrada calendario para cada recurso concreto.
entre los mismos. El efecto que se produce por el hecho de asignar recursos
que generalmente son escasos para realizar una serie de actividades mucho
mayor que los recursos disponible es que el cronograma del proyecto se
retrasa. Con esto el director de proyecto tendr que enfrentarse al problema de
conseguir nuevos recursos o contratar la ejecucin de ciertas actividades en el
exterior. En el caso de tener que obtener nuevos recursos de trabajo del
mercado exterior se tendr que tener en cuenta que, normalmente, el pago
210 PLANIFICACIN Y GESTIN DE SISTEMAS INFORMTICOS CAPTULO 11: PROGRAMACIN DE RECURSOS 211
I p t i J & l - - - -al]-*]
Archivo Edicin Vet In se rta r Form ato fcjsiram ient Proyecto V e n ta re J lli;
'M icrosoft Project - Desarrollo te softw are . ' S i # a ! - m % i'>r? i j g r g
_________ _________________________________ O ^ jES 3
Figura 11.1 Diagramas de Gantt facilitados por Microsoft Project 2000 El d irecto r del proyecto tam bin ten d r que enfrentarse con problem as
referentes al acopio de sum inistros, de alquiler de m aquinaria, la gestin de
contratar tales m edios, la form acin en el uso de las nuevas tecnologas y un
largo etctera de asuntos que, en p rin cip io parecen triviales, pero que el
Se pu ed en indicar, en cada uno de los niveles, los das laborales, los director de proyecto debe saber gestionar con todo tipo de detalles.
festivos y los das no laborables as com o introducir el horario, por defecto, de
la jo m a d a laboral. T am b in se pueden c re a r, com o se ha indicado, todo tipo de Con todos los p lazos y todos los recursos asignados al proyecto
calendarios a p artir del calendario que v isu alizam o s en pantalla. obtendrem os un inform e de gestin q u e deberem os contrastar con el resto de
com paeros que dirigen otros proyectos para ver si tenem os conflictos con
proyectos ajenos, o para saber los riesgos que incorporam os, tanto si no
cum plim os los hitos del proyecto n o so tro s o com o si no lo cum plen otros
sectores cuya responsabilidad pueda p o n e r en peligro el proyecto propio.
Ejemplo de WBS
214 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 F O R M T IC O S C A P IT U L O I I : P R O G R A M A C I N D E R E C U R S O S
Especificacin de tarea
Nmero: 5.2.
Nombre: Diseo base de datos
Descripcin: Se diseara la base de datos a partir del
modelo entidad/relacin obtenido en la
tarea de anlisis 2.4
O
O
ms convenientes segn el tipo de proyecto, pero de forma genrica
D E F . C21 100 75 175
podemos definir los siguientes:
o Produccin (P): cuando una carga de trabajo y una intensidad
determina la obtencin de un producto final. En terminologa de
gestin de proyectos son los recursos, INT. S S 2 25 125 150
cuando determina las condiciones en que pueda ser obtenido el INT. S IS T E M A 200 100 100 250 650
R E A L . S S1 P
DEF. S S 2 A R
Ejemplo de OBS simple (Sanchis, 2002) D E F . C21 R y P S
INTE =!VINIENTES
A B C D Ca J Ca k
Def. sistema X
IN T. S S 2 C P
Real. s s t 1 X
REAL. SS3 A
Real. sst. 2 X X
Real. sst. 3 X INT. S I S T E M A A y P P P P
Pero el trabajo no termina en conocer el calendario del proyecto sino que Los informes de gestin de la planificacin nos ayudarn a considerar los
adems necesitar informar del coste del proyecto tanto a nivel total como a resultados de la planificacin desde el punto de vista financiero y,
nivel de calendario. Necesitar conocer cuales son los pagos que se debern posiblemente, nos obligarn a efectuar muchas modificaciones antes de
producir en los prximos das as como considerar otros pagos que tenga disponer de un proyecto que pueda ser aprobado y que sirva de referencia para
comprometidos con anterioridad. todo su desarrollo.
informticas. En este sentido Microsoft Project propone los siguientes perfiles Programacin detallada con hitos, asignacin de tareas, gestin de
de aplicacin de proyectos en general: costos y previsin de pagos.
Uniforme. El trabajo se reparte de forma uniforme durante el calendario Con todo ello, una vez firmado obtendremos una lnea base del proyecto.
del recurso
Decreciente: Al principio se aplica ms trabajo y luego la actividad
decae
Creciente: Poco a apoco se va aumentando el trabajo sobre cada tarea
siendo al final de la misma cuando se concentra el esfuerzo.
Pico inicial: Similar al creciente pero distribuido como un pico inicial
de trabajo.
Pico final: El inverso al anterior.
Dos picos: Al principio de la actividad se produce un pico de trabajo.
Campana: El trabajo se concentra fundamentalmente en el centro de la
actividad.
El proyecto para su firma deber incluir, entre otros, todos los documentos
iniciales de objetivos a cumplir y los parmetros generales del alcance, plazos
previstos y costes totales a los que se acompaarn todo tipo de documentos de
texto que se dispongan y que hagan referencia al proyecto en si.
CAPTULO 12
En la presente leccin se efectuar, adems, un recorrido por las La disponibilidad de un sistema de define como el cociente entre el tiempo
especificaciones de seguridad que pueden condicionar notablemente las medio entre fallos y la suma del tiempo medio entre fallos y el tiempo de
primeras planificaciones. reparacin, todo ello multiplicado por 100 para hablar de porcentajes.
12.1 ESTNDARES EXTERNOS, INTERNOS Y A MEDIDA Conviene recordad los modelos de fiabilidad del software que tratan de
medir, o de hacer una prediccin de la fiabilidad en funcin del tiempo de
Para mejor comprender el presente captulo vamos a definir una serie de calendario o en funcin del tiempo de CPU, el comportamiento del sistema
conceptos como son: frente a fallos. En especial es de considerar el modelo de diseminacin que
mide el poder de la deteccin de errores mediante procesos estocsticos. Se
Fiabilidad del software: la probabilidad de operacin libre de fallos de pueden estudiar casos como:
un programa de computadora en un entorno determinado y durante un tiempo
especificado La validez predictiva
Capacidad del modelo
En este sentido podemos definir los fallos como cualquier falta de Calidad de las suposiciones
concordancia con los requisitos del software. En este sentido tenemos que Aplicabilidad
considerar la naturaleza de los fallos ya que tienen un amplio abanico de Simplicidad
posibilidades: de leves a graves, desconcertantes o catastrficos, de correccin Seguridad del software
inmediata con pequeo esfuerzo a un gran esfuerzo. Adems la correccin de
un fallo puede producir nuevos fallos. Los modelos de fiabilidad son actividades de garanta de calidad del
software que se centra en la identificacin y evaluacin de riesgos potenciales
La mayora de los modelos de fiabilidad relativos al hardware son debidos que pueden producir un impacto negativo en el software y hacer que falle el
al desajuste que a fallos de diseo o al desgaste de los componentes fsicos y sistema completo.
no nos sirven como idea de clasificar los fallos del software donde ocurre lo
contrario. El anlisis del rbol de fallos es un modelo grfico para determinar los
estados del sistema peligrosos: ejemplos de rboles de fallos se pueden seguir
Se suelen aplicar una serie de medidas de fiabilidad y de disponibilidad, la muy bien desde los sistemas de tiempo real y los modelos de suceso-accin. Un^
forma ms sencilla de medida es el tiempo medio entre fallos definido como la modelo que se adapta a este problema y sobre el que se pueden representar la
suma del tiempo medio de fallo ms el tiempo medio de reparacin de ese situacin real es mediante Redes de Petri.
fallo:
Se puede establecer una valoracin intrnseca de cada activo 1 susceptible
TMEF=TMDF+TMDR de riesgo en el equipo de desarrollo y sus sistemas para lo cual se puede
considerar tanto su valor de uso corno el valor de cambio, dependiendo de la
siendo TMEF el tiempo medio entre fallos, TMDF el tiempo desde la situacin particular de cada activo. El tipo de valoracin puede ser
correccin del fallo inmediatamente anterior y TMDR el tiempo de reparacin directamente una valoracin intrnseca, para aquellos activos que tienen
del fallo. sustitucin estndar sin problemas de operatividad, y que se considerar,
obviamente, su valor de cambio; tambin puede tratarse de un activo
Otra medida utilizada en la industria de la informtica y de los Sistemas de
Informacin desde el punto de vista software es el nmero de defectos por
miles de lneas de cdigo fuente que, si bien es una medida bastante precisa, 1 Cualquier elemento de la configuracin del proyecto, ya sea software, documentacin, ele
suele ser bastante desconcertante para el personal no especialista. mento de anlisis se puede considerar como activos del grupo de desarrollo o de la empresa
propietaria.
22 6 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 F O R M T IC O S C A P T U L O 12: A N L IS IS P C I , R IE S G O : S E G U R ID A D 227
Por otra parte podemos establecer una serie de mtricas para valorar el Submodelo de Ele Submodelo de Even Submodelo de Pro (
estado de seguridad de los activos. mentos tos cesos
Autenticacin: Seis Entidades Bsicas
Tres Tipos Principales
o Bajo, si se puede reemplazar fcilmente por problemas de Cuatro Etapas Tipificadas
autenticacin Activos
o Normal, si se puede reemplazar a coste medio Amenazas
Planificacin
o Alto (difcil y costosamente reconstruible) Vulnerabilidades (
Esttico Anlisis de Riesgos
Confidencialidad: Impactos
Dinmico organizativo Gestin de Riesgos
o Bajo, si se puede reemplazar fcilmente por problemas de Riesgos
Dinmico fsico Seleccin de Salvaguar
confidencialidad Salvaguardas
das
o Normal, si se puede reemplazar a coste medio
o Alto (difcil y costosamente reconstruible) (
F ig u ra 12.1 E structura de b lo q u es d e l m o d elo M A G E R IT
Integridad:
o Bajo, si se puede reemplazar fcilmente
o Normal, si se puede reemplazar a coste medio El submodelo de elementos esta formado por todos los activos de los
o Alto (difcil y costosamente reconstruible) Sistemas de Informacin de la empresa propietaria junto con las amenazas que
o Crtico, si no puede volver a obtenerse puedan producirse sobre los activos, las vulnerabilidades que pueden tener los
Disponibilidad. activos frente a las amenazas, el valor del impacto que puede tener el hecho de
o Menos de una hora. que se produzcan esas condiciones y el riesgo que se est corriendo junto con
o Hasta un da laborable las medidas correctoras que podamos tener previstas.
o Hasta una semana
o Ms de una semana (
228 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 F O R M T IC O S C A P T U L O 12: A N L IS IS D EL R IESG O : S E G U R ID A D 22 9
Conviene tener en cuenta que estos ltimos criterios conceden al activo un Otro aspecto importante en el anlisis de riesgos es el estudio de las
valor ms prximo al significado del impacto causado en los casos de vulnerabilidades. La vulnerabilidad de un activo es la potencialidad o
materializacin de cualquiera de las amenazas posibles que al verdadero valor posibilidad de ocurrencia de la materializacin de una amenaza sobre dicho
de adquisicin o desarrollo del propio activo. Este enfoque viene motivado activo. Las vulnerabilidades varan por la aplicacin de medidas correctivas
porque se considera que numerosos activos presentan una vulnerabilidad muy sobre tales amenazan en las fases correctivas o como consecuencia de aplicar
alta (vulnerabilidad = I 100%) a ciertos sucesos; si adems el defecto salvaguardias.
produce una disfuncionalidad completa en el activo (degradacin = 100 %) se
obtiene una situacin de impacto pleno en la que el riesgo alcanza el valor de Mtricas de Vulnerabilidad
impacto producido en el momento de materializacin de la amenaza.
Se consideran amenazas a los eventos que pueden desencadenar un Periodo medio ente ocurrencia Rscala subjetiva Tasa anual
incidente en la organizacin, daos materiales o prdidas inmateriales en sus A diario Muy frecuente 100
Mensualmente Frecuente 10
activos. Las amenazas en la profesin informtica estn caracterizadas por
Una vez al ao Normal 1
errores y accidentes si bien podemos tener otro tipo de amenazas debidas a un Cada varios aos Poco frecuente 1/10
planteamiento deficiente del proyecto, a las debidas a errores en el proceso de
adaptacin de algn mdulo que anteriormente era correcto o las amenazas Figura i 2.2 Ejemplo de mtricas de Vulnerabilidad segn el modelo MAGERIT
causadas por objetos empotrados cada da ms difciles de prever.
Los tipos de vulnerabilidades los podramos clasificar en:
Conforme se vaya progresando en el desarrollo del proyecto, las amenazas
analizadas anteriormente variarn en cantidad y posiblemente de clase, ya que, Vulnerabilidad intrnseca del activo respecto al tipo de amenaza que
por ejemplo, como consecuencia de la utilizacin de herramientas como las depende de las dos entidades, activo y amenaza.
indicadas en ASI2000 pueden aparecer amenazas no presentes con Vulnerabilidad efectiva que es la resultante de aplicar las salvaguardas.
anterioridad.
De hecho, la progresin de la vulnerabilidad durante el desarrollo sistemas
En el momento del desarrollo de los sistemas de informacin se pueden de informacin es el resultado del aplicar las funciones y mecanismos de
dar, como ejemplos, las siguientes amenazas: salvaguarda especficos para reducir la vulnerabilidad efectiva.
Fallo de equipos hardware causado por componentes software.
Fallo en las comunicaciones: centralitas, bridges, routers, etc. La mtrica de la vulnerabilidad consiste en considerar la distancia entre la
Avera de climatizacin que impiden el correcto funcionamiento de los amenaza y su materializacin sobre el activo. De esta forma para la
sistemas. vulnerabilidad se utiliza la mtrica [0 , 1 ] donde la cota 0 implica que la*
Cortes de suministro elctrico o malfuncionamiento en las unidades de amenaza no afecta al activo y la cota 1 es la certeza de que se va a producir el
alimentacin ininterrumpida (SAIs). fallo por una amenaza concreta.
Errores causados por funcionamiento invlido de aplicaciones.
Indisponibilidad lgica causada por no poder arrancar u operar La vulnerabilidad, como propiedad de la relacin activo-amenaza da lugar
correctamente el sistema por causas de actualizacin en el sistema a una casustica extremadamente variada y muy compleja que se puede resumir
operativo o en las herramientas de desarrollo. en una coleccin de factores valorados y relacionados con las vulnerabilidades
Inadecuacin de monitorizacin por problemas colaterales en el debidas a las causas ms importantes como instrumento de ayuda al proceso de
componente que monitoriza. valoracin de la vulnerabilidad.
Corrupcin de la informacin por tratamiento defectuoso de la misma
por parte de las distintas aplicaciones. Estos factores se pueden evaluar respecto a la vulnerabilidad siguiendo la
Prdida de informacin o no poder recuperarla de forma eficiente. siguientes escala: CI = Cierto, M F = Muy Frecuente, F = Frecuente, FN =
Frecuencia Normal, y PF= Poco Frecuente.
230 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 F O R M T IC O S C A P T U L O 12: A N L IS IS D E L R IE S G O : S E G U R ID A D 231
Otro aspecto importante es el estudio de los impactos. Un impacto en un valores calculados de riesgo 3 se debern tomar acciones para continuar con las
activo es la consecuencia sobre ste de la materializacin de una amenaza. En etapas siguientes del proyecto.
este sentido podemos considerar varios tipos de impactos:
En este sentido es importante considerar los siguientes puntos:
Impactos con consecuencias cualitativas funcionales
o Deterioro del Subestado de Integridad (SI) El riesgo calculado intrnseco se define o calcula antes de aplicar
o Deterioro del Subestado de Disponibilidad (SD) salvaguardas.
Impactos con consecuencias cuantitativas: El riesgo calculado residual se considera como el que se da tras la
o Prdidas de valor econmico aplicacin de salvaguardas dispuestas en un escenario de simulacin o
o Prdidas indirectas en el mundo real.
o Prdidas econmicas relativas a responsabilidad legal El umbral de riesgo es un valor establecido como base para decidir por
Impactos con consecuencias cualitativas orgnicas. comparacin si el Riesgo calculado es asumible o aceptable.
La caracterstica ms destacable del impacto es la presencia del impacto En la figura 12.3 se establece un modelo de riesgo en funcin del impacto
pleno (impacto = 100 %) cuando la materializacin de una amenaza produzca y la vunerabilidad.
un disfuncionalidad completa en el activo. Este tipo de impactos puede
traducirse en una interrupcin no controlada de los procesos, tanto informticos Im p a c to R e s (jo
como de control sobre el medio fsico, con consecuencias en multitud de M uy alto Alio M uy alto M u y alto M u y alto
procesos y de forma simultnea. Alto M edio Alto M u y alto M u y alto
5 Esta decisin puede tomarse por comparacin explcita del riesgo calculado con un nivel
2 ACID: Autenticacin, Confidencialidad, Integridad y Disponibilidad. prefijado de riesgo (umbral de riesgo).
232 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 F O R M T IC O S C A P T U L O 12: A N L IS IS D E L R IE S G O S E G U R ID A D 233
Vulnerabilidades y los Impactos en gran nmero de niveles, por lo que puede Al definir una relacin entre un activo y una amenaza debida a posibles
ser no slo suficiente, sino adems lgico, reducir la matriz anterior por elementos deberemos establecer, para ese par activo amenaza, un conjunto de
ejemplo a los 3 niveles Bajo, Medio y Alto, como indican los recuadros funciones de salvaguarda. Cada funcin de salvaguarda incorpora un conjunto
anteriores. de mecanismos de salvaguarda que se debern aplicar para hacer frente a la
En el caso ms sencillo, la Vulnerabilidad se ha podido equiparar a una amenaza.
frecuencia (por ejemplo, de fallos de un componente), y el impacto tambin se
ha podido estimar como un valor monetario de reposicin (de ese componente). El tercer submodelo de la metodologa MAGERIT es el de procesos que
Entonces, el riesgo calculado se puede considerar como el impacto acumulado comprende las cuatro etapas representadas en la figura 12.4 y que describimos
durante un perodo, por ejemplo un ao. El Riesgo ser as el coste de las a continuacin:
reposiciones del componente durante el ao y se podr comparar, bien con un
umbral determinado, bien con el coste tambin anual de las salvaguardas para
reducirlo. As, si el componente falla cada mes como media y su reposicin
cuesta 100.000 pesetas, el riesgo anual ser simplemente la composicin de
ambas cantidades, o sea 1 .200.000 pesetas.
Recogida de informacin. Una vez completada la tabla de riesgos podremos establecer para cada uno
Situacin genera! del sistema. estrategias y planes de contingencia que nos determinaran nuestro Plan de
Identificacin y agrupacin de A divos. Reduccin, Supervisin y Gestin del Riego:
Identificacin y evaluacin de Amenazas.
Identificacin y estimacin de Vulnerabilidades. Estrategia de prevencin. Sera aquella dirigida a reducir la
Identificacin y valoracin de Impactos. probabilidad de que ocurra el riesgo.
Evaluacin del Riesgo. Estrategia de minimizacin. Sera aquella dirigida a reducir el impacto
del riesgo si este ocurre.
Plan de contingencia. Sera el conjunto de acciones planificadas para
ser ejecutadas en el momento de la ocurrencia real del riesgo.
12.3 ESTRATEGIAS Y PLANES DE CONTINGENCIA
En la proyeccin del riesgo se busca hacer una medicin de los riesgos en Ejemplo:
funcin de su probabilidad de ocurrencia y del coste o consecuencias de que Se presenta a continuacin un ejemplo de tabla de riesgos de un
ocurra. El objetivo ltimo es establecer un Plan de Reduccin, Supervisin y proyecto de desarrollo de software para un cliente. Veremos dos
Gestin del Riego (RSGR). tablas, la primera corresponde a la identificacin del riesgo,
tipologa, vulnerabilidad e impacto. La segunda contiene para cada
El primer paso para conseguir el RSGR es desarrollar una tabla de riesgos riesgo identificado su estrategia de prevencin, estrategia de
donde hacer la proyeccin de los riesgos. Los pasos generales de su minimizacin y plan de contingencia.
construccin seran:
Hay que tener en cuenta que tanto el riesgo identificado como su
Hacer una lista de todos los riesgos posibles, incluidos los ms remotos. vulnerabilidad e impacto se definen para un entorno determinado,
Categorizar cada riego, indicando el tipo de riesgo que es: de producto, formado por la empresa de desarrollo, el diente, el personal, el
de proyecto o de negocio. Cada organizacin puede incluir las mercado, el momento econmico y tecnolgico, etc. E l mismo
categoras que considere oportunas segn sus propias caractersticas. desarrollo puede contemplar riesgos distintos en definicin y
Determinar la probabilidad de ocurrencia de cada riesgo caractersticas para un cliente u otro o si se desarrolla en un entorno
(vulnerabilidad), ya sea mediante una estimacin en forma objetiva o tecnolgico u otro, etc.
subjetiva o haciendo una valoracin promedio de todas las estimaciones
individuales. Los riesgos estn ordenados por vulnerabilidad del riego (de mu)> alta
Valorar el impacto de cada riesgo y establecer una categora de impacto a muy baja) y dentro de esto por impacto (de tolerable a catastrfico).
para cada uno. Una posible clasificacin de categoras sera: Se deber tener en cuenta los riesgos ms frecuentes (hasta
Catastrfico probabilidad media) sea cual sea su impacto (aunque se pueden
Serio despreciar aquellos de impacto tolerable) y los riegos con
- Tolerable probabilidad baja o muy bajo con impacto serio o catastrfico.
236 P L A N IF IC A C I N Y G E S T I N D ti S IS T E M A S IN F O R M T IC O S C A P T U L O 12: A N L IS IS D E L R IE S G O : S E G U R I D A D 237
de lenguaje
R ie sgo Tipo Probab. Efecto
Cambio de requisitos Proyecto M uy alta Serio Trabajo en grupo. Reparto
Elevado
Cambio del personal Proyecto Alta Tolerable Divisin del Establecer equitativo del
nmero de
Limitaciones impuestas por el proyecto en coordinador y trabajo. Reajustes
miembros en
Producto Media Serio subproyectos buena y control del jefe
lenguaje el equipo
comunicacin de proyecto
Elevado nmero de miembros Mantener
Proyecto Alta Tolerable Acuerdos con
en el equipo motivado y
empresas Sustitucin
Baja del personal Proyecto Media Serio contento al
Baja del subcontratistas. rpida. Reajustar
personal.
Falta de motivacin Proyecto Media Serio personal No tener una roles si es
Prevencin de
nica persona necesario
Retraso en la entrega del Media accidentes e
Proyecto Serio por rol
producto final incidencias
Buena
Retraso de la aceptacin del Media
Proyecto Serio comunicacin y Seguimiento del
cliente Reajuste de roles.
Falta de liderazgo. Buena personal
Cambio de
Salida inesperada al mercado motivacin poltica de potencialmente
Negocio Baja Serio personal
de un producto equivalente retribuciones y inmotivado
mritos
Personal poco cualificado Proyecto Baja Serio
Buena Crisis del
Abandono del cliente Proyecto M uy baja Catastrfico Retraso en la planificacin y proyecto (trabajar Renegociar con el
Cambio en la tecnologa Producto M uy baja Serio entrega del seguimiento y ms horas, cliente el plazo de
producto final control del reajustar la entrega
No se cumple el contrato Negocio Baja Serio
proyecto planificacin)
Mala eleccin de la tecnologa Proyecto M uy Baja Serio Comunicacin
constante con el
Retraso de la cliente, buena Presencia del Renegociar con el
Estrategia de Estrategia de Plan de aceptacin planificacin del jefe de proyecto. cliente el plazo de
R iesgo
prevencin minim izacin contingencia del cliente trabajo de prueba Reajuste de roles entrega
Entrevista y personal
detallada con el cualificado
cliente por Volver a la etapa Mercado Analizar nuestro
Diseo flexible. Salida
personal de anlisis de especializado o producto en
Consensuar con inesperada al Estar al dia de la
Cambio de cualificado para requisitos, cautivo. Producto comparacin con
el cliente mercado de situacin del
requisitos establecer los modificarlos y competitivo en el competidor
soluciones poco un producto mercado
requisitos. revisar la cuanto a precio para encontrar
impactantes equivalente
Establecer planificacin y/o calidad puntos fuertes
prioridades en los Establecer planes
requisitos Compartir de formacin
Cumplir la Personal Buena poltica de conocimientos y especficos que
No tener una
Cambio del planificacin. poco formacin y experiencias. no retrasen el
nica persona Reajustar roles
personal Realizar un buen cualificado seleccin Solicitar ayuda proyecto. Nuevo
por rol
trabajo en equipo. de expertos personal y
Formacin Usar otras reajuste de roles
Limitaciones
exhaustiva del Establecer herramientas Comunicacin. Presencia del Buscar nuevos
impuestas
lenguaje antes de alternativas en el complementarias. Abandono Mantener los jefe de proyecto. clientes. Estudiar
por el
empezar el diseo Cambiar el del cliente plazos de entrega Buena la posibilidad de
lenguaje
diseo diseo. Cambiar y la calidad presentacin del abandonar el
23 8 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 F O R M T IC O S C A P T U L O 12: A N L IS IS D E L R IE S G O : S E G U R ID A D 239
producto y el proyecto Deteccin del resto de componentes afectados: Por propagacin dentro
proyecto de las aplicaciones, de los elementos anteriormente identificados.
Estar al dia
Usar tecnologas
Cambio en la tecnolgicamente. Cambiar el diseo
consolidadas y
tecnologa Soluciones y la codificacin
estndares
verstiles
Crisis del
Redactar el
proyecto. Centrar
No se contrato
esfuerzos en Renegociar el
cumple el asegurando
puntos contrato
contrato compromisos
importantes del
factibles
contrato
Documentarse.
Mala Realizar una Personal experto. Cambiar la
eleccin de seleccin Adecuacin del tecnologa.
P ro p ag ac i n
la tecnologa cuidadosa de la diseo. Replan ificar
tecnologa Figura 2.5 El anlisis del Impacto
CAPTULO 13
LA COMUNICACIN TCNICA
En colaboracin con el Dr. Josc Ramn Hilera Gonzlez
La documentacin se clasificar en dos grupos: a documentacin de los 13.1 FUNDAMENTOS DE LA COMUNICACIN TCNICA.
procesos y a documentacin de los productos, entre los primeros se
encuentran los planes, estimaciones, listas de tareas, anexos, informes de Gran cantidad del tiempo la dedicamos a la comunicacin. La comunicacin
evolucin del proyecto, documentos de trabajo, etc. Entre el segundo grupo se intenta trasmitir informacin o conocimientos por lo que tenemos que
encuentra la documentacin de usuario y la documentacin del sistema. diferenciar ambos trminos. En la comunicacin lo que se necesita es un
conocimiento que compartir y, por lo tanto, se deben de establecer las
Las metodologas de desarrollo de sistemas informticos y los estndares condiciones necesarias para que este proceso pueda ser realizado; en concreto,
relacionados con la gestin de la calidad suelen establecer los diferentes dentro de la materia que nos ocupa, ser necesario que las personas
documentos, de las dos categoras indicadas, que han de generarse a lo largo de involucradas en la comunicacin tengan algo que comunicar y que quieran
los proyectos. Por ejemplo, en el caso del estndar ISO 12207, algunos de los hacerlo.
documentos previstos son los siguientes:
La comunicacin se puede realizar de muchas formas: comunicacin oral,
Contrato del proyecto escrita, viendo anuncios, escribiendo, etc pero es la comunicacin oral la que,
Documento de requisitos de momento, nos ocupa la mayor parte del tiempo de la actividad de
Especificaciones funcionales comunicacin. En la gestin de proyectos informticos necesitaremos disponer
Manual de usuario de un conocimiento completo y pertinente sino que, adems, tenemos que
Manual de explotacin buscar los cauces para compartirlos de la forma ms eficiente posible.
Manual de procedimiento
Manual de calidad Para que exista una verdadera comunicacin se necesita de un emisor de
Informes de pruebas conocimientos, un mensaje que se quiera trasmitir, y, al menos, uno o varios
Informes de problemas receptores disponibles que sean capaces de entender lo que se trasmite. En
Informes de codificacin todos los canales de comunicacin se genera un ruido que hace que el mensaje
Informes de estado no llegue con toda la claridad a los receptores por lo que es necesario, si
Informes de verificacin pretendemos una comunicacin efectiva, buscar un segundo canal de respuesta
Informes de validacin que nos confirme que la emisin se ha producido con integridad y que el
Informes de auditora receptor ha comprendido el mensaje: se trata del conocido feedback que tanto
Informes de mtricas apreciamos en todo tipo de mensajes.
Material de formacin
Plan de desarrollo
Plan de mantenimiento
Plan de migracin Canal de trasmisin
Plan de gestin de configuracin
Plan de gestin del riesgo Emisor A ------------------
\ Canal de retomo
Decamos que la mayor parte de la comunicacin entre personas es la Una vez comenzada la reunin, tratando de ajustarse a la fecha de inicio
comunicacin oral si bien en los proyectos de desarrollo tcnico se est prevista, ni el moderador ni el grupo de trabajo deberas ser molestados desde
transitando hacia una comunicacin escrita. Cada da se introduce mayor nivel el exterior salvo por temas importantes que se realizaran a travs de una
de soporte documental para que las peticiones de informacin se realicen de secretaria o persona auxiliar. No hay nada peor en una reunin que el sonido de
una forma sistemtica y disciplinada para que el tiempo, que tiene una los telfonos mviles que hacen que muchas personas tengan que perder un
capacidad finita, se nos convierta en un aliado y no en una fuente de gastos. tiempo muy valioso.
Una fuente de informacin tcnica en las empresas que quieren desarrollar Durante la reunin el moderador ser la persona que dar juego a la
proyectos es las reuniones. Una reunin tcnica formal nos ayudar a asentar reunin: repartir documentacin, fijar la informacin que el grupo a
conocimientos y a que la comunicacin de las metas sean fuertemente elaborado, tomar nota de los acuerdos y tratar de que todos los miembros del
confirmadas. En las reuniones, adems de intercambiarse mensajes orales y grupo de la reunin respeten los tumos de palabra. Igualmente intentar centrar
escritos, los asistentes intercambian mensajes complementarios, a travs de la reunin si algn miembro o grupo de participantes se sale del tema general
gestos y expresiones, que nos ayudarn a sentar las bases del proyecto, sus de la reunin o si trata de tener alguna reunin paralela.
objetivos y la importancia que el mismo tiene para la empresa y otro tipo de
informacin de importancia para el grupo. Cuando finaliza la reunin realizar un informe, que distribuir entre los
miembros para lograr su aprobacin y, si as se especifica, lo elevar al
Las reuniones deben de prepararse con antelacin haciendo que los conocimiento de sus superiores.
participantes planifiquen las preguntas y reflexionen sobre las actividades
realizadas frente a las actividades previstas. Segn se trate de reuniones de
trabajo o reuniones informativas se debern tener en cuenta una serie de pautas 13.3 PREPARAC IO N ES DE EXPOSICIONES O R A L E S Y DE
para lograr los objetivos que se persiguen. As en una reunin de trabajo, donde M ATERIALES DE SO PO RTE.
lo que se persigue es la bsqueda de soluciones a problemas concretos, el
moderador deber mantener una postura de neutralidad y, si as hiciera falta, La importancia de preparar las exposiciones al grupo de la reunin, o incluso
animara a los miembros del grupo a manifestar sus ideas y posibles en las entrevistas personales, adquiere cada da una mayor importancia por el
soluciones. Sin embargo en la reunin informativa el que preside tomar un hecho de tratar de asegurar un perfecto conocimiento de toda la informacin
alto protagonismo ya que el objetivo ser facilitar informacin a los dems que el grupo debe de conocer. Pero las personas de las empresas, normalmente
miembros de la reunin salvo que el objetivo sea precisamente el contrario: estn muy ocupadas, y no se les puede facilitar toda la informacin disponible
recibir informacin del grupo. sobre un tema sino que ser necesario que conozcan los aspectos ms
importantes y que tengan referencias del lugar dnde se pueden ampliar los Documentales (SGBDD), o Sistemas de Gestin Documental (SGD) o, en
aspectos especficos del tema en cuestin. ingles. Document Management Systems (DMS), que, entre otros, ofrecen
mecanismos para la identificacin, almacenamiento, seguimiento, recuperacin
En este sentido es necesario insistir en la forma de elaborar exposiciones y presentacin de los documentos.
orales, los materiales de soporte y, sobre todo, saber emplear con cierto rigor
los elementos de comunicacin como pueden ser los sistemas hipermediales Aunque tradicionalmente estos sistemas han asumido exclusivamente
considerando el objetivo final de la exposicin: explicaren un breve espacio de funciones propias de gestin administrativa como las mencionadas, existe una
tiempo, las ideas fundamentales del trabajo cuya documentacin es excesiva y tendencia a la integracin en los ms recientes SGD de tales funciones con las
su lectura, por tanto, nos ocupara varias horas. de edicin que, hasta ahora, eran competencia de los populares procesadores de
texto. Se puede decir, por tanto, que un SGD es un sistema que permite la
Las personas estn muy ocupadas pero el director del proyecto necesita automatizacin, la creacin, el mantenimiento y la consulta de fuentes de
que sus superiores, o la empresa cliente, perciba una informacin que es de informacin constituidas por documentos y, por lo tanto, sirve para explotar el
mucha importancia para el desarrollo del proyecto como pueden ser el Plan de conocimiento que contienen los documentos con el fin de ponerlo al alcance de
Trabajo, informacin para la ayuda en la decisin de invertir en un proyecto, los usuarios del sistema, definicin de Codina en 1994.
presentacin de ofertas con matices importantes que se quieren resaltar.
Los SGDs se utilizan en el seno de organizaciones pblicas o privadas, con
Para que la presentacin sea exitosa se deben de cumplir una serie de el objetivo de controlar e incrementar la eficiencia del finjo de documentos que
premisas que se reflejan en los siguientes apartados: soportan sus negocios o actividades. Entre los posibles beneficios que se
pueden obtener mediante esta automatizacin de la gestin documental podran
Estudio de la estructuracin de la presentacin considerarse los siguientes:
Preparacin del material de apoyo
Estudio de la exposicin El aprovechamiento del capital intelectual de la organizacin, ya que el
conocimiento se crea una sola vez y es reutilizado muchas veces.
13.4 LA HERRAM IENTA CASE Y EL SOFTWARE DE La gestin del flujo de trabajo, mediante el control del flujo de
PLANIFICACIN COMO MEDIO DE PRODUCIR informacin a travs de todas las fases de un proceso de trabajo.
DOCUM ENTACIN TCNICA.
Se favorece un trabajo en equipo ms efectivo acelerando actividades
Dentro del entorno de las herramientas de construccin de sistemas de crticas para la organizacin (por ejemplo, las actividades de
informacin modernas e, incluso, en los planificadores de proyectos, se coordinacin o la notificacin de incidencias).
proveen servicios de seguimiento de procesos de gestin documental que
facilitan todo tipo de comunicacin tcnica entre los elementos del grupo.
Al disponer de la documentacin de forma inmediata, se puede mejorar
el proceso de produccin (si existe) y el servicio al cliente.
El trmino gestin documentaI suele utilizarse para hacer referencia al
control automatizado de documentos electrnicos a travs de su ciclo de vida
Permite una rpida respuesta a eventos o imprevistos que puedan surgir.
completo en una organizacin, desde su creacin inicial hasta su archivado
final. Si, como afirman algunos autores, el 90% de la informacin de una
Pero para que el conocimiento se comunique es necesario considerar que
organizacin reside en documentos (segn Cleveland en 1995), resulta evidente
existe una base de conocimientos que cada da se va enriqueciendo como en el
suponer que el aumento de la eficiencia en su gestin d lugar al consiguiente
caso particular de organizacin de las bibliotecas. Antes de decidir implantar
incremento de competitividad de la organizacin. Tal objetivo no es, sin
un sistema de este tipo en una de ellas, habra que plantearse una serie de
embargo, posible sin unas herramientas informticas adecuadas que
interrogantes acerca de si se pretende que los documentos sean el fin ltimo de
genricamente reciben el nombre de Sistemas de Gestin de Bases de Datos
la organizacin o un medio para alcanzar un fin (por ejemplo, la obtencin de
2+8 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 F O R M T IC O S C A P T U L O 13: LA C O M U N IC A C I N T C N IC A 249
beneficios), si se desea poder ofrecer a los usuarios la posibilidad de consultar incorporadas ahora que la tecnologa de redes de computadoras, especialmente
documentos virtuales, si el sistema va a gestionar tambin los documentos Internet e Intranet, permite una perfecta comunicacin entre los posibles
administrativos de la biblioteca o slo los documentos depositados en ella, cul integrantes de grupos de trabajo.
es el perfil de los clientes/usuarios de los fondos documentales, etc.
La infraestructura necesaria para disponer de un servicio de groupware
En los siguientes apartados se analizarn las funciones que debe incorporar est formada normalmente por el hardware, junto con el software de base, y las
un SGD para que sea de utilidad a las organizaciones, destacando una lneas de comunicacin. En este sentido se entiende que la infraestructura
tendencia de gran actualidad que ya ha repercutido en estos sistemas, como es sobre la que se va a trabajar es algo ms que el ordenador y el programa: se
la necesidad de incorporar servicios que faciliten la cooperacin en grupos de habla, adems, del acceso a todos los recursos que pudieran existir a travs de
trabajo. la red que estar integrada por las computadoras, tanto los que utilizan los
usuarios (clientes del sistema), como la o las computadoras que centralizan las
Los sistemas de Gestin Documentales, SGDs, son sistemas informticos bases de datos documentales (servidores).
que estn compuesto de unos elementos fsicos (el hardware) que constituyen
la infraestructura del sistema y otros lgicos (el software) que proveen los Sobre esta infraestructura se pueden montar una serie de servicios para
servicios necesarios para gestionar un documento en una organizacin desde su optimizar la comunicacin. Tales servicios son:
nacimiento hasta su muerte. Estos componentes son los siguientes:
Los servicios de autor
Infraestructura. Los servicios de almacenamiento
Servicios de autor. Servicios de bsqueda
Servicios de almacenamiento y bsqueda. Servicios de biblioteca
Servicios de biblioteca. Servicios de presentacin y distribucin
Servicios de presentacin y distribucin.
Servicios de trabajo coiporativo {groupware). Los servicios de autor son un conjunto de herramientas (de autor
entendido como usuario final) para permitir la creacin de los documentos que
Aunque existen productos comerciales que ofrecen algunos de estos sern gestionados y que debe poder manejar formatos de documentos creados
servicios por separado, la tendencia actual es su integracin en una nica por otras aplicaciones. Estas herramientas pueden ser desde procesadores de
herramienta que combine las tradicionales funciones de almacenamiento y texto convencionales hasta editores de hipertexto o hipermedia que permitan la
bsqueda con otras facilidades para la elaboracin de los documentos, para su inclusin de componentes multimedia en los documentos (imgenes,
control, su presentacin y su utilizacin compartida por los integrantes de secuencias de vdeo, sonido) y enlaces para facilitar la navegacin por su
diferentes grupos de trabajo. En este sentido la herramienta de gestin de contenido. En este sentido, los SGD incorporan, por ejemplo, procesadores del
proyectos Project 2000 de Microsoft incluye un servicio, denominado Central lenguaje HTML (Hyper Text Markup Lenguage) utilizado en Internet para la
Project, que establece un marco de relaciones de trabajo en grupo entre los elaboracin de documentos hipermedia.
miembros del equipo de desarrollo basado en la suite de Office, tambin de
Microsoft. El ncleo que subyace a todo SGD lo constituyen los servicios de
almacenamiento, en concreto un gestor de base de datos tradicionalmente
Nuestro objetivo no es describir como se desarrolla documentacin para la relacional, aunque en la actualidad se tiende hacia la orientacin a objetos
comunicacin tcnica entre el grupo ni con la herramienta de planificacin ni como paradigma de almacenamiento (ver Martnez, 1996), considerando un
con las CASEs, sino establecer una visin general de los aportes que la documento compuesto por objetos de informacin (fotos, captulos, secciones,
industria de las tecnologas de la informacin ofrecen para la planificacin y etc.) que adems incluye informacin sobre cmo los objetos deben
gestin de sistemas informticos; por ello, a continuacin se describirn ensamblarse. Esto, adems, puede permitir el presentar despus a los usuarios
brevemente los servicios, dedicando especial atencin, en el siguiente apartado, documentos virtuales diferentes, adaptando el ensamblaje de las partes a las
a las facilidades para el trabajo corporativo (groupware), que han sido caractersticas de cada usuario. En definitiva, de lo que se trata es de
250 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 F O R M T IC O S C A P T U L O 13: LA C O M U N IC A C I N T C N IC A 251
evolucionar desde el clsico almacenamiento esttico de los documentos hacia Utilizacin de descriptores: Son trminos extrados de lenguajes
un almacenamiento que permita su composicin en el mismo momento en el documentales, tales como listas de autoridades, encabezamientos de
que van a ser utilizados por los usuarios. materias o tesauros, que permite la recuperacin de documentos a partir
de palabras que no estn presentes en el documento original.
En cualquier caso, para facilitar las tareas de bsqueda que se describen en Conexiones de hipertexto o hipermedia: Este caso, en realidad, se
el siguiente apartado, muchos fabricantes prefieren utilizar como servicio de tratara de una bsqueda manual, ya que es el usuario el que navega
almacenamiento bases de datos mixtas, denominadas ORDMS: Object por el interior de los documentos a travs de las conexiones semnticas
Relational Database Management Systems, que utilizan una base de datos que ofrecen los enlaces de este tipo.
relacional para localizar a los objetos de informacin documental situados en ndices permutados: Permite la seleccin de palabras clave dentro o
otra base de datos orientada a objetos (ODMS: Object Database Management fuera del contexto (KWIC/KWOC: Key Word In/Out Context).
System).
Otras funciones que incluyen los SGD actuales son las de gestin de
Junto con los servicios de almacenamiento de los documentos, un SGD biblioteca. Suele utilizarse este trmino para referirse a los mecanismos de
debe proporcionar servicios de bsqueda en esos documentos. Esto suele control de los documentos: de quin utiliza los documentos y qu documentos.
hacerse mediante ndices, que no son sino bases de datos con indicadores o Esto puede hacerse mediante funciones de:
localizadores que sealan el lugar dnde se almacenan los documentos. As, las
bsquedas que solicitan los usuarios se realizan en la base de datos ndice en Retencin y destruccin de documentos, estableciendo el tiempo de
lugar de hacerlo directamente sobre los documentos. En algunos casos, el mantenimiento de un documento y asegurando que su destruccin
motor o mecanismo de bsqueda es desarrollado por el propio fabricante del afecte a todas sus versiones.
sistema de gestin documental, mientras que en otras ocasiones se utilizan los Control de versiones, por ejemplo, para evitar que una nueva versin de
de otras firmas. un documento sea reemplazada por una anterior.
Seguimiento de uso, para lo cual se puede guardar informacin
El tema de los ndices es importarte porque afecta a la velocidad de las histrica asociada a cada documento, como quin trabaj con un
consultas o bsquedas y a la calidad de los resultados obtenidos: si realmente el documento y cundo, el nmero de versiones que existen de l, y quin
usuario encuentra lo que le interesa. Algunos mtodos de indizacin cre las diferentes versiones.
(tratamiento de los ndices) son los siguientes: Controles de acceso, que aseguren que slo los usuarios autorizados
puedan obtener los documentos, estableciendo, por ejemplo, diferentes
Mtodo de texto completo (Full Text): Gestiona una lista de todas las niveles de seguridad por usuario o por grupos de usuarios.
palabras significativas de cada documento, emparejando cada palabra Replicaciones, para permitir guardar copias de documentos en cualquier
con localizadores que referencian a todos los documentos en los cuales lugar de la red en la que est inmerso el SGD (por ejemplo, discos fijos,
aparecen. cintas, discos pticos, etc.).
Mtodo de las palabras clave: La lista de palabras significativas se
reduce a las consideradas como clave. Los servicios de presentacin y distribucin que debe ofrecer un SGD son
Mtodo de las palabras clave y relaciones: Complementa al anterior los que establecen la forma en que se proporciona la informacin documental a
creando adems relaciones entre ciertas palabras en el ndice los usuarios. En este sentido un SGD debera permitir la distribucin de la
(sinnimos). Por ejemplo, si el usuario busca documentos a partir de la informacin en diferentes formatos, como pginas Web en Internet, CD-ROM
palabra viajar, el sistema de bsqueda la podra relacionar con o impreso en papel. Actualmente est creciendo en importancia y popularidad
palabras como avin, hotel, etc. el concepto de impresin bajo demanda, donde un documento de una base de
Mtodo de palabras derivadas: Se busca una palabra y otras con su datos documental pblica se puede imprimir cuando lo demande el usuario que
misma raz. Por ejemplo, a partir de conducir se buscara tambin previamente habr abonado el coste correspondiente (por ejemplo, en Internet
Conductor, conducido, etc. para obtener ejemplares de publicaciones oficiales o revistas).
252 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 F O R M T IC O S C A P T U L O 13: LA C O M U N IC A C I N T C N IC A 253
Tambin es posible la utilizacin de visual izadores o herramientas capaces En los procesos de negocio porque el sistema va marcando el camino por
de presentar al usuario cualquier documento en su estructura y formato donde deben de circular los flujos de comunicacin entre departamentos desde
original, sin necesidad de adquirir las aplicaciones con las que fueron los pedidos de los clientes hasta la prestacin del servicio con todo el sistema
elaborados. Por ejemplo, para ver" un documento escrito con WordPerfect 110 de seguimiento integrado adjunto.
sera necesario disponer de este procesador de texto.
Frente a la integracin global de la ofimtica corporativa entendida como
todos los procesos de oficina porque integra todo tipo de lo que se denomina
los sistemas estratgicos.
13.5 SISTEMAS DE W ORKFLOW
Los denominados sistemas estratgicos, aplicaciones que agilizan la
En un informe del Consejo Superior de Informtica (CSI, 1996) se define realizacin de tareas en un entorno de trabajo colectivo, se caracterizan por
como sistema de flujo de Trabajo o workflow aquel que permite definir, considerar las comunicaciones y los documentos como elementos
ejecutar y gestionar procesos y tareas (unidades de trabajo) en base a unas fundamentales, y por contribuir de forma decisiva a la automatizacin de los
reglas. procesos que tienen lugar en las organizaciones. Pero lo ms destacado, no
Los sistemas de Gestin de Flujos son herramientas que permiten ayudar a las obstante, es que cada vez son ms las empresas y colectivos a quienes los
mejoras de las condiciones de negocios: normalmente un grupo de empleados sistemas estratgicos han reportado un significativo aumento de los beneficios
colaboran sobre un conjunto de objetos para producir una serie de resultados procedentes de su inversin.
especficos.
No son pocas las diferencias que separan a los sistemas estratgicos de
Existen dos vertientes de workflow, los workjlows orientado a documentos otras generaciones de aplicaciones que los precedieron, tales como los sistemas
y los workjlows orientados a grupos de trabajo. En el caso de utilizar los operacionales y las aplicaciones para el aumento de la productividad personal:
sistemas de workflow como herramientas de seguimiento de proyectos aquellos se caracterizaban por su capacidad de procesamiento de transacciones,
informticos o como herramientas de ayuda al desarrollo efectuado por un el control centralizado y la automatizacin de tareas internas (nminas, libro
grupo de trabajo nos pueden servir las dos vertientes que se encuentran mayor, etc.); stas, por centrarse en la resolucin de tareas individuales tales
desarrolladas ya que se pueden aplicar las caractersticas ms importantes de como la redaccin de una circular o la elaboracin de un presupuesto.
estos sistemas, que van desde el enrutamiento de la informacin hasta los
interfases para el intercambio de la misma factores que ayudan a confeccionar Mientras que los sistemas operacionales pueden ofrecer un informe sobre
la documentacin tcnica. los resultados de las transacciones ya procesadas, los estratgicos estn
orientados hacia el futuro en tanto que facilitan a las personas la toma de
El workflow permite manipular la informacin para incrementar la rapidez decisiones y el cumplimiento de sus objetivos empresariales. De esta forma, un
de las bsquedas en sistemas documentales, actuar sobre ella y redirigirla hacia sistema estratgico ofrece al usuario la posibilidad de explotar bancos de datos
los puntos demandantes de la misma de forma instantnea, consiguiendo una para, por ejemplo, obtener informacin sobre clientes, mantener un
alta productividad, mejor servicio al cliente, menores costes de operacin, seguimiento de la competencia, conseguir noticias sobre productos o seguir la
mejora en las satisfacciones del trabajo y mayor informacin en la toma de evolucin de un ciclo de ventas. A todo ello se suma el hecho de que, mediante
decisiones. un sistema estratgico, es posible acometer un proceso empresarial en su
totalidad, desde su concepcin inicial hasta su culminacin, siguiendo paso a
La incorporacin de este tipo de herramientas permite la implantacin paso su evolucin y notificando a quien corresponda las incidencias que se
racional del desarrollo de una compaa en dos niveles: vayan produciendo.
Los procesos de negocio Las empresas que se sirven de sistemas estratgicos cuentan con una
La integracin global de la ofimtica corporativa valiosa memoria empresarial en la que quedan almacenados, para su posterior
254 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 F O R M T IC O S C A P T U L O 13 LA C O M U N IC A C I N T C N IC A 255
Criterios cambiantes Proceso: Conjunto de tareas ordenadas, por tiempo o por unas
Integracin de sistemas condiciones contenidas en unas reglas, que son ejecutadas bien por los
Nuevas tecnologas, nuevos estndares sujetos competentes o de una forma automatizada (por autorizacin
Seguimiento de expedientes en entornos administrativos. expresa del sujeto competente). Un proceso puede tener subprocesos
hasta su descomposicin en tareas. Cada una de las ocurrencias de un
Tendramos que considerar las implicaciones que conlleva la implantacin proceso se denomina proceso especfico (en algunos casos particulares,
del workflow a nivel operativa (se pretende que los miembros de los grupos de expedientes, problema o caso).
desarrollo trabajen en entornos mas compactos, mas operativos y con mayor
informacin) y a nivel organizacin (se necesita una revisin de la situacin Proceso abierto o no reglamentado: Proceso en el que los sujetos con
real). competencia o autorizados pueden ordenar tareas, procesos
completamente definidos, asignar reglas e incluso integrar tarcas
Dentro del mbito de los sistemas de workflow se definen una serie de automatizadas de forma dinmica. Las citadas tareas, procesos y
trminos de vital importancia para la definicin de los propios flujos de trabajo reglas debern de estar catalogadas en los correspondientes
que se describen a continuacin: diccionarios.
Competencia: Condicin que define la capacidad de un sujeto para Proceso reglamentado: Proceso en el que toda la secuencia de tareas o
realizar una tarea. Las competencias pueden ser establecidas en un subprocesos, la asignacin de reglas y la correspondiente integracin de
proceso reglamentado o atribuidas en un momento concreto por el tareas automatizadas tiene un flujograma predeterminado.
sujeto jerrquicamente superior. Puede ser permanente o temporal y
puede ser ejercida por delegacin. Proceso semireglamentado: Proceso reglamentado en el que se prevn
excepciones que pueden alterarlo dinmicamente a voluntad de sujetos
Datos: Valores que identifican todos los atributos de los procesos y competentes o autorizados para ello.
tareas especficas.
256 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 F O R M T IC O S C A P T U L O 13- 1,A C O M U N IC A C I N T C N IC A 257
Notificacin y firmas
Procesos-tipo: Procesos reglamentados que pueden ser reutilizados en
procesos abiertos o semirreglamentados en la fase de diseo. Deber de A la hora de implementar en la puesta en marcha de un sistema de
estar en el diccionario. workflow se debe de considerar los siguientes aspectos:
Regla: conjunto de condiciones que regula el encadenamiento de las Cantidad de programacin necesaria para su puesta en marcha
tareas. Incorporacin de tecnologa Cliente/Servidor
Sistemas Abiertos
Regla-tipo: Reglas establecidas que pueden ser reutilizadas por los Capacidad de Personalizacin
sujetos competentes en la fase de diseo. Deben de pertenecer al Tecnologa Asociada
diccionario. Tecnologa de Bases de Datos Relacional
Tipos de procesos que admite:
Sujeto: Usuario o grupo de usuarios que tiene la competencia para o Reglamentados
realizar una tarea. Un usuario, segn los procesos, puede tener o Semi-reglamentados
atribuidas las competencias de distintos sujetos. o Abiertos
Imposicin de teoras particulares
Tarea: Unidad mnima de trabajo que, combinada con otras tareas,
constituye un proceso. Las tareas pueden ser manuales, automatizadas o Existen muchas herramientas para implementar un sistema de workjlow en.
semiautomatizadas. los entornos corporativos, con este tipo de herramientas se logra la mxima
integracin de los sistemas informticos distribuidos en ios trabajos
Tareas automatizadas: Tareas-tipo que el sistema pone a disposicin' colaborativos hasta englobar el concepto genrico de la organizacin
de sujetos para que sean realizadas por ejecucin de una regla. corporativa del trabajo que se logra con los sistemas de groupware que
trataremos en el siguiente apartado. En este tipo de entornos se aportan una
Tareas semiautomatizadas: Tareas-tipo que el sistema pone a serie de ventajas como es el hecho de que se pueden tratar los procesos
disposicin de los sujetos competentes para que sean realizadas a conjuntos; la informacin no est limitada al mbito de cada departamento,
peticin expresa y manual. seccin o aplicacin, y, por lo tanto, la informacin de la empresa puede ser
ms coherente e integrada.
Tareas-tipo: Tareas que pueden ser reutilizadas por los sujetos
competentes en la fase de diseo. Deben de pertenecer al diccionario. La solucin a los problemas planteados suele comenzar por la
informatizacin del tratamiento de los documentos relacionados con los
Tambin es importante citar, al menos, algunos procesos fundamentales de procesos. La gestin documental se puede encargar de gestionar, mediante
la tecnologa de Gestin de Flujos: informtica, los documentos de nuestra empresa a nivel corporativo.
Actualmente se tratan los documentos abriendo grandes posibilidades para la
Routing gestin de procesos de negocios. Las ventajas de procesar la Gestin
Distribucin Documental son muy claras: seguridad, accesibilidad, ahorro en sistemas de
Priorizacin archivo, distribucin y copias...
Registro de historia
Reporting Entendemos por proceso de negocio la combinacin de actividades,
Instancias o casos dirigidas a un cliente y distribuidas en el tiempo, en las que intervienen
distintas personas de la empresa. La organizacin de la empresa suele estar
Grupos y Roles
enfocada a la gestin de funciones y no a la gestin de procesos. Existe la
Reglas y condiciones
258 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 F O R M T IC O S C A P T U L O 13: L A C O M U N IC A C I N T C N IC A 259
organizacin funcional que persigue la eficiencia de los trabajadores pero no Subsistema de Gestin Documental: Control de versiones. Archivo,
existe la orgnica horizontal" que persigue la eficacia de los procesos. El Rplicas, Clasificaciones, Indexacin, Bsqueda, Distribucin,
workflow se puede aplicar por muy diversos criterios permitiendo que los Informes, etc.
procesos estn informticamente documentados para su posterior recuperacin Subsistema de Gestin de Imgenes
y tratamiento eficiente de contenidos. Subsistema de bsquedas especializadas de texto
Subsistema de Bases de Datos
El enfoque del ciclo de vida completo de solucin WorkFIow estara Plataforma del sistema:
formado por las siguientes fases: Servicios generales del sistema:
o correo electrnico
Anlisis y diseo: donde se estudian los procesos y se configura el o faxes
entorno de solucin o integrador de servicios de comunicaciones
Creacin e Integracin del sistema: en los que se desarrollan los Soporte a la heterogeneidad:
procedimientos automatizados y se integra la solucin. Soporte a nivel de desarrollo de aplicaciones a nivel C/S
Implantacin, con el objetivo de minimizar el impacto del sistema, Integracin con aplicaciones a medida existente o futuras
haciendo que los usuarios lo utilicen corno propio.
Administracin, donde se aplican unas tcnicas para asegurar que todo Para el desarrollo se deber realizar en el entorno de la plataforma
funciona correctamente. (normalmente heterogneo, y deber atender a las especificaciones definidas
por el anlisis. Es normal que la empresa tenga la necesidad de tener que
Para efectuar el anlisis de implantacin de un sistema de workflow se utilizar varios entornos de desarrollo por lo que es frecuente que casi siempre
suelen seguir las siguientes tareas: hay que buscar APIs integradores de los sistemas. El desarrollo se puede guiar
por metodologas apropiadas.
Se determinan las fronteras de la aplicacin, las iteraciones con otros
sistemas, el impacto que causar en la organizacin... La fase ms crtica se sufre en el momento de la implementacin donde se
Se determinan los subsistemas funcionales: trata de conseguir que los usuarios del sistema lo acepten como propio y lo
o Subsistema de usuarios: grupos, autorizaciones, roles... utilicen adecuadamente, minimizando el impacto negativo que pueda tener.
o Subsistema de puestos: condiciones de cada puesto y Para poder efectuar esta transicin con cierto xito es necesario una
herramientas del puesto preparacin o entrenamiento que debe de estar presente en todo ciclo de vida
o Subsistema de timing: cundo se hacen las tareas y cuanto del sistema y que consiste en la implementacin, migracin y formacin de un
tiempo cuestan. sistema normal, y, adems, debe de contar con las actividades de difusin y
o Subsistema de enrutamiento: a quin y por donde se envan los seguimiento de la utilizacin del sistema en base a indicadores previamente
datos... determinados.
o Subsistema de agenda: atiende al conjunto de tareas asignadas a
cada usuario, informando a cada usuario y administradores de Como check-list para la implantacin de una metodologa del sistema de
cada tarea a realizar, workflow podemos citar los siguientes hitos:
o Subsistema de excepciones: si algo falla pasa control al
administrador. Identificar el mbito y finalidad del Proyecto
o Subsistema de seguimiento: controla el estado de los No automatizar procesos errneos
expedientes, Desarrollar un plan de proyecto detallado
o Subsistema de Seguridad: Hacer la documentacin lo primero
La Integracin del Sistema con los subsistemas fsicos Entender a la audiencia, su problemtica
No sobrecargar a los usuarios
260 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 F O R M T IC O S C A P T U L O 13 LA C O M U N IC A C I N T C N IC A 26 1
de almacenes de documentos pblicos (normas, elementos de debate, de una empresa puede adjuntar las pginas electrnicas (almacenadas en
opiniones, etc.) que, en definitiva, permiten recoger el conocimiento y la Internet) de los peridicos del da con informacin de inters para l. En
experiencia de los miembros de un grupo, as como la creacin de foros de nuestro caso, la finalizacin de una tarea definida por el programa de gestin
discusin dentro del grupo. El paradigma actual de colaboracin lo constituye de proyectos enviada va correo electrnico con el formato apropiado servir
la red Internet, a travs de la cual un documento puede ponerse a disposicin para notificar el progreso del esfuerzo al superior jerrquico y para actualizar la
de millones de personas en todo el mundo para su consulta. base de datos del proyecto donde, automticamente, quedar reflejado el
progreso, las fechas de finalizacin, las notas sobre las posibles incidencias y,
La tercera parte del groupware est formada por las funcin de por ejemplo, los costes asociados a esa tarea
coordinacin es la que integra la comunicacin y la colaboracin en una
infraestructura global que permite la automatizacin de los flujos de trabajo en Mediante la integracin de correo electrnico con el workflow permite que
el seno de un grupo. Lo que se pretende, en definitiva, al incorporar esta la automatizacin del flujo de trabajo basada en el encaminamiento de
funcionalidad al groupware es permitir a las organizaciones tener control e documentos sirva al software de gestin de proyecto para que automticamente
incrementar la eficiencia de los flujos de documentos que soportan sus desencadene una orden de trabajo de satisfacer los esfuerzos para realizar la
negocios o actividades. siguiente tarea dentro del proyecto aprobado.
Aunque existen herramientas que utilizan por separado cada uno de estos Gracias a la integracin de bases de datos compartidas y los workflow los
modelos tecnolgicos, la potencia de una herramienta de groupware radica en participantes en un flujo de trabajo pueden consultar una base de datos
su capacidad para integrar en un entorno dinmico y transparente la compartida de seguimiento para comprobar el estado de determinados
comunicacin, la colaboracin y la coordinacin (fig. 13.2): documentos. En estos sistemas es importante poder efectuar consultas al
control de versiones donde se permite la elaboracin explcita de versiones de
documentos a partir del original, facilitando el seguimiento de las
modificaciones realizadas por varios usuarios sobre el mismo documento,
incluso de forma simultnea. Tambin los usuarios pueden incorporar a un
documento original comentarios y sugerencias particulares.
Los sistemas estratgicos han sido diseados para el "grupo de trabajo CAPTULO 14
ampliado". Bien poco han heredado los equipos de trabajo de hoy da del
carcter esttico de quienes colaboraban entre las cuatro paredes de una oficina LA GESTIN DE CONFIGURACIONES
o departamento. En la actualidad, su naturaleza es bien distinta y mucho menos
homognea. Un sistema estratgico trasciende de las barreras organizativas
internas para llegar hasta departamentos dispares, hasta tal punto que su radio
de accin abarca tambin a quienes mantienen un contacto espordico con el El objetivo del presente punto es describir la gestin de configuraciones, una
resto del grupo. En ocasiones, el alcance de los sistemas estratgicos traspasa actividad que es crtica en la gestin y mantenimiento de sistemas grandes. Se
tambin los muros de una empresa para ponerla en contacto con sus establecern las lneas maestras a considerar en la gestin de configuraciones y
proveedores, clientes y socios en un proceso empresarial unificado. se estudiarn los problemas tpicos que se suelen presentar. Finalmente se
establecer la estructura suficiente para estudiar la incidencia que pueden tener
Los sistemas estratgicos utilizan un modelo distinto de comunicacin. los cambios a efectuar dentro de la planificacin y gestin de sistemas, como
Los sistemas estratgicos dependen en gran medida de la capacidad que tengan influyen en la planificacin, cmo deben de ser controlados y como, en
sus usuarios para enviar mensajes y compartir informacin almacenada en un proyectos de elevada magnitud, conviene que se planifique, como tareas aparte,
sistema de gestin documental de fcil acceso. un grupo de personas cuya responsabilidad sea el control de dichos cambios.
Los sistemas estratgicos utilizan un modelo de gestin de la informacin A medida que progresa el proceso de Ingeniera del Software, el nmero
nico. Dichos sistemas gestionan datos semiestructurados de diversa de elementos de configuracin del software (ECS), bien sean programas,
procedencia y presentacin. Como parece lgico pensar, difcilmente podran fuente, documentos de textos de texto con documentacin sobre los
utilizarse los mtodos convencionales de almacenamiento y recuperacin de la requerimientos, pruebas, etc. crece rpidamente. Cada especificacin del
informacin de una base de datos relacional para almacenar, clasificar y sistema produce un Plan de Proyecto del Software y una Especificacin de
gestionar unos documentos tan heterogneos. La base de datos de un sistema Requerimientos del Software y, a su vez, estos documentos producen unos
estratgico gestiona las relaciones que emparentan a los documentos mediante nuevos documentos de creacin de jerarqua de informacin. Si cada ECS
vistas jerrquicas indexadas, enlaces hipertextuales entre documentos y produjera simplemente otra ECS no habra mayor problema pero
"contenedores" de objetos. desgraciadamente interviene otro factor el cambio y aparecer por cualquier
motivo en cualquier momento, de hecho Bersoff en 1980, lo seala como la
Primera Ley de la Ingeniera de Sistemas diciendo: "sin importar en qu
momento del ciclo de vida del sistema nos encontramos, el sistem a cambiar y
el deseo de cambiarlo persistir a lo largo de todo el ciclo de vida".
Por otra parte la Gestin de Configuraciones Software (GCS) es responsa puede llegar a amenazar el progreso del propio proyecto (Mack-Crane en
ble de la identificacin de los ECS individuales y de las distintas versiones del 1989).
software, de las auditorias, de la generacin de la informacin de todos los
cambios realizados. Para superar estos obstculos Victor R. Basili contribuy a fundar el
Laboratorio de Ingeniera de la Programacin, con el fin de asentar la
Cualquier discusin de la GCS plantea una serie de complejas cuestiones programacin sobre cimientos matemticos y cientficos ms firmes. En este
del tipo: sentido se han desarrollado tcnicas que aumentan en gran medida la eficacia
en el diseo e implementacin del software, aunque, a la vez, han
Cmo se identifican en una organizacin las diferentes versiones incrementado, desde el punto de vista de gestin de configuracin del software,
existentes de un programa de forma que se pueda modificar con la complejidad de los proyectos.
eficiencia?
En los grandes proyectos no slo hay que tener en cuenta su propia
Cmo controla la organizacin los cambios antes y despus de que el complejidad sino, adems, segn Lago en 1995, la debida a las nuevas
software es enviado al cliente? relaciones y los nuevos elementos introducidos por las tcnicas de desarrollo
aplicadas.
Quin tiene la responsabilidad de aplicar las distintas prioridades a los
cambios que han de resolverse? El objetivo primordial de la Gestin de Configuracin del Software (en
adelante GCS) es proponer soluciones con el fin de conseguir que un proyecto
Cmo podemos asegurar que los cambios se han realizado crezca de manera ordenada de forma que, a lo largo de su ciclo de vida, su
correctamente? gestin sea manejable. Es, por tanto, el conjunto de tcnicas y actividades
desarrolladas para gestionar los cambios a lo largo del ciclo de vida de una
aplicacin, de cara a garantizar la calidad del software y la optimizacin de su
Qu mecanismo se usa para informar al resto de la organizacin de los
desarrollo y mantenimiento (IEEE 1042 de 1987). Cuando estas tcnicas se
cambios que se han producido?
aplican al desarrollo y mantenimiento del software, incrementan la calidad del
producto, reducen el costo del ciclo de vida, evitan la duplicacin de esfuerzos
Estas y otras preguntas nos llevan a la definicin de cinco tareas
y mejoran las funciones de gestin en el proceso de desarrollo y produccin.
importantes en la gestin de configuraciones del sistema: La identificacin, el
control de los cambios, el control de versiones, las auditorias de
Para satisfacer estas necesidades, y desde el punto de vista cientfico,
configuraciones y la generacin de informacin.
podemos afirmar que la GCS debe de proporcionar la metodologa adecuada
para la realizacin de software ajustndose a las necesidades de otras
metodologas de ingeniera de software. Todo esto significa mejorar los
14.1 CONCEPTO DE GESTION DE CONFIGURACIONES: SU controles y medidas de calidad, financiacin, y planificacin en el tiempo. As
PAPEL EN EL CONTROL DE LA EVOLUCION DEL mismo, significa estandarizar mtodos para evitar la duplicacin de esfuerzos y
SOFTW ARE. permitir el fcil intercambio de informacin. En principio parece que se carga
con ms burocracia a los programadores, pero en realidad es todo lo contrario.
La cantidad de cdigo instalada en los diversos dispositivos hardware se est La aplicacin de GCS elimina, o facilita, muchas de las tareas aburridas que los
duplicando, segn Wayt Gibbs (1994), cada dos aos, esto est haciendo que, programadores ya realizan en el entorno de desarrollo de sistemas software,
por el crecimiento de los proyectos de desarrollo de software, cada vez sea ms permitindoles dedicar su esfuerzo al problema intelectual de disear y
compleja la tarea de gestin de los mismos. Cada vez hay ms elementos a construir, su verdadero trabajo. El GCS puede llevar a la automatizacin de las
tener en cuenta y con relaciones entre ellos cada vez ms complejas. El funciones de organizacin, registro de la informacin y permitir, al equipo de
crecimiento de la complejidad de gestin de un gran proyecto es tan grande que gestin, dedicarse a lo que realmente cuenta.
268 PL 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 F O R M T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 269
Los procesos para la mejor gestin de un proyecto de desarrollo de A este tipo de cuestiones nicamente se puede contestar de forma
soware, an apoyndose en metodologas efectivas como las descritas en las razonable cuando existe algn tipo de control de la configuracin pudiendo
normativas internacionales, puede ser muy laboriosa (Reichenberger, 1995). afinar en las respuestas en funcin de la informacin de la que dispongamos en
Para apoyar esta tarea, se utilizan estructuras de informacin que clarifican las cada momento. En este sentido el Instituto de Ingeniera del Software
relaciones entre las distintas entidades a gestionar. La aplicacin del lgebra de Carnegie Mellon public en 1991 un documento titulado "State-of-the-Art in
retculos para la clasificacin de conceptos es, en este sentido, muy eficaz, Environment Support fo r C M cuyo objetivo era hacer comprender la
como se estudia en el captulo tercero. importancia que tiene el papel de la gestin de configuracin dentro de un
proyecto. En el mismo se muestran resultados de una encuesta simple que
La Gestin de Configuraciones del Software es "una disciplina aplicada a muestra como se estn usando los proyectos de Gestin de Configuraciones
a direccin, vigilancia tcnica v administrativa de la identificacin y poniendo en manifiesto que para poder contestar a las preguntas anteriores ser
documentacin de las caractersticas de un elemento de configuracin, el necesario tener previstas una serie de funciones en el proceso de Gestin de
control de los cambios de estas caractersticas, el registro e informe del Configuraciones que resumimos en el siguiente esquema:
proceso del cambio y del estado de la realizacin, asi como la verificacin de!
cumplimiento de requerimientos especficos'^. La Identificacin de la Configuracin especfica:
o Componentes del producto software con su identificacin y sus
Los pioneros en aplicacin de GCS fueron las grandes compaas de atributos.
software y los equipos muy especializados con contratos en el rea de defensa o Recopilacin de estos componentes frente a sus requerimientos.
y aeroespacial. Los procedimientos que se utilizaron tendan a la complejidad,
lo que lo ha hecho inapropiados para muchos proyectos (aquellos de pequeo La Gestin de archivo y proceso de peticiones de cambio.
tamao), sin embargo, muchas de las ideas fundamentales son directamente o Verificacin de sus consecuencias tcnicas.
aplicables a proyectos de todo tipo, mejorndolas y adaptndolas a las distintas o Decisin de su aceptacin, demora o rechazo.
metodologas de trabajo. o Creacin de rdenes de realizacin en caso de aceptacin.
Una de las primeras implementaciones de herramientas para ayudar a Inspeccin de la Configuracin comprobando los cambios
gestionar la Gestin de Configuraciones (en ingls Configura! ions o Nmero total las peticiones de CR se han desarrollado
Management) fue a mediados de los setenta con UNIX y su PWB o Registro de cundo se han modificado todos los componentes
{Programmers Work Bench) que contiene el SCCS (source code control afectados
system) orientado a la gestin de configuraciones en formatos textuales. El o Informacin de cundo se ha producido un cambio no
lenguaje ADA (principio de los ochenta) no olvid disponer de un componente planificado
de Gestin de Configuraciones dentro de sus IPSE (lntegrated Project Support
Environment). Posteriormente han aparecido en algunos de los denominados Registro del estado de las configuraciones bases y prerrequisitos
entornos de programacin (por ejemplo en EPIQS)
El trmino gestin de configuracin fue originalmente aplicado a los
La forma ms simple de justificar la necesidad de la GCS se encuentra en controles de desarrollo y produccin de hardware y, posteriormente, al
las situaciones que de forma cotidiana abordan el propio desarrollo del problema del mantenimiento. En este sentido, Jones afirma en 1994 que todos
software en sus distintos entornos de produccin. Preguntas como Cundo los proyectos tienden a experimentar un cambio mensual del 1 % y cuanto ms
estar listo determinado programa?Cundo se puede corregir el error? Qu largo sea un proyecto ms cambiar su producto una vez finalizado.
versin est actualmente en uso? Cunto costar esta expansin? Qu
componentes estn involucrados y cunto costar este cambio?. Durante la breve historia de los sistemas software la falta de metodologa
de control ha conducido a muchos y muy publicitados costossimos desastres
(Gibbs en 1994), y es en respuesta a esto por lo que la GCS se ha desarrollado.
Muchas de las tcnicas han sido tomadas de las experiencias en hardware,
1 Definicin del IEEE Standard Glossary of Software Engmeering, edicin de 1990.
270 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 F O R M T IC O S C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S 271
donde una historia ms larga ha permitido establecer buenos mtodos de Identificacin de objetos en la configuracin del software
trabajo. Otras han sido producto de las especiales caractersticas de los sistemas
software. Muchas son en realidad buenas prcticas de trabajo que Analizando este problema Babich en 1986 habla del arte de coordinar el
programadores individuales aplican a su propio trabajo. Un programador desarrollo del software para minimizar la confusin que se produce en las
profesional normalmente aplica muchas de estas tcnicas a su trabajo cotidiano distintas fases del ciclo de vida del software, simplificando, controlando y
sin pensar en ello. Por ejemplo, nombra programas dejando huella de los organizando las modificaciones que se sufren en el software que construye un
cambios que ha hecho, guarda las versiones antiguas, y comprueba la precisin equipo de programacin pero esos son slo los sntomas que observamos no las
de su trabajo en puntos predefinidos. Despus, estas tcnicas han sido causas que lo producen.
extendidas y formalizadas para trabajar con proyectos complejos, que implican
a un gran nmero de personas.
Un concepto muy vinculado a la GCS es el de lneas base (baseline): una 14.2 M ANTENIMIENTO DE LA INTEGRIDAD DEL
lnea base es una referencia en el desarrollo del software que quedar marcada PRODUCTO.
por el envo del documento de configuracin del software y la aprobacin de
ECS (Elementos de Configuracin del Software) obtenida mediante una En el inicio de los tiempos de la programacin, las tareas de los programadores
revisin tcnica formal. consistan exclusivamente en codificar y depurar, sin dar importancia a disear
algo antes de desarrollarlo. En general, no se usaban modelos de programa para
Una lista de configuracin es un conjunto de ECSs identificadas por un asegurar que el resultado final se ajustase al propsito inicial, o para definir una
nombre, una versin y, opcionalmente, por unos atributos entre los que se estructura de programa prctica y mantenible.
encuentran la asignacin de la versin del producto. Es de destacar que,
normalmente, la versin tiene una estructura jerrquica. De esta forma los cambios producidos posteriormente, como han podido
ser por la adaptacin al Euro o la problemtica del ao 2000, han hecho que
Las listas de configuracin pueden estar congeladas entre dos lneas mucho viejo software sea infranqueable. Con el tiempo, cuando se acometieron
bsicas. Es ms, la tcnica que se utiliza es tratar de congelar la lista de por primera vez grandes programas, y se construyeron con aquellos mtodos,
configuracin como si se tratara de hacer una fotografa de la configuracin, resultaron pobremente estructurados. As, resultaban muy caros y, en algunos
tratando de que no salga ningn componente movido. casos, imposibles de mantener. A menudo, no se ajustaban a los requerimientos
iniciales del usuario. Con el paso del tiempo, los ingenieros aprendieron a
Como todo desarrollo es un paso entre dos estados congelados, el trabajo a desarrollar los grandes sistemas en series de etapas, cada una de las cuales
realizar se descompone en paquetes de trabajo que se entrega al equipo de GCS produce una lnea base o configuracin de referencia que es tomada como
quien devolver el paquete una vez completado, documentado y probado. plataforma para las actividades de la siguiente etapa.
En general, el responsable de desarrollo, define, planifica y controla como Segn la terminologa ANSI-IEEE el mantenimiento del software se
se realiza la GCS definiendo quin realiza esta funcin. En este sentido, y para define como el Proceso de modificar un sistema o componente software
garantizar la calidad del producto, el responsable de desarrollo realiza las despus de Ia entrega al cliente o usuario para corregir defectos, mejorar el
siguientes tareas: rendimiento o atributos, adaptarlo a un cambio de entorno o ampliar su
funcionalidad'. Una lnea base puede tomarse como un producto o
Identificacin de objetos de la configuracin del software especificacin que ha sido formalmente aprobado por los miembros del
proyecto de desarrollo y puede cambiarse slo mediante procedimientos
Control de versiones
formales de control de cambios. De una manera ms sencilla se puede tomar
Control de cambios
como una fotografa aprobada del sistema en un punto dado de su
Auditoria de la configuracin
configuracin.
Informes de estado
Observacin de estndares
272 P L A N IF IC A C I N Y G E S T I N D E SIS TE M A S IN F O R M T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 273
Un ejemplo simple puede ser el propio modelo de etapas del ciclo de vida
del soware: La etapa de anlisis de requerimientos, en la que se produce una
lnea base que establece lo que el sistema tiene que hacer. La etapa de diseo
en la que su lnea base define una estructura que se ajusta a los requerimientos.
La etapa de implementacin, que tiene por objetivo producir un sistema
terminado y la etapa de mantenimiento, que produce una sucesin de sistemas
terminados, que perfeccionan, adaptan y corrigen las lneas base previas.
Segn este modelo, la lnea base producida por cada etapa es la base para
las actividades de la siguiente etapa. Cada lnea base antes de la
implementacin del sistema es una abstraccin en la que se ignoran algunas
propiedades. Cuanto ms temprana, en la lnea de desarrollo por etapas, se
defina una lnea base, ms abstracto es el modelo que refleja. Cada etapa puede
considerarse como el proceso de transformacin de un modelo abstracto del
sistema a uno menos abstracto.
Una mejora respecto del mtodo anterior de slo codificar y depurar es el Control del cambio
modelo de etapas sucesivas que reconoce la necesidad de disear antes de
construir. Sin embargo, cada etapa no puede comenzar hasta que la anterior ha Figura 14.2 Modelo de desarrollo en cascada.
terminado, y una vez terminada, la lnea base producida no se puede cambiar.
No es esto lo que ocurre en la realidad. Habitualmente, como reconoce Bersoff Prototipos. El modelo de prototipos requiere construir el sistema varias
en 1980, los requerimientos cambian mientras se est diseando, la imple- veces. Todas las implementaciones excepto la ltima son prototipos. Para
mentacin revela errores de diseo o se encuentran mtodos ms eficaces de Brokks (1975), el propsito es establecer detalladamente los requerimientos o
conseguir los objetivos marcados. La manera de solucionarlo es retirar las investigar la factibilidad de una estrategia de implementacin a partir de un
partes inadecuadas de cada etapa y reajustarla sobre la marcha volviendo al primer sistema que, normalmente, es desechable.
paso anterior si as fuera necesario lo que constituye el modelo en cascada.
274 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 F O R M T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 275
M a n te n im ie n to
originalmente desarrollado. Por tanto, el mantenimiento adaptativo es del software por la persona que lo ha desarrollado una vez que se
tan necesario como corriente. requiere el mantenimiento.
El mantenimiento perfectivo se produce cuando el paquete tiene xito. El mantenimiento no se ve como un trabajo atractivo. Muchas de las
A medida que se usa el software, se reciben de los usuarios causas de esto vienen dadas por el alto nivel de frustracin asociado con
recomendaciones sobre nuevas posibilidades, sobre modificacin de el trabajo de mantenimiento.
funciones ya existentes y sobre mejoras en general. Para satisfacer estas
peticiones, se lleva a cabo el mantenimiento perfectivo. Esta actividad La mayora de los problemas asociados con el mantenimiento del software
suma la mayor cantidad de esfuerzo empleado en el mantenimiento del se deben a las deficiencias de la forma en que el software ha sido definido y
software. desarrollado. Aqu aparece el clsico sndrome del pague ahora o pague
despus". La falta de control y disciplina en las primeras fases del desarrollo de
En cuanto al mantenimiento preventivo, se da cuando se cambia el software casi siempre se traducen en problemas a la hora del mantenimiento.
software para facilitar una futura facilidad de mantenimiento o
fiabilidad, o para proporcionar una base mejor para futuras actuaciones. La esencia del mantenimiento es la modificacin del software actualmente
Se adecan las estructuras a nuevas metodologas que mejoran la existente. Sin embargo, la modificacin es siempre peligrosa.
capacidad del sistema de ser cambiado. Esta es una actividad Desgraciadamente cada vez que se introduce un cambio en un complejo
relativamente rara en el mundo del desarrollo de software ya que procedimiento lgico, la posibilidad de error aumenta. La documentacin del
supone un importante cambio de mentalidad en la alta direccin de la diseo y una cuidadosa prueba de regresin ayudan a eliminar los errores, pero
empresa. seguirn apareciendo efectos secundarios del mantenimiento. La obligacin del
jefe de proyecto, en este sentido, ser asegurar la integridad del producto
Entre los muchos problemas clsicos asociados con el mantenimiento de entendido como una forma de garanta de calidad como podremos comprobar
software se encuentran los siguientes: en los siguientes apartados.
No existe una documentacin apropiada o est mal preparada. Un Normalmente nos comunicamos con la mquina mediante cdigo fuente
primer paso es el reconocimiento de que el software debe ser de un lenguaje de programacin y las posibilidades de efectos secundarios
documentado, pero para que la documentacin sea de algn valor debe abundan. Aunque cada modificacin de cdigo potencialmente puede inducir a
ser comprensible y consistente con el cdigo fuente. Esto es, variar a error, los siguientes cambios tienen mayor probabilidad de inducir a error que
medida que los programas varan, y en el mismo sentido. otros:
La mayora del software no ha sido diseado previendo el cambio. A Un subprograma que es eliminado o cambiado.
menos que el diseo prevea el cambio mediante conceptos tales como Eliminacin o modificacin de una sentencia de etiqueta.
independencia funcional o clases de objetos, las modificaciones del Eliminacin o modificacin de un identificado!-.
software sern difciles y propensas a errores. Cambios para mejorar el rendimiento en ejecucin.
Modificacin de apertura o cierre de archivos.
A menudo es excepcionalmente difcil comprender un programa Modificacin de operadores lgicos.
ajeno. Si slo existe el cdigo indocumentado, es de esperar que Traduccin de cambios del diseo en importantes cambios sobre el
aparezcan serios problemas. cdigo.
Cambios sobre las pruebas de lmites.
Ese personaje ajeno a menudo no se encuentra alrededor para poder
explicarse. La movilidad de los profesionales del software es Los efectos secundarios sobre el cdigo van desde los insulsos errores que
actualmente muy grande. No podemos esperar una explicacin personal se detectan y remedian durante las pruebas de regresin, hasta los problemas
27 8 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 F O R M T IC O S C A P T U L O l-t: LA G E S T I N DE C O N F IG U R A C IO N E S 27 9
graves que pueden hacer que falle todo el sistema. El hecho es que durante el cabo, lo que un usuario ve de un sistema es en gran parte la documentacin. Si
mantenimiento, a menudo se hacen cambios sobre determinados elementos de no se reflejan los cambios del software ejecutable en la documentacin de
una estructura de dalos o sobre la propia estructura de datos. Cuando cambian usuario, los efectos secundarios estn garantizados. Por ejemplo, los cambios
los datos, el diseo del software puede no cuadrar con los datos y aparecer de formato en la entrada interactiva, si no estn adecuadamente documentados,
errores. Los efectos secundarios sobre los datos tambin aparecen como pueden producir problemas significativos. Tambin los mensajes de error no
resultado de las modificaciones sobre la estructura de informacin de software. documentados pueden causar gran confusin; tablas, ndices o texto no
actualizados pueden llevar al usuario a la frustracin y la insatisfaccin.
Los siguientes cambios en los datos a menudo producen efectos
secundarios: Los efectos secundarios sobre la documentacin se pueden reducir
substancialmente si se revisa la configuracin entera antes de lanzar una nueva
Redefinicin de constantes locales o globales. versin del software. De hecho algunas peticiones de mantenimiento pueden no
Redefinicin de formatos de registros. requerir cambios en el diseo del software o en el cdigo, sino indican falta de
Aumento o disminucin del tamao de arrays o de otras estructuras de claridad en la documentacin de usuario. En tales casos, el esfuerzo de
datos. mantenimiento se centrar en la documentacin.
Modificacin de datos globales.
Reinicializacin de indicadores de control o de punteros.
Reorganizacin de argumentos de E/S o de subprogramas.
14.3 NORM ALIZACION DE LA GESTION DE LA
CONFIGURACION.
Los efectos secundarios sobre los datos se pueden limitar, segn
Mogilensky (1994) mediante una profunda documentacin del diseo que Antes de seguir estudiando la Gestin de Configuraciones vamos a pararnos a
describa las estructuras de datos y d una referencia cruzada que asocie los efectuar unas consideraciones sobre la importancia de la normalizacin en los
elementos de datos, los registros, los archivos y otras estructuras a los mdulos procesos de la Ingeniera del Software: En general la normalizacin es una
software. actividad colectiva encaminada a establecer soluciones repetitivas. Las normas
son documentos tcnicos con la caracterstica de contener especificaciones
Tambin sobre la documentacin pueden aparecer efectos secundarios tcnicas de aplicacin voluntaria y que son elaboradas por consenso de las
cuando no se reflejan los cambios del cdigo fuente en la documentacin del partes interesadas: fabricantes, administraciones, usuarios y consumidores,
diseo y en los manuales orientados al usuario. Pasa a menudo que la centros de investigacin y laboratorios, asociaciones y colegios profesionales y
documentacin se deja para el ltimo momento. Al final, por problemas de agentes sociales. Entre las caractersticas a destacar podemos considerar que
plazos de entrega, la documentacin no es un fiel reflejo de la realidad de un estn basadas en los resultados de la experiencia y el desarrollo tecnolgico,
sistema. que son aprobados por un organismo de normalizacin reconocido y el hecho
de estar disponibles al pblico.
Siempre que se haga un cambio sobre el flujo de datos, sobre la
arquitectura del diseo, sobre los procedimientos (mdulos) o sobre cualquier Las normas ofrecen un lenguaje en comn de comunicacin entre las
otra caracterstica asociada, se debe actualizar la documentacin tcnica de empresas, la Administracin, los usuarios y los consumidores; establecen un
soporte. La documentacin de diseo que no refleje el estado actual del equilibrio socioeconmico entre los distintos agentes que participan en las
software es peor incluso que la ausencia total de documentacin. Cuando un transacciones comerciales, base de cualquier economa de mercado, y son un
examen inocente de la documentacin tcnica lleva a una determinacin patrn necesario de confianza entre el cliente y el proveedor.
incorrecta de las caractersticas del software, se darn efectos secundarios en
los consiguientes esfuerzos de mantenimiento. Para Sanll y Stoll, en 1995, la normalizacin ofrece serias ventajas tanto a
nivel fabricantes como a nivel consumidores y administracin. Para los
Para el usuario, el software slo es tan bueno como lo sea la fabricantes permite, entre otras cosas, racionalizar variedades y tipos de
documentacin (tanto escrita como interactiva) que describe su uso. Al fin y al
280 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 F O R M T IC O S C A P T U L O 14: L A G E S T I N DK C O N F IG U R A C IO N E S 281
productos, permitiendo una mejora en la gestin y en el diseo. Para los NASA D-GL-II, Software Configuration Management for Project
consumidores es conveniente porque establece niveles de calidad y seguridad Managers, National Aeronautics and Space Administration. Versin
de los productos y servicios. Las ventajas para la administracin 0.2. March, 1987.
fundamentalmente residen en que establecen polticas de calidad.
DoD-STD-2167A, Military Standard for Defense System Software
Existe una gran cantidad de organismos normalizadores de los cuales Development, Department o f Defense, June 4, 1985.
vamos a sealar aquellos de mayor relevancia dentro del campo de Ingeniera
del Software que tienen algn tipo de vinculacin con la Gestin de DoD DI-MCCR-80030A, Data Item Description for the Software
Configuraciones, entre las que cabe destacar las siguientes: Development Plan, Department o f Defense, June 1986.
IEEE. Institute o f Electrical and Electronics Engineers. Asociacin DoD M1L-STD-973, Military Standard for Configuration Management,
internacional ampliamente reconocida en la generacin de estndares. Department o f Defense.
ISO. International Organization for Standardization. Es la organizacin DoD MIL-STD-483A, Configuration Management Practices for
que desarrolla un mayor nmero de estndares mundialmente, Systems, Equipment, Munitions, and Computer Programs.
principalmente estndares tcnicos.
Como consecuencia de toda la normativa estudiada, as como los artculos
NASA. National Aeronautics and Space Administration. Organizacin y documentos tcnicos tratados, se confirma que la gestin de configuracin de
de desarrollo de proyectos espaciales, para cuyo soporte genera normas software es un trmino que cubre un conjunto de tcnicas, que cuando se
ampliamente difundidas. aplican al desarrollo y mantenimiento de software, incrementan la calidad del
producto, reducen el costo de mantenimiento durante el ciclo de vida, y
DoD. Department o f Defense o f USA. Organizacin militar mejoran las funciones de gestin para el proceso de desarrollo y produccin.
estadounidense que genera y divulga importantes normas para su
funcionamiento. Segn las normas expuestas el propsito de la GCS es proporcionar la
metodologa para la realizacin de software ajustndose a las necesidades de
De las normas anteriores hemos realizado una recopilacin de algunas de otras metodologas de ingeniera de software. Esto significa mejorar los
ellas, de amplia utilizacin profesional en la Gestin de Configuraciones controles y medidas de calidad, financiacin y planificacin en el tiempo3.
Software, a fin de evaluarlas y elaborar una serie de directivas y documentos Tambin significa estandarizar mtodos para evitar la duplicacin de esfuerzos,
esquemticos dirigidos a una rpida y cmoda puesta en prctica de sus y permitir el fcil intercambio de informacin. En principio parece ms
contenidos. burocracia sobre los programadores, pero en realidad es justo lo contrario. La
aplicacin de GCS elimina o facilita muchas de las tareas aburridas que los
IEEE Std 828-1990, IEEE Standard for Software Configuration programadores ya realizan en el entorno de desarrollo de sistemas software,
Management Plans, American National Standards Institute, 1990. permitindoles dedicar su esfuerzo al problema intelectual de disear y
construir, que es su verdadero trabajo, aplicando controles para garantizar que
IEEE Std 1042-1987, IEEE Guide to Software Configuration el proyecto est trascurriendo dentro de sus dominios de definicin. Puede
Management, American National Standards Institute, 1987. llevar a la automatizacin de las funciones de organizacin, registro de
informacin (cosas que las mquinas hacen muy bien y los humanos muy mal)
NASA Sfiv DID 04, Software Configuration Management Plan Data
Item Description, National Aeronautics and Space Administration,
3 W. Gibbs, en su artculo Soflware's Chronies Crisis, publicado por la Scientific American en
Version 3.0, October 15, 1986.
septiembre de 1994 (y traducido a la filial espaola Investigacin y Ciencia en la misma fecha),
describe algunos proyectos software plagados de cambios de requerimientos cuya gestin puso
en peligro la realizacin de los mismos.
2 82 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 F O R M T IC O S C A P T U L O H : L A G E S T I N DE C O N F IG U R A C IO N E S 283
y permitir al equipo de gestin dedicarse a lo que realmente importa. Los tres en particular, la espera para la aprobacin de un cambio no debe ser un cuello
principales conjuntos de controles a los que normalmente se aplica son: de botella.
Tcnico: La necesidad de proporcionar ciertas funciones que implican Incluso despus del desarrollo, un sistema software no permanece estable:
el conocimiento de ciertas restricciones tcnicas. se encuentran errores que hay que arreglar, hay peticiones de mejoras, etc.
Durante este periodo, que normalmente es mucho ms largo que el tiempo de
Financiero: La necesidad de mantener ciertos presupuestos financieros desarrollo, los responsables del sistema tienen que estar cambiando cosas, y
y de plazos de entrega para el proceso de desarrollo, y producir al final para las que no cambian, es peor, ya que la memoria se desvanece. En estas
un sistema con algunas restricciones de precio. circunstancias, si las incidencias no mucho mayores que errores se registran,
los cambios estn controlados, todos los cambios estn registrados y se hacen
Calidad: Asegurar que la calidad del desarrollo satisface las hackups, la documentacin se mantiene coherente con el estado actual del
necesidades del usuario y permitir un proceso de produccin y software. En el caso de cambios mayores, el trabajo se puede considerar como
mantenimiento eficiente. volver a desarrollar, y la metodologa de desarrollo es igualmente aplicable.
Durante mucho tiempo estos controles se han considerado separados, pero Uno de los problemas de trabajar con software es que no hay entidades
en realidad interaccionan. Por ejemplo, se pueden reducir los costos financieros mensurables suficientemente aceptadas que se puedan usar para observar el
bajando los requerimientos tcnicos o reduciendo la calidad (y por tanto progreso o la calidad entre la concepcin inicial y el resultado final del
posiblemente, aumentando los costos de produccin y de mantenimiento). En proyecto. De hecho aunque se pueda probar la existencia de un sistema final,
muchos sistemas software que funcionan correctamente, ya existen mtodos de su calidad o la medida en que se ajusta a las especificaciones iniciales es difcil
control operativos. El propsito de GCS no es sustituir alguno de ellos, ni de demostrar, y en algunos sistemas, imposible de demostrar de manera
aadir ningn control nuevo, sino proporcionar una metodologa simple que concluyente.
ayude a la operacin de esos controles, coordinarlos, y evitar o reducir la
sobrecarga de los gestores de proyecto. A lo largo de los aos se han diseado muchas tcnicas para aproximarse a
la mensurabilidad del software. Uno de las ms importantes es el concepto de
lneas base o configuracin de referencia.
14.4 ESTABLECIM IENTO I)E LNEAS MAESTRAS. Una lnea base es un punto base o de referencia en el esquema de trabajo
de desarrollo del proyecto cuya consecucin puede ser demostrada
La base fundamental de la GCS es la lnea base o configuracin de referencia: objetivamente. Tiene tres funcionalidades que debe dar:
Un hito en el proceso de imple mentacin de un producto, contra el que se
puede medir el progreso, y que forma una base para futuras actividades. Puesto Punto de progreso mensurable
que es una base para el progreso futuro, debe ser tan firme como se pueda Rase para el posterior control y desarrollo
conseguir. De aqu la necesidad de congelar las especificaciones y versiones Punto de medida para evaluar la calidad y el grado de ajuste a las
del sistema en ciertas etapas. No obstante, como la naturaleza del desarrollo es especificaciones antes de que se termine todo el sistema.
impredecible, y los desabolladores son humanos, puede aparecer la necesidad
de alterar esa base firme en posteriores etapas. Cada cambio debe hacerse slo Para conseguir estos propsitos, cada lnea base debe marcar un paso
despus de considerar las posibles consecuencias, y una vez hecho, hay que definido en el progreso desde las especificaciones iniciales hasta la aparicin
distribuirlo a todas las personas responsables implicadas. El sistema que del sistema deseado, ya concluido, y an despus, ya que debe servir para la
controla estas operaciones se llama normalmente control de cambios, y se ha posterior evolucin del sistema ya en servicio.
utilizado durante aos en el desarrollo y produccin de hardware. Es muy
importante que el sistema de control de cambios no sea demasiado burocrtico, De cara a conseguir que cada lnea base d una plataforma slida sobre la
que seguir construyendo, el final de una fase de desarrollo y el principio de la
284 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 C A P T U L O 14 LA G E S T I N D E C O N F IG U R A C IO N E S 285
siguiente, viene determinado por la aceptacin de la lnea base. La forma en Las verificaciones requeridas para demostrar el logro de las
que se acepta cada lnea base vara en cada fase del desarrollo, pero los caractersticas funcionales y de interfaz que se especificaron.
criterios de aceptacin deben ser los mismos en lodos los casos: la nueva lnea
base debe ajustarse a las restricciones impuestas por las lneas bases previas, y Esta lnea base consiste en dos tipos distintos de documentos:
las siguientes lneas base, con el sistema final que implican, deben ser
alcanzables. Especificaciones de los elementos mismos. Estas especificaciones
describen cada uno de los requerimientos esenciales (funcin, diseo,
La aceptacin de una lnea base implica que el cdigo o la documentacin restricciones y atributos) de los elementos de configuracin de
aprobados se pueden congelar para formar una plataforma slida para las software. Una especificacin por cada elemento.
prximas operaciones. Sin embargo, puesto que las actividades humanas no
son nunca perfectas, debe existir la posibilidad de introducir modificaciones en Documentos de requerimientos de interfaz. Son en la prctica las
las especificaciones. Un sistema de gestin de software debe tener en cuenta especificaciones de requerimientos de interfaz, que identifican las
esta posibilidad, pero debe tambin asegurarse de que los cambios se hacen con interfaces entre los elementos de configuracin. Recopilando todos los
la misma cantidad de investigacin de las consecuencias, y con el mismo nivel requerimientos de interfaz en un solo documento se evita la confusin y
de autorizacin que tena la aprobacin original de la lnea base. la duplicacin de tener esta informacin en cada elemento de
configuracin.
En la prctica, se establecen una serie de lneas base para permitir un flujo
ordenado del trabajo de desarrollo. Normalmente se establecen cuatro lneas Los elementos individuales que componen una lnea base de asignacin se
base en cada proyecto: funcional, de asignacin, de configuracin de desarrollo establecen normalmente a lo largo de sucesivas revisiones de las
y de producto. especificaciones de cada uno de los elementos de configuracin. Desde un
punto de vista de gestin de configuracin lo ms importante es que estas
La lnea base funcional es la documentacin inicialmente aprobada que revisiones se hagan de una manera controlada y responsable.
describe las caractersticas funcionales del sistema, y la verificacin requerida
para demostrar el logro de esas caractersticas funcionales. Esta es la lnea base La lnea base de configuracin del desarrollo est formada por el software
inicial que se establece en un proyecto y, normalmente, consiste en las que proporcionan los responsables del desarrollo y la documentacin tcnica
especificaciones del sistema, un documento que define las caractersticas de lo asociada, que define el entorno de un elemento bajo desarrollo. Est bajo el
que todo el software tiene que hacer. El trmino funcional se usa porque esta control de configuracin del responsable del desarrollo y describe la configu
lnea base describe las funciones que el sistema, actuando como un todo, tiene racin de software en cada etapa de diseo, codificacin y pruebas. Est
que cumplir. La lnea base funcional es una parte del acuerdo formal entre el establecida para facilitar el control de las actividades internas de desarrollo.
usuario y el desarrollador. Normalmente se establece en el momento de la
adjudicacin del contrato. Partiendo de esta lnea base, en posteriores esfuerzos Normalmente estas lneas bases se establecen de manera incremental. Cada
de diseo, se divide el sistema en los distintos elementos software que lo elemento se incluye en la lnea base cuando es revisado con otros. La razn es
configuran. que se hace mucho esfuerzo en las revisiones de elementos, y esto se refleja en
los acuerdos conseguidos con otras partes del equipo de desarrollo. La lnea
La lnea base de asignacin es la documentacin inicialmente aprobada base de configuracin de desarrollo se establece normalmente con los
que describe: documentos de diseo de alto nivel, en el momento de las revisiones
preliminares de diseo. Los documentos de diseo de detalle se procesan de la
Las caractersticas funcionales y de interfaz de los elementos misma manera: y los elementos fuente, objeto y ejecutables se aaden despus
designados desde los elementos de configuracin de alto nivel. del trmino de sus respectivas fases de pruebas.
Los requerimientos de interfaz de los elementos que se interrelacionan.
Las restricciones de diseo. La lnea base de producto es la documentacin inicialmente aprobada que
describe las caractersticas funcionales de los elementos de configuracin, las
2 86 PL 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 F O R M T IC O S ______________________________C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S ___________________287
caractersticas de interoperabilidad, las caractersticas funcionales Cmo podemos dar soporte para trabajos en cadenas de desarrollo
seleccionadas para sealar las pruebas de aceptacin en produccin. Incluye el paralelo?
cdigo software, un medio de almacenamiento masivo junto con el resto de
elementos (documentacin, herramientas software, etc.) de cara a asegurar que Qu mecanismos se utilizan para avisar a los otros de los cambios
el cdigo puede ser reproducido y mantenido. Esta lnea base se establece que se han realizado?
cuando se completan las pruebas de aceptacin del sistema. Reemplaza el resto
de lneas base, y normalmente se entrega al cliente de una manera formal. Estas cuestiones nos llevan a la definicin de cinco tareas que debe realizar
un sistema de gestin de la configuracin, que estudiaremos en detalle a
continuacin:
La identificacin de configuracin proporciona los medios para aislar los vista es que puesto que es software diseado para integrarlo en un dispositivo
elementos que constituyen un sistema como base para el control. La funcin hardware, debe ser tratado de una manera distinta y separada para evitar
normal demandada es la de establecer un agente bibliotecario encargado de equvocos.
controlar los movimientos de los archivos, mantenerlos en su lugar
correspondiente y almacenar y organizar documentos importantes desde el Software externo (categora III). Este es el software que ya existe y que
punto de vista de su posible recuperacin en cualquier punto de su ciclo de viene proporcionado y mantenido por un vendedor. Esta categora incluye
vida. sistemas operativos, sistemas gestores de bases de datos relacinales,
herramientas de gestin de configuracin, etc.; esto es, todo el software que se
Hay tres aspectos que se deben tener en cuenta: primero, dividir el sistema compra para apoyar el desarrollo de las otras categoras.
en un nmero de partes conocidas y gestionables; segundo, estas partes deben
estar inequvocamente nombradas; y tercero, puesto que las partes cambian a lo Documentos de gestin (categora IV). Este software es el desarrollado
largo del tiempo, las versiones deben identificarse perfectamente. El primer para apoyar la aceptacin formal de las categoras I, II, y III. Incluye
aspecto est encuadrado en el proceso de especificacin, anlisis y diseo, las manejadores de pruebas, datos de pruebas, todo el software que rodea la
otras dos, requieren la aplicacin de rigurosos estndares. ejecucin de las pruebas de aceptacin, as como los programas de anlisis
usados por el equipo de pruebas para reducir los datos de pruebas y tener
Es obviamente necesario que un sistema completo tenga una nica resultados significativos. En muchos casos no se consideran necesarias las
identificacin y, por lo tanto, se pueda distinguir entre las distintas versiones pruebas sobre la categora III. Esto se debe a que el propio vendedor es el que
del sistema que puedan existir. Cada versin puede haber seguido varios pasos se ocupa de las pruebas de aceptacin de sus productos.
hasta la versin final, o alternativas ajustadas a distintos clientes en distintos
lugares. Puesto que es lgicamente necesario, es imprescindible que stos Software de apoyo al producto (categora V). Es software que se desarrolla
tengan identificadores nicos, siendo lo ms comn identificarlos por los para apoyar el proceso formal de produccin de las categoras I, II y IV, pero
nmeros de versin. se identifica formalmente como un producto. Suele incluir herramientas de
comprobacin de estndares, y los ficheros de comandos usados para compilar,
Los diferentes tipos de software tienen diferentes tipos de requerimientos enlazar y cargar el software de las categoras I y II.
de identificacin (y control). Por tanto, uno de los pasos en la identificacin
debe incluir la definicin de categoras de software. Una posible categorizacin La identificacin tambin incluye la tarea de designar las
del software puede ser la que sigue: responsabilidades de la propia identificacin. Normalmente para las categoras
que son objeto de desarrollo esa responsabilidad recae sobre quin, despus,
El producto software tiene la responsabilidad del desarrollo y del mantenimiento.
Los componentes de un producto firm w are
Software externo En cuanto a la forma de denominar a cada elemento de la configuracin se
Informacin de gestin recomienda utilizar nombres que definan algn tipo de codificacin
Software de apoyo al producto altoparlante de tal forma que sugiera el tipo de elemento al que se refiere
bien con vinculacin al proyecto, bien con vinculacin al desarrollo, o ambas
El producto software (categora I). El software ha de ser desarrollado incluidas (en este sentido podramos denominar como ASI003 al tercer
como producto final, o como parte de un producto final. Para algunas documento de Anlisis de Sistemas de Informacin definido en Mtrica v.3).
organizaciones es aqu donde el proceso termina. Para otras esto es slo la cima
de un iceberg, y hay que definir ms categoras. La identificacin del proyecto y de la versin se puede realizar con la
misma estrategia anterior, por ejemplo anteponiendo el identificador CONTA
Los componentes de un producto firnnvare (categora II). Este es el al proyecto de contabilidad, y posponiendo el nmero de versin o variante al
software que se desarrolla para integrarlo en un producto final firmware. Un final del nombre del elemento separado con un guin (por ejemplo el elemento
punto de vista es tratarlo como si de software normal se tratase. Otro punto de
290 ____________________ 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 F O R M T IC O S _________________ C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 291
CONTA.ASI2. l:003-v3.2 liara referencia al tercer documento de anlisis de En el entorno de desarrollo de software los elementos tienen
requisitos del proyecto CONTA en su versin 3.2). necesariamente que ser cambiados. En un mundo ideal, una vez que un
elemento est completamente aprobado no es necesario cambiarlo. En el
Es importante considerar que los elementos de la configuracin se mundo real se necesitan nuevas versiones por muy variadas razones:
encuentran ligados unos a otros bien por los recursos4 que necesitan o por el
nivel de realizacin (por ejemplo un programa objeto depende de su programa Los requerimientos del sistema cambian. El mercado para un producto
fuente y del compilador que se haya empleado) y que en su totalidad se puede cambia o los requerimientos para un sistema ya acordados cambian.
definir una red de dependencias entre elementos de la configuracin. En este
sentido surgirn interrelaciones entre objetos: habr objetos bsicos y objetos Los lmites entre elementos en la jerarqua de diseo cambian. La
compuestos o agregados y la identificacin del objeto de configuracin interfaz que se relaciona con un elemento cambia y tiene que ser
tambin debe considerar las relaciones entre los objetos implicados: se crea una renegociada. Esto supone cambios en las especificaciones, y por lo
jerarqua de ECSs. tanto en la implementacin, y nuevas pruebas.
4 Los recursos son entidades que proporciona, procesa, referencia o son requeridas por el objeto
(C H O I).
292 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 F O R M T IC O S C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S 293
cam bio de ingeniera (OCI). La OC1 describe el cambio a realizar, las res
tricciones que se deben respetar y los criterios de revisin y auditoria.
Una vez que el ECS se convierte en una lnea base, aparece el control de
cam bios a nivel proyecto. Ahora, para hacer un cambio, el encargado del
desarrollo debe recibir la aprobacin del gestor del proyecto (si el cambio es
local) o de la ACC (si el cambio impacta en otros ECS). En algunos casos se
dispensa de generar formalmente las peticiones de cambio, los informes de
cambio y las OCI. Sin embargo hay que evaluar la realizacin de cada cambio
y seguir la pista y revisar todos los cambios.
5 Jones comenta en su libro "Assessment and Control o f Software Risk" que los grupos de 6 En la obra de Boddie titulada "Crunch Mode: Building Effective Systems on a Tight Schedule
control de cambio, entendidos como la autoridad que los aprueba, son efectivos frente a los se comentan casos muy interesantes relacionados con los grupos que ostentan la autoridad del
cambios de requerimientos en grandes proyectos. cambio.
294 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 F O R M A T IC O S C A P T U L O 14: L A G E S T I N D E C O N F IG U R A C IO N E S 295
Se puede construir otro agente con las funciones de vigilante, encargado sus fuentes. Por un principio similar el estado de un elemento compuesto es el
de asegurar que los archivos sean accedidos nicamente por las personas que del elemento componente de menor aprobacin. No tiene sentido poner bajo
tengan una determinada autorizacin. revisin un elemento que no est congelado. De la misma manera, no tiene
sentido aprobar una configuracin que contiene elementos que no han sido
Es verdad que el control de cambios requiere que se haga algo ms que aprobados.
codificar: Precisa que se trabaje de una manera responsable y disciplinada que
contribuya a la consecucin de los objetivos del equipo. Un poco de burocracia
es, sin embargo, un precio pequeo para conseguir los beneficios que el control Control de versiones
de cambios asegura:
Otro paradigma de la gestin de configuraciones consiste en la necesidad
Hay un procedimiento bien definido para la peticin de un cambio y la de mantener dos o ms versiones de una aplicacin por necesidades de la
realizacin de dicho cambio si finalmente se aprueba. organizacin. El problema de la precisin para mantener los cambios en ambas
versiones origina la necesidad de un control de versiones.
La realizacin de un cambio aprobado se puede planificar teniendo en
cuenta su importancia, su impacto y los recursos que necesita. El trmino versin se debe de explicar como una instancia de un sistema
que difiere de otra instancia en una serie de cualidades. Sera normal considerar
En principio, el cambio de un elemento no tiene efectos secundarios que no tiene sentido mantener dos versiones simultneas por lo que vamos a
adversos inesperados. ilustrar algn ejemplo en el que se evidencia la necesidad de mantener ambas
versiones: Existe una versin de Microsoft Word 6.0 en Windows y otra en
El estado de aprobacin de una peticin de cambio, y del elemento al DOS, lo mismo ocurre con FoxBase, que adems tiene versiones en Unix y
que se refiere, queda siempre documentado. para Mac, y con muchos otros productos existentes en el mercado. Su
fabricante considera importante mantener en el mercado, de forma simultnea,
En la figura 14.6 se describe de manera muy sencilla el ciclo de vida de todas las versiones del producto y necesita controlar los cambios, ya que
una versin de un elemento software. alguna de las rutinas internas del producto sern comunes y otras no.
porque hay configuraciones en servicio que hacen uso de ellos. Si en una de variaciones para varios sistemas operativos. Los diferentes sistemas
estas versiones obsoletas de un sistema que an est en servicio ocurre un error operativos proporcionan los mismos servicios de distinta manera.
no detectado hasta el momento, hay que ser capaz de reconstruir el error, sin
necesidad de desplazarse hasta el domicilio del cliente que lo detect, para Variacin para pruebas y depuracin. A menudo se hacen variaciones
investigar el error y descubrir las implicaciones sobre otros elementos del para satisfacer las necesidades particulares de los programadores que
sistema y sobre las versiones posteriores del elemento y del sistema. Tambin desarrollan o mantienen un mdulo. Una variacin de un mdulo puede
puede ocurrir que una nueva versin resulte no ser mejor, a pesar de todo, que incluir volcados de datos y rastreos (traces ), que ayudan a la
la versin a la que sustituye porque no se ajusta estrictamente a las necesidades depuracin, pero que no se incluyen en lo que efectivamente se manda
del usuario o porque contiene ms errores. al cliente.
Versiones congeladas versin de traba o Variacin de los requerimientos del usuario. Hay muchos programas
que son utilizados por muchos y muy distintos clientes. Si un sistema
de nminas se ha de utilizar en pases distintos, entonces debe
comunicarse con los usuarios en los distintos idiomas nacionales. El
sistema debe ser capaz tambin de tener en cuenta las distintas
Figura 14.7 Sucesivas versiones de un mismo elemento. legislaciones laborales y fiscales de cada pas (ejemplo en la figura
14.8).
Habitualmente la secuencia de revisiones se referencia con un nombre del
elemento seguido de un nmero incremental que refleja el orden en que han
sido creadas.
As pues, suele existir para cada elemento una secuencia de revisiones que
se suceden a lo largo del tiempo, para las que es imprescindible saber el orden
de precedencia cronolgica que guardan y tambin las modificaciones que
introduce cada una de ellas, para poder seguir su evolucin.
Hp Qp
Existen herramientas en el mercado para el control de configuraciones
Figura 14.12 Versiones de la documentacin de usuario. cuando existe software que depende de una versiones s y de otras no, este
software en forma de herramienta est pensado para los desarrolladores y
La versin 2 de la documentacin de usuario comprende la versin 2 de la asegura la consistencia con el cdigo comn en todas las versiones del
gua, la versin 6 del manual de referencia y la versin 3 del manual de producto, es decir, asegura la fase de considerar el software que es diferente en
instalacin. Despus de la versin 3, se necesitan variantes de la cada versin y la fase de construccin de dichas versiones.
documentacin para UNIX y para VMS, que en realidad slo afectan al manual
de instalacin. Los sistemas ms populares para controlar estas situaciones son el SCCS
(Source Code Control System) debido a Rochkind en 1975 en su primera
Hay que hacer notar que una nueva versin de un elemento compuesto no versin y desarrollado originalmente para IBM-370 aunque en la actualidad se
significa necesariamente nuevas versiones de todos sus componentes. Este es el puede encontrar en cualquier UNIX. Otra herramienta popular es el MAKE
caso de la versin 2 de la documentacin de usuario, que contiene dos debido a Feldman en 1979 que permite el mantenimiento de versiones en modo
elementos que no han sido modificados desde la versin anterior, la versin 2 arbolescente.
de la gua y la versin 3 del manual de instalacin. Tampoco una nueva versin
de un elemento es necesariamente incluida en una nueva versin del elemento Dentro de los avances del control de versiones se han creado lenguajes de
compuesto, como es el caso de la versin 3 de la gua y la versin 4 del manual interrelacin de mdulos (LIMs) que permiten construir automticamente
de instalacin, que no han sido nunca incluidos en ninguna versin de la cualquier versin del sistema siempre y cuando se hayan definido las
documentacin. relaciones pertinentes, tales como:
Una distincin importante entre los elementos es si unos han sido Dependencia: Cualquier otro tipo de relaciones entre ECS,
derivados de otros mediante una herramienta o si son construidos fundamentalmente en la documentacin y requisitos.
manualmente. Un elemento que se construye por un proceso automtico desde
otro elemento se llama elemento derivado. El que se construye manualmente Derivacin: A partir de qu ECS se ha originado otro elemento.
sin partir de otro se llama fuente. Ejemplos de elementos derivados son los
mdulos objeto, que se derivan del cdigo fuente usando un compilador, y los
302 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 F O R M T IC O S ______________________________C A P T U L O 1-1 LA G E S T I N DE C O N F IG U R A C IO N E S _______ ________ 303_
Equivalencia: Cuando un determinado ECS est almacenado en lugares consistencia con otros ECS, las omisiones o los posibles efectos secundarios.
diferentes, pero todas las copias corresponden al mismo elemento. Se debe llevar a cabo una revisin tcnica formal para cualquier cambio que no
sea trivial.
Composicin: Cuando un ECS est compuesto de otros ECS.
Una auditoria de configuracin del software complementa la revisin
Variante: Modificaciones sobre un determinado ECS que no cambian tcnica formal al comprobar caractersticas que no tiene en cuenta la revisin.
su funcionalidad. La auditoria se plantea las siguientes cuestiones:
Sucesin: En la historia de cambios sobre un ECS desde una revisin a Se ha hecho el cambio especificado en la OCI? Se han
otra. incorporado modificaciones adicionales?
Igualmente se pueden crear grafos de evolucin (Gustavsson en 1989) para Se ha llevado a cabo una revisin tcnica formal para
cualquier objeto. Puede ser muy til definir un grafo de evolucin para cada comprobar la correccin tcnica?
ECS. Este grafo describe la historia de cambios de un objeto y su transicin de
unas versiones a otras (ver figura 14.14). Se han seguido adecuadamente los estndares de ingeniera del
software?
Objeto 2.0 Objeto 2.1
F igura 14.14 G rafo d e evolucin de ECS. Se han seguido procedimientos de GCS para sealar el cambio,
registrarlo y divulgarlo?
Existen herramientas informticas para ayudar en la tarea de Se han actualizado adecuadamente todos los ECS
identificacin. En algunos casos se disea una herramienta para mantener las relacionados?
copias mas recientes y en otras herramientas se restan versiones para llegar a
la versin deseada. En algunos casos, las cuestiones de auditoria se incluyen en la revisin
tcnica formal. Sin embargo, cuando la GCS es una actividad formal, la
auditoria de la GCS se lleva a cabo independientemente del grupo de garanta
Auditoria de la configuracin de calidad.
La identificacin y el control de cambios ayudan al equipo de desarrollo de Hay tres tipos distintos de auditorias que se pueden hacer:
software a mantener un orden sobre los cambios, que de otro modo llevaran a
una situacin catica y sin salida. Sin embargo, incluso el mecanismo ms Auditoria funcional de configuracin. El propsito de una auditoria de
conecto de control de cambios vigila, rastrea e informa los cambios hasta que este tipo es validar que el desarrollo de un elemento de configuracin se
se ha generado la OCI. Cmo podemos asegurar que los cambios se han ha completado satisfactoriamente, y que el elemento a conseguido las
realizado correctamente? La respuesta es doble: 1) revisiones tcnicas caractersticas funcionales y de rendimiento especificadas.
formales, y 2 ) auditorias de configuracin del software. Normalmente se hacen despus del ciclo de desarrollo, una vez
completadas las pruebas de los elementos desarrollados.
Las revisiones tcnicas formales se centran en la correccin tcnica del
ECS que ha sido modificado. Los revisores evalan el ECS para determinar la
304 P L A N IF IC A C I N Y G E S T I N DF. S IS T K M A S IN F O R M A T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 305
14.6 M D U L O S E IN TE R FA C ES.
Sobre un caso ms general, no siempre es tan fcil, ni conviene, separar
Una vez conocidos los problemas que plantea el mantenimiento del software y funciones tan claramente como en el caso anterior. Entonces se construyen
a la luz de la normativa y prcticas de uso existentes en la comunidad cientfica mdulos que constan de dos partes diferenciadas:
y profesional, pasamos a analizar algunas de las tcnicas ms dominantes.
La interfaz, que es la parte del elemento que es visible a los otros
De la lectura de la bibliografa, por ejemplo Software Configuraron elementos. Especifica precisamente las caractersticas del elemento que
Management de Berlack, y de la intuicin de la experiencia, se deduce que un los otros elementos necesitan conocer. Est escrupulosamente prohibido
equipo de desarrollo trabaja mejor cuando todos los miembros tienen un describir en esta parte aspectos que no conciernen a los otros elementos.
conocimiento suficientemente amplio del trabajo de los otros. Desa
fortunadamente, la intuicin no es a veces la mejor gua. De hecho, para El cuerpo del elemento, que no es visible a los otros. Todas las
muchos aspectos del desarrollo de software el mnimo conocimiento lleva al decisiones sobre como conseguir el propsito del elemento, estn
mximo progreso. ocultas al resto en esta parte. El cuerpo de un elemento se puede
cambiar libremente siempre y cuando se mantenga consistente con su
Supongamos que un programa de gestin de almacn tiene que hacer muy interfaz.
frecuentes accesos a una base de datos que contiene la informacin que
necesita. La base de datos tiene unas funciones especiales de acceso Dividir un elemento en interfaz y cuerpo permite restringir todas las
desarrolladas por una persona distinta a la que desarroll el primer programa. dependencias de un elemento a las dependencias de su interfaz. Es la interfaz la
Puesto que una parte importante del tiempo de proceso se usa en las funciones que hace las llamadas a otros mdulos, y es nicamente ah, donde se crean las
de acceso a la base de datos, se acuerda no utilizar las rutinas de acceso y dependencias (ejemplo en figura 14.16).
acceder directamente a los campos que necesita en la base de datos, para lo que
el programador de las rutinas proporciona toda la informacin referente a la
O tros in terfa ce s y cuerp os Interfaz
base de datos al programador del programa de gestin de almacn. Cada vez Otros in te rfa c e s
que hay un cambio en la estructura de la base, no solo hay que cambiar las cuerpo
rutinas de acceso, sino que tambin hay que cambiar el programa de gestin de
almacn. Esta situacin puede ser mantenible si slo ocurre en unos pocos Figura 14.16 Dependencias entre mdulos divididos en cuerpo e interfaz.
casos y estn bien coordinados. En el momento en que empieza a ocurrir con
frecuencia se hace inevitable que en algn cambio de la estructura de la base de Como ya se vio, la interfaz puede ser un archivo distinto o integrarse en el
datos, alguien no se entere, o que se le olvide cambiar su programa. mismo que el cuerpo del elemento. La decisin depender del tamao y la
Inevitablemente ocurren errores. Para Choi y Scacchi este es el tpico problema complejidad de la interfaz. La interfaz de un gran subsistema est normalmente
de doble mantenimiento. separada del proceso porque es una parte muy importante y merece la pena
gestionarla por separado. No cambia tan a menudo como el elemento que
El conocimiento de la estructura de la base de datos est presente en ms forma el cuerpo del subsistema, pero cuando lo hace afecta a otros subsistemas.
de un sitio (las rutinas de acceso propias, y cada uno de los programas que Por otro lado, la interfaz de un procedimiento que ordena una matriz de enteros
acceden directamente). Cuando uno se cambia, han de cambiarse todos. La es muy pequea; probablemente es mejor incluirlo en el mismo archivo del
divergencia, y por tanto el error, es inevitable7. El problema es que los cuerpo que mantener los dos archivos distintos relacionados entre s.
programas de gestin saben demasiado de la estructura de la base de datos.
Deberan llamar a las funciones propias de la base de datos, y no acceder Las interfaces se definen en la fase de diseo de manera que se puedan
directamente. El conocimiento de la estructura de la base de datos debera estar intercambiar las versiones de un elemento. El diseo comienza con todo el
en un solo sitio, las rutinas de acceso que le son propias. proyecto visto como una sola entidad. Sus interfaces lo son con el mundo
exterior y se les llama requerimientos funcionales. Los requerimientos
7 Este tipo de problemas los examina Paul Carroll en su artculo "Creating new software iras funcionales definen lo que el software debe hacer.
agonizing ta sk fo r m itch kaporfirm", publicado en The Wall Street Journal (11/5/1990).
30 8 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 IM F O R M A T IC O S C A P T U L O 14: L A G E S T I N DE C O N F IG U R A C IO N E S 30 9
El diseo de un mdulo se puede expresar con un dibujo como el de la Las interfaces entre mdulos se pueden dividir en dos tipos bsicos:
figura 14.17. El diseo empieza con una caja que representa el mdulo, lneas interfaces de llamada e interfaces de datos:
salientes que representan las interfaces que debe encontrar. La caja est vaca
mostrando que la impleinentacin no est diseada. Una interfaz de llamada permite a un mdulo invocar a una rutina en
otro mdulo. Existe entre el mdulo que define la subrutina (el
llamado) y el mdulo que contiene la llamada a la subrutina (el
Mdulo llamador) una relacin de dependencia. El llamado proporciona un
servicio al llamador, por ejemplo un clculo, un salvado o retorno de
datos.
Figura 14.17 Mdulo sin su estructura diseada.
Una interfaz de datos describe datos que son accedidos por ms de un
El diseo de la implementacin se expresa entonces (figura 14.18) con mdulo. Si slo un mdulo referencia los datos, entonces la definicin
cajas ms pequeas que representan submdulos. Las lneas que los unen es parte de la implementacin del mdulo. Una interfaz de datos
representan las dependencias entre submdulos. describe datos compartidos, variables globales estructuras de datos,
ficheros en disco o cinta, as como entradas y salida extemas.
Cada vez que una interfaz cambia, todos los mdulos dependientes deben
ser revisados para asegurar que son compatibles con el cambio. Cuantos ms 14.7 E L E M E N T O S D E D ISEO.
mdulos implicados, ms personas implicadas, y por tanto mayor es la
312 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 F O R M T IC O S C A P T U L O 14: LA G E S T I N DE C O N F IG U R A C IO N E S 313
Algunas veces es til considerar el sistema entero como una unidad, por muchos elementos distintos. Para poder planear y gestionar un proyecto
ejemplo cuando se va a enviar al cliente. Otras veces es apropiado considerar se debe partir en paquetes de trabajo cada vez ms pequeos de manera
un simple procedimiento como una unidad, por ejemplo cuando un que la estructura de la jerarqua del sistema y la del equipo de trabajo
programador tiene que reformar un procedimiento independientemente del vaya paralela.
resto del sistema. Los elementos forman una jerarqua en la que un elemento
compuesto consiste simplemente en unas listas de elementos componentes. En En la figura 14.21 se muestra parte de una jerarqua de elementos de un
alguno de estos casos ese considera que es una configuracin de un sistema o sistema de gestin de base de datos (SGBD).
de un subsistema.
para incluir elementos que son apropiados para trabajar en Unix o en cualquier depende del cdigo fuente. Un cambio a un elemento fuente requiere
otro sistema operativo. nuevas versiones de elementos que se derivan de l. Por definicin, un
elemento derivado 110 se puede cambiar directamente. La dependencia
Los elementos que son parte estrictamente de la jerarqua se llaman de un elemento con los elementos desde los que ha sido derivado se
elementos de diseo. Un elemento de configuracin no es en general un llama dependencia de construccin.
elemento de diseo.
Cada vez que un elemento de cdigo llama a otro, el elemento que
Debe existir un limite de cunto se ha de descomponer un sistema. En llama es dependiente del que es amado. Si un programa A llama a otro
lneas generales, un software que puede ser til modificarlo programa B, entonces A es dependiente de B, y no puede cambiarse sin
independientemente del resto, debe ser considerado como un elemento. Si no tener en cuenta las necesidades de B; pero no viceversa.
hay suficiente descomposicin, puede ocurrir, que para un pequeo cambio se
tenga que hacer una nueva versin de un elemento muy grande, o que no sea La documentacin de usuario y el cdigo de un sistema son
posible seleccionar diferentes combinaciones de elementos para construir dependientes el uno del otro. Estos dos elementos se han de mantener
diferentes configuraciones. Sin embargo, si el sistema est descompuesto en en paralelo; ninguno de ellos se puede evaluar ni cambiar sin el otro.
elementos demasiado pequeos se hace innecesariamente complicada la
gestin. Hay pues que llegar a un compromiso en el grado de descomposicin Los elementos derivados no deben confundirse con elementos binarios. Un
del sistema. elemento de texto puede ser derivado, por ejemplo el cdigo C producido por
un preprocesador de C++. Inversamente, un elemento binario no tiene que ser
A la hora de hacer un cambio, es necesario evaluar el impacto que tendr necesariamente un elemento derivado, por ejemplo, un procesador de textos
la implementacin de dicho cambio antes de acometer su diseo. Hay que normalmente incluye bytes de control que describen el formato del texto, pero
identificar y gestionar las mltiples versiones que un cambio genera. Los a pesar de todo, es un elemento fuente.
cambios son difciles de gestionar porque los elementos dependen unos de
otros. Un cambio aparentemente menor a un elemento se puede propagar a los Algunas veces no es obvio si un elemento es derivado o no. Es el caso de
elementos que dependen de l directa o indirectamente, de manera que al final, un proyecto que tiene un formato estndar de cdigo fuente definido por una
hay que hacer cambios a lo largo de todo el sistema. plantilla. Para escribir un nuevo programa, un ingeniero primero copia la
plantilla y despus rellena los blancos. Este elemento es actualizado
Formalmente, un elemento X es dependiente de otro elemento Y si cuando manualmente y debe ser por lo tanto tratado como un elemento fuente. Sin
ocurre un cambio en Y, se requiere un cambio en X para que X permanezca embargo se construye inicialmente copiando una plantilla, que no se puede
correcto; si X requiere una versin compatible de Y para que X cumpla sus volver a crear por un proceso automtico.
propsitos entonces X es dependiente de Y. Si X no es dependiente de Y,
entonces Y puede cambiarse arbitrariamente sin afectar a la correccin de X. De una misma fuente pueden nacer muchos elementos derivados.
Dependiendo de las instrucciones que se marcan a la herramienta que lo
Las dependencias surgen entre distintos tipos de elementos: construye, y de la herramienta que lo hace, pueden salir elementos
sustancialmente diferentes. Un caso tpico es la compilacin del mismo
La implementacin de un elemento es dependiente de sus programa para distintos requerimientos de entorno tales como sistemas
especificaciones. Un cambio a las especificaciones probablemente operativos, requerimientos de memoria, etc. (ejemplo en figura 14.22).
requerir cambiar la implementacin. Las especificaciones 110 dependen
de su implementacin, ya que la correccin de las especificaciones se
evala independientemente de su posterior implementacin.
El depurado tradicional incluye un anlisis de lo que el programa debera Las opciones y argumentos que se dan a la herramienta para conseguir
hacer segn las especificaciones, lo que hace realmente al ejecutarlo y el el objetivo deseado, y cul es ste; por ejemplo las opciones de
listado del cdigo. Pero muchas veces una manera ms rpida de encontrar el compilacin.
error no es el anlisis del programa mismo, sino analizar las variaciones que ha
sufrido, esto es, analizar la historia del programa. Tras la historia de un La razn por la que un argumento, dato u opcin se introduce en la
elemento se pueden esconder multitud de errores que no lo son en si mismo, herramienta.
sino que lo son en funcin de la coordinacin con el resto de elementos.
Tambin se pueden detectar ms fcilmente los errores en el propio programa, Mantener la historia de un elemento es tambin til para mejorar el
ya que si se puede relacionar el momento en que empez a dar problemas con rendimiento de un entorno de desarrollo. Por ejemplo, en algunas instalaciones
el momento de la implementacin de un cambio, nos proporciona una pista se manejan innumerables elementos de un mismo proyecto. Esto genera
muy clara de en que parte del cdigo est el error. problemas de espacio en disco para la identificacin de componentes de las
distintas configuraciones. As, los elementos ms antiguos, o que menos uso
Si se es capaz de relacionar el inicio de los problemas con algn cambio en tienen, se eliminan fsicamente de los soportes de almacenamiento masivo.
alguna parte del sistema, la labor de anlisis no ya slo del elemento en Pero esto no significa que se pierdan, puesto que aunque sean de versiones muy
cuestin, sino de su relacin con el resto de elementos, incluso con los que antiguas pueden ser requeridos en cualquier momento para reproducir un error
aparentemente no la tiene, se hace mucho ms directa. de una instalacin que utiliza una versin muy atrasada del producto. Para
reproducir el entorno se toman los ficheros fuente y se vuelve a compilar y
Una manera sencilla de mantener la historia de un elemento es incluir la linkar siguiendo las instrucciones que marca la historia de cada elemento en
informacin conveniente en la cabecera del elemento. As los elementos irn
31 8 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 F O R M T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 319
Por otro lado, no es econmicamente rentable recompilar enteramente un El IEEE Std. 828-1998, por otra parte, establece los contenidos mnimos
proyecto en un proceso que puede durar horas de tiempo de un ordenador. Hay que deben aparecer en el Plan de Gestin de la Configuracin Software. Dicho
pues que llegar a un compromiso entre el espacio de almacenamiento ocupado plan puede ser un documento aislado o formar parte de otro documento (por
y el tiempo de ordenador ocupado en la reconstruccin. ejemplo, el plan del proyecto o el plan de calidad). Este estndar est elaborado
segn el siguiente contenido:
Esta misma tcnica de borrado selectivo con reproductibilidad se utiliza
tambin con los archivos fuente. Para ahorrar espacio de almacenamiento se 1. Introduccin. Este punto proporciona una visin simplificada del plan y
tienen siempre disponibles las ltimas versiones del elemento. Las anteriores se especifica:
reconstruyen restando las diferencias, llamadas deltas, convenientemente
1.1 Propsito: necesidad del plan y su audiencia.
almacenadas con su nmero de secuencia, el responsable, la fecha y el motivo
del cambio. 1.2 Alcance: campo de aplicacin y limitaciones.
1.3 Definicin de trminos clave utilizados en el plan.
1.4 Referencias: estndares, procedimientos y documentos relacionados.
14.8 PLAN DE GESTION DE LA CONFIGURACIN DEL
SOFTW ARE. 2. Gestin de la GCS. En este punto se asignan responsabilidades para cada
actividad de la gestin de configuracin. En detalle:
Segn Mtrica V3 en su interfaz de gestin de configuracin el objetivo de esta
2.1 Organizacin: unidades organizativas relacionadas y relaciones entre
actividad es definir el Plan de Gestin de Configuracin para los requisitos de
ellas y externas.
configuracin establecidos y especificar el entorno tecnolgico de soporte a la
gestin de configuracin. Los aspectos que debe contemplar el plan son: 2.2 Responsabilidades GCS: asignacin de actividades a cada unidad
organizativa.
Identificacin de todos los productos que deben ser controlados, su 2.3 Polticas, directivas y procedimientos aplicables: restricciones externas
clasificacin y relaciones entre ellos, as como el criterio o norma de al plan que hay que considerar.
identificacin.
3. Actividades de la GCS. En este punto se detallan las funciones y tareas
Ubicacin y localizacin de los productos. requeridas por el plan, que son:
3.1 Identificacin de la configuracin, dividida en tres tareas, establece
Definicin del mbito y alcance del control de la configuracin,
tcnicas y herramientas de identificacin, manipulacin y libreras:
describiendo los procesos incluidos en l.
3.1.1 Identificacin de ECSs.
3.1.2 Nombrado de ECSs.
Definicin de las reglas de versionado de los productos y los criterios
3.1.3 Adquisicin de ECSs.
de actuacin para cada caso, teniendo en cuenta el motivo por el cual se
realiza el cambio de versin. 3.2 Control de la configuracin, define procedimientos, documentacin y
niveles de autoridad para la gestin del cambio de lneas base, con las
Definicin del ciclo de estados para cada tipo de producto y los criterios siguientes tareas:
de trazabilidad entre los mismos. 3.2.1 Peticin de cambios.
3.2.2 Evaluacin de cambios.
Descripcin de funciones y responsabilidades. 3.2.3 Aprobacin o desaprobacin de cambios.
320 P L A N IF IC A C I N Y G E S T I N D E S IS T EM A S IN F O R M T IC O S C A P T U L O 14: LA G E S T I N D E C O N F IG U R A C IO N E S 321
Mantenimiento de un historial de cambios. Cada vez que se realiza una RCS garantiza la continuidad del proyecto.
revisin, RCS almacena automticamente el autor, fecha y hora,
adems de una descripcin de los cambios realizada por el autor cuando Provee un alto nivel de visibilidad de la gestin. As, es fcil seguir el
se registra la nueva versin. estado de un proyecto software porque provee un completo historial de
cambios y graba quin hizo qu, cuando y a qu versin de qu mdulo.
Resolucin de conflictos de acceso. Cuando dos o ms usuarios desean
modificar la misma versin, la aplicacin RCS alerta a los RCS es totalmente compatible con las herramientas existentes de
programadores y previene una modificacin incompatible con otra. desarrollo de software. RCS no obstaculiza, su interfaz al sistema de
ficheros es tal que todas las herramientas software existentes pueden ser
Organizacin de las distintas versiones en estructura de rbol. Esto usadas como antes.
permite mantener abiertas (modificndose) varias lneas de desarrollo
simultneamente. Cada lnea estara representada por una rama del El interfaz bsico de usuario de RCS es simple. Para su manejo basta
rbol. con dos comandos. Las facetas ms sofisticadas han sido llevadas hacia
avanzados entornos de desarrollo software.
Permite unir varias versiones: Si las versiones afectan a la misma parte
de cdigo, RCS alerta sobre tal circunstancia. RCS simplifica la distribucin software si los clientes mantienen
cdigos tambin con RCS. Esta tcnica asegura una identificacin
Se pueden marcar determinadas versiones de diferentes documentos adecuada de versiones y configuraciones, y el seguimiento de las
con nombres (claves) simblicos, lo que permite referenciar al conjunto modificaciones de los clientes.
completo de todas ellas como una configuracin.
Otras herramientas, Jasmine, por ejemplo10, funcionan en base a una
Se identifica automticamente cada revisin con: nombre, nmero de descripcin textual y as se modela el inventario de los componentes del
revisin, hora de la revisin, autor, etc. La identificacin hace simple sistema, la estructura, la configuracin, la forma de construir la aplicacin, las
determinar que revisiones de que mdulos concuerdan con una pruebas... La definicin textual, en forma de lenguaje de control de
configuracin determinada. configuraciones, involucrar relaciones, dependencias, prioridades en la
construccin y reglas de verificacin; permitiendo el uso de tmplales o
Minimiza el espacio necesario en disco para el almacenamiento de esqueletos previamente construidos para facilitar la descripcin del sistema
todas las versiones. RCS necesita poco espacio extra para las versiones completo.
(slo almacena las diferencias entre las versiones en forma de deltas,
cambios elementales entre ficheros de texto) de forma que slo se Otro ejemplo puede ser la forma de funcionamiento de Rational que, como
almacena de forma completa la ltima revisin. muestra Feiler en 1988, se enfoca principalmente hacia el trabajo por
subsistemas entendidos como interfaces ms implementaciones; los
RCS mantiene un completo historial de cambios. As, una persona componentes son invisibles una vez que se ha efectuado la exportacin del
puede encontrar que le sucedi a un mdulo fcil y rpidamente, sin subsistema. Permite recompilaciones entre subsistemas.
tener que comparar las listas de cdigo y sin tener que preguntar a sus
compaeros. Otras herramientas, como por ejemplo DSEE, hacen hincapi en el pool de
objetos derivados para ser compartidos. Introduce el concepto de BCT (Bound
RCS realiza la grabacin automtica de propietarios. Configuraron Thread) donde se almacenan todos los detalles asociados con
cada objeto, desde versiones de fuentes, herramientas, descripciones, fechas,
RCS almacena todos los cambios automticamente.
10 Vease el artculo de Marzullo de 1986 titulado Jasm ine: A Software System M odelling Fa-
cility", donde se anuncian sus funcionalidades.
324 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 F O R M T IC O S C A P T U L O 14- LA G E S T I N DE C O N F IG U R A C IO N E S 325
personas involucradas, comentarios... El usuario indica las propiedades de por l en la localizacin de todos y cada uno de los componentes. Adems, la
derivacin deseadas y OSEE usa, de forma automtica, un objeto que debe de interfaz grfica le deber mostrar el grafo de las distintas versiones a partir de
existir. la realizacin de ese bug en todo tipo de configuracin.
CCC (Softool, 1987), por ejemplo, separa fases y responsabilidades Para restaurar los ficheros puede ayudarse de las funciones estndar de
modelando las tareas, las transiciones y generando, finalmente, un data flow. cualquier sistema de Gestin de Configuraciones, que puede completar con un
Un protocolo de actuaciones aprueba las transiciones entre estados y el ciclo de sistema automtico de reparto de carga si estamos tratando sistemas
vida queda almacenado va actividades en los diferentes estados de la distribuidos.
configuracin.
LIFESPAN es un verdadero ayudante para generar modelos de procesos Mantenimiento de cdigo reutilizable.
para realizar los cambios, para ello cuenta con una coleccin configurable de
formularios en lnea como los de Informes del Rendimiento del Software, El mantenimiento del cdigo reutilizable es una de las actividades en las
Diseo de Cambios y el Informe del Estado del software. Tambin cuenta con que las organizaciones empiezan a invertir ei tiempo de los miembros de
una batera de herramientas para el control de tareas, roles y estados; entre los desarrollo. Se trata de seguir la poltica de desarrollar las aplicaciones en torno
que convendra destacar el Anlisis del Impacto del Cambio, Personas a un cdigo principal que se utiliza repetidamente en otras muchas
afectadas por el Cambio, Descripcin y modelos de la aprobacin de los aplicaciones.
cambios,...
Cada da las empresas de desarrollo miran su software como un activo a
proteger, activo o actividad productiva que debe de estar continuamente
gestionado y que puede ser reusado para obtener un mayor nivel de beneficios.
14.10 RENTABILIDAD DE LA GESTIN DE LA Esto hace necesario entender que la reutilizacin de los distintos mdulos sea
CONFIGURACION. una actividad fuertemente conectada con las herramientas de mantenimiento
automatizado del software.
Del anlisis de las herramientas destacamos a continuacin aquellos aspectos
que ms nos han llamado la atencin en cuanto a rentabilidad inmediata de la Para Adams y otros, las herramientas automticas pueden ayudar a
aplicacin de Gestin de Configuraciones: mantener el software con una alta calidad, muy rpidamente y con un bajo
coste, siempre que la mentalidad de los directivos acepte la necesidad de
herramientas potentes en este sentido, siendo necesario el control de las ver
Regeneraciones de componentes. siones generadas por estos componentes reutilizados porque estos mdulos
evolucionan a lo largo del tiempo, bien porque se solucionen algunos errores o
El grupo de desarrollo necesita que la herramienta integrada de Gestin de bien porque se adaptan a nuevas necesidades. Si bien los beneficios que aporta
Configuraciones permita regenerar, de una forma ordenada y segura, cualquier la estructura de cdigo reutilizable es clara, la gestin de estos objetos es
versin anterior de una aplicacin en cualquier nivel de desarrollo. De esta tediosa si no se dispone de una herramienta integrada en el entorno de trabajo
forma puede explorarse un error descubierto en una cierta versin para que nos ayude en el trabajo de saber que versin de estos componentes tiene
asegurarse si afecta o no a cualquier otra versin en explotacin. incorporada cada versin de la aplicacin.
Con este tipo de caractersticas un desarrollador que se encuentra El entorno debe efectuar la labor de agente para ayudar al desarrollador a
trabajando en una aplicacin sobre una cierta configuracin al da de la fecha, propagar los cambios a todas las ubicaciones adecuadas11 y, bajo la supervisin
al que se le informa de un error usando otra versin de la misma aplicacin,
puede conocer las diferentes versiones de los componentes incluidos en aquella 11 Vase la obra de Whitgift: Methods and Tools for Software Configuraron Management,
versin y actuar sobre el componente concreto, dejando que el sistema trabaje donde se aporta informacin, en su momento novedosa, en aspectos de integracin de 'la GG il
la base de datos del proyecto donde se aplican las herramientas CASE.
3 26 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 F O R M T IC O S C A P T U L O 14: LA G E S T I N DE C O N F IG U R A C IO N E S 327
de los responsables, obtener nuevas versiones, tanto de cdigo fuente como Generacin de versiones especificas para clientes.
ejecutable, de las aplicaciones construidas con estos objetos.
Otro tipo de problemas importantes son las necesidades que tienen
Para que esto sea posible la herramienta deber almacenar en su determinadas organizaciones para satisfacer los requisitos de los clientes que
repositorio una sola copia de cada versin de un componente reutilizable ms exigen pequeas variaciones a los programas generales para satisfacer
una referencia a cada aplicacin que utilice este componente concreto. De esta necesidades especficas de sus procesos de negocio.
forma, mientras que un grupo de desarrollo congela una versin para someterla
a pruebas o evitar errores, otro grupo puede seguir efectuando el La forma de trabajar tpica hasta el momento es tener diferentes libreras
mantenimiento sobre este cdigo reutilizable. de trabajo, una por cliente, y efectuar las modificaciones necesarias en cada
una de las distintas libreras de trabajo. Con el empleo de una herramienta de
Apuntando a este tipo de componentes, la empresa puede implementar gestin de versiones de elementos reutilizables se pueden crear proyectos
procesos de reingeniera en Ingeniera del Software, entendida como el proceso diferentes, pero indicando que parte de los archivos son compartidos y cuales
de examinar un sistema de software existente y/o modificarlo con la ayuda de son especficos, de modo que un componente comn se pueda modificar de
herramientas automticas para: forma automtica para todos los clientes en sus diferentes versiones.
Mejora de los sistemas de seguridad al poder detectar, con la propia El objetivo de este captulo es describir los procesos necesarios para que el
automatizacin, el software intruso, gracias a una gestin de control a director del proyecto pueda medir y garantizar la calidad del software
travs de una lista, del software autorizado. producido como una labor ms en su gestin del proyecto.
Mtodos de optimizacin de la gestin de la distribucin en grandes La garanta de calidad del software (o SQA, Software Quality Assurance)
sistemas, al permitir incluir tasas de transferencia de informacin es una actividad de proteccin que se aplica en todo el proceso de ingeniera
relativas al trfico normal de gestin y disear una distribucin del del software. Corresponde a muchos en la organizacin, a los ingenieros de
software en cascada para reducir la carga de la red. software, a los gestores de proyecto, clientes, comerciantes, personas del grupo
de desarrollo, pero la responsabilidad de la gestin de proyectos exige el
Resumiendo, podemos enumerar una serie de factores que sera necesario control y garanta de la calidad del software desde el punto de vista tcnico y
automatizar desde la propia herramienta de Gestin de la Configuracin como del cliente.
son: la Gestin del Inventario software y hardware, la entrega del software a
distribuir, la gestin de la propia distribucin y actualizacin del software con La planificacin de la calidad es una actividad presente en todas las
acuses de recibo, la gestin de licencias, el registro de los distintos organizaciones de software, que establece y desarrolla los objetivos y
acontecimientos que puedan suceder y la posible auditoria. requisitos de la calidad y su aplicacin (ISO 8402). Asimismo, es necesario que
la direccin exprese formalmente una poltica de calidad que abarque todas las
directrices y objetivos de la empresa relativos a la calidad. Todas estas,
Administracin de informacin hipcrniedia cambiante. funciones estn encuadradas en la gestin de calidad (UNE 66-001).
En este sentido Stan Magee y Leonard Tripp12 en 1999 presentan una gua A lo largo del tema veremos en detalle el concepto de calidad, su
de estndares y especificaciones para el diseo de software en WEB. evolucin histrica y algunos trminos relacionados, como control de calidad,
garanta de calidad, gestin de calidad y sistemas de gestin de calidad.
Por otra parte el ISOC ha propuesto un estndar (RFC2215) donde Determinaremos los factores que influyen en la calidad del software y tcnicas
pretende establecer unos parmetros generales para la caracterizacin de asociadas a la calidad del software: revisiones, validaciones, verificaciones y
elementos integrados en los servicios de red. pruebas. Estudiaremos las mtricas de la calidad del software, las normas y
estndares existentes y los contenidos del plan de calidad del software.
Veremos, despus, el modelo CMM (Capacity Madurity Model) para el control
del grado de madurez de las organizaciones en el desarrollo del software. Por
ltimo entraremos en un tema, que est cobrando una gran relevancia: el papel
12 Leonard L. Tripps, graduado en Matemticas y doctor por la Universidad Brigham Young, de la documentacin en la calidad del software como elemento integrador.
actualmente es el presidente de la IEEE Computer Society.
33 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 F O R M T IC O S C A P T U L O 15: LA G A R A N T A D E C A L ID A D 331
profesionalmenle". Segn la definicin anterior los fundamentos con los que se 8402). Estos sistemas deben estar suficientemente respaldados por la
mide la calidad son los requerimientos del sistema y la no concordancia entre alta direccin y tener el alcance suficiente, en medios y recursos, para
estos puntos es una deficiencia de calidad, por eso las actuales metodologas de conseguir los objetivos de calidad. Actualmente, es muy comn ligar
desarrollo de sistemas insisten en la garanta de calidad desde los primeros estos sistemas a las clusulas contractuales o vinculantes en la
requerimientos funcionales. Esta definicin, adems, enfatiza dos puntos: los valoracin de la calidad. Los sistemas de gestin de calidad
estndares definen un conjunto de criterios de desarrollo y que existen habitualmente incluyen:
requerimientos implcitos que no se mencionan como, por ejemplo, el deseo de
que un programa sea fcil de mantener y de depurar. 1..Enfoque de gestin de calidad.
2. Tecnologas de IS (mtodos y herramientas).
Segn el estndar IEEE 610-1990 la calidad del software es el grado con 3. Revisiones Tcnicas Formales durante el proceso de software.
el que un sistema, componente o proceso cumple los requerimientos 4. Estrategia de pruebas.
especificados y las necesidades o expectativas del cliente o usuario. El grado 5. Control de la documentacin del software y de cambios.
de la calidad del software alcanzado actualmente no es el ptimo, de hecho, las 6. Procedimientos que aseguren un ajuste a los estndares de
organizaciones desarrolladoras de software, plantean problemas muy comunes, Sistemas de Informacin.
como la falta de planificacin, la desorganizacin, la primaca del parche a lo 7. Mecanismos de medicin y generacin de informes.
hecho ayer sobre como mejorar mi trabajo de hoy, el trabajo personal y
artesanal, la falta de una ngenierizacin de la produccin de software, etc. De
hecho hay porcentajes muy elevados de proyectos software que no cumplen
con los requisitos deseados (en torno al 90% de los sistemas utilizados) o que 15.2 FACTORES DE CALIDAD DEL SOFTWARE
no se entregan o fracasan (alrededor del 30% del los sistemas desarrollados).
Conviene sealar los factores que determinan la calidad del software, trminos
Para resolver estos problemas surge la Ingeniera del Software con nueva introducidos por McCall en su libro Factors in Software Quality, donde
fuerza incorporando a los procesos del ciclo de vida del software la gestin de ofrece el significado de cada uno de ellos:
la calidad y a las tcnicas y herramientas a utilizar durante el proceso los
sistemas de calidad del software: Correccin /.Hace lo que se peda en los requisitos?
Fiabilidad Se ejecuta sin fallos todo el tiempo?
La gestin de calidad determina y aplica la poltica de la calidad, los Eficiencia Se ejecuta en ptimas condiciones de
objetivos y las responsabilidades utilizando la planificacin de la uso de tiempo y recursos?
calidad, el control de la calidad, la garanta de calidad y la mejora de la Integridad Es seguro? Puede acceder personal no
calidad. Es responsabilidad de todos los niveles ejecutivos, pero debe autorizado?
estar guiada por la alta direccin. Su realizacin involucra a todos los Facilidad de uso Puede ser utilizado fcilmente y posee
miembros de la organizacin y debe tener en cuenta tambin criterios documentacin de uso?
de rentabilidad. Flexibilidad Es fcil modificarlo?
Facilidad de prueba Se puede probar en todas sus
El aseguramiento de la calidad es el conjunto de acciones planificadas y posibilidades?
sistemticas que son necesarias para proporcionar la confianza Facilidad de mantenimiento Sus caractersticas permiten adaptarse
adecuada de que un producto o servicio satisfaga los requisitos dados fcilmente a los cambios (comprensin,
sobre calidad (UNE). modularidad, etc.)? Es fcil detectar y
corregir un error?
Los sistemas de gestin de la calidad incluyen una estructura de la Portabilidad Es posible usarlo en otro entorno?
organizacin, de responsabilidades, procedimientos, procesos y Reusabilidad Se puede reutilizar alguno de sus
recursos que se establece para llevar a cabo la gestin de calidad (ISO componentes?
334 P L A N IF IC A C I N Y G E S T I N DE SIS T E M A S IN F O R M T IC O S C A P T U L O 15: L A G A R A N T A D E C A L ID A D 335
Facilidad de interoperacin. Tiene capacidad para relacionarse La fiabilidad se calcula midiendo la frecuencia de los fallos y su
fcilmente con otros sistemas? importancia, la bondad de los resultados obtenidos, el tiempo medio
entre fallos, la posibilidad de recuperarse a los fallos y la facilidad de
McCall, en su estudio de estos factores, se centra en tres aspectos predecir los resultados del software.
importantes de un producto software y agrupa los factores en tomo a ellos:
Tanto el modelo de McCall como el de Grady, presentan adems mtricas
Caractersticas operativas, corresponde a los cinco primeros factores. precisas que permiten cuantificar cada uno de los factores presentados.
Capacidad de soportar los cambios, corresponde a los tres factores
siguientes. Existen muchos otros estudios de factores que influyen en la calidad del
Adaptabilidad a nuevos entornos, corresponde a los tres ltimos software y se actualizan constantemente en funcin de las tcnicas y
factores. metodologas que aparecen. La figura 15.2 muestra el resultado del estudio
realizado por el Grupo de Trabajo sobre Calidad del Software de la Asociacin
Por otra parte, Pressman da ms importancia a las mtricas de calidad, a la de Tcnicos de Informtica (ATI), que divide los factores en dos grandes
forma de asegurar que se cumplen los factores, y los clasifica en dos grandes grupos: operativos y de adaptabilidad, desarrollando, adems, las
grupos: caractersticas de cada no de los factores.
Otra lista de factores de calidad es la desarrollada por Grady y Caswell en Factores Operativos
su libro Software Metrics: Establishing a Company-Wide Program. Los
factores y sus atributos correspondientes son los siguientes: |Inteqridad| |Exactitu| jlnteroperabilidadl |VerJci
La funcionalidad es funcin de las caractersticas y posibilidades del -/Auditoria .. Completitud -M odularidad No deficiencia
software, las funciones que proporciona y la seguridad de todo el -Segu rid ad -Consistencia -Conformidad -Tolerancia a fallos
sistema. - Visin Global -Trazabilidad Disponibilidad
Amigabilidad
Figura 5.2 Detalle de los factores que influyen en la calidad de! software.
Con revisiones tempranas
fcilmente dos aspectos en el software, por un lado la solucin software o el Total 783
producto y, por otro lado, al uso que se haga del software o la satisfaccin de
las necesidades del usuario del software. Estos dos conceptos se han
Sin revisiones tempranas
consignado como la dualidad Verificacin y Validacin. La verificacin se
Fase en la que se Numero de errores Coste de Correccin Total
refiere al conjunto de actividades que aseguran que el software describe encontro el errror encontrados por error
correctamente lo operacin que realiza. La validacin se refiere a un conjunto Antes de la prueba 22 6.5 143
de actividades que aseguran que el software construido se ajusta a los
Durante la pnieba 82 15.0 1.230
requerimientos del cliente. Boehm lo establece de la siguiente forma:
Tras la implantacin 12 67.0 804
Verificacin Estamos construyendo el producto correctamente? Total 2.177
( )
La seguridad del software examina de que forma los fallos producen 1) Si este sistema fa lla tina vez a la semana y p o r dicho fallo no est operativo
condiciones que pueden llevar a accidentes. El anlisis del rbol de durante 3 horas (tiempo de solucin del problema), calculamos:
fallos es un modelo grfico para determinar los estados del sistema ( ,
peligrosos que pueden conducir a accidentes. Una vez estudiados los Tiempo medio entre fallos: <
riesgos se debe crean una lista adicional de requerimientos diciendo lo 90 = 87 (horas funcionando hasta un fallo) + 3 (horas de resolucin del fallo) (
que NO debe de suceder para garantizar la seguridad del sistema. Existe
otra disciplina que puede llevarnos a error que es la seguridad entendida Disponibilidad:
como privacidad y proteccin de la informacin. 96 65% = 100 * (87 / 90)
Debemos establecer, antes de continuar, la definicin de fallo. Qu es un 2) Si falla dos veces a Ici semana con los mismos tiempos, calculamos:
fallo?: Un fallo es cualquier falta de concordancia con los requisitos del ( ,
software. Cmo son los fallos?: Los fallos tienen un amplio abanico de Tiempo medio entre fallos: ( , \
posibilidades: de leves a graves, desconcertantes o catastrficos, de correccin 45 = 42 (horas funcionando hasta un fallo + 3 (horas de resolucin del fallo) < . )I
inmediata con pequeo esfuerzo o con necesidad de mucho tiempo y un gran
esfuerzo. Hay que tener en cuenta, adems, que la correccin de un fallo puede Disponibilidad:
producir nuevos fallos con bastante probabilidad. 93 35% - 100 * (42 /4 5 )________________________________
Una forma de medir los fallos del software son los modelos de fiabilidad Por ltimo sealar que algunas mtricas de calidad se basan en el coste de (
del software. La mayora de los modelos de fiabilidad relativos al hardware son calidad, que es aquel que se deriva de las actividades relacionadas con la (
debidos al desajuste que a fallos de diseo o al desgaste de los componentes calidad. De este coste forman parte los costes preventivos (establecimiento y (
fsicos y no sirven para el software donde ocurre lo contrario. Los modelos de seguimiento del plan de calidad, formacin, medios, etc.), de evaluacin
fiabilidad del software predicen la fiabilidad en funcin del tiempo de (revisiones, inspecciones, pruebas, etc.) y de fallos (anlisis de errores y
calendario o en funcin del tiempo de CPU. Una sencilla medida es el tiempo reparacin, litigios con el cliente, soporte on-line, etc.). Dentro del coste de !
medio entre fallos que es la suma del tiempo medio de fallo ms el tiempo calidad debido a fallos, es importante analizar y distinguir el coste debido a '
medio de reparacin de ese fallo: fallos antes de la implantacin y posteriores a la implantacin, cuando el <
producto est funcionando en el cliente.
TMEF=TMDF+TMDR
ISO 9001 (une 66-901). Sistemas de calidad. Modelo para el Medicin de la calidad de! producto y del proceso.
aseguramiento de la calidad en el diseo, desarrollo, produccin, Reglas, prcticas y acuerdos para aplicar la norma ISO 9000.
instalacin y servicio post-venta. Herramientas y tcnicas para hacer efectiva la norma en la gestin y el
desarrollo.
ISO 9002 (UNE 66-902). Sistemas de calidad. Modelo para el Garanta de las compras.
aseguramiento de la calidad en la produccin y la instalacin. Productos software suministrado por el cliente.
Necesidades de formacin respecto a calidad.
ISO 9003 (UNE 66-903). Sistemas de calidad. Modelo para el
aseguramiento de la calidad en la inspeccin y los ensayos finales. La norma ISO 9000-3 hace referencia, adems de las ya mencionadas, a
las siguientes:
ISO 9004 (UNE 66-904). Gestin de la calidad y elementos de un
sistema de calidad. ISO 2382/1. Trminos fundamentales del tratamiento de datos.
ISO 8402. Vocabulario de calidad.
Dentro de la ISO 9000 hay que destacar su tercera parte que afecta ISO 10011-1. Reglas para las auditorias de sistemas de calidad.
directamente a la calidad del software. Es la ISO 9000-3: Gua para la
aplicacin de la norma ISO 9001 al desarrollo, suministro y mantenimiento del Dentro del entorno espaol, debemos citar las siguientes leyes que afectan
software. Esta norma crea un marco de referencia a la calidad del software a la calidad del software:
estableciendo criterios sobre las responsabilidades de la direccin del cliente y
del suministrador, la elaboracin y mantenimiento de un plan de calidad Ley de Regulacin del Tratamiento Automtico de Datos de carcter
integrado durante todo el ciclo de vida del software, la realizacin de auditorias personal (LORTAD 5/92).
internas y la elaboracin y mantenimiento de acciones correctoras.
Ley de Proteccin Jurdica de Programas de Ordenador (16/93).
Ley de Ordenacin de las Telecomunicaciones (LOT 31 /87).
La ISO 9000-3 establece los criterios a seguir en las siguientes actividades
del ciclo de vida del software:
Adems establece criterios a seguir en las siguientes actividades de apoyo El equipo de gestin do calidad del software estar formado por los
del ciclo de vida del software: desarrolladores que llevan a cabo tareas tcnicas, los responsables de la gestin
de los proyectos software y por personal tcnico especializado en calidad del
Gestin de la configuracin. software que ayudar a definir y medir la calidad. Este equipo, adems de
Control de la documentacin establecer el Plan de Calidad, participar en el desarrollo de la descripcin del
proceso de calidad dentro del proyecto software, revisar que las actividades
Registros de calidad.
346 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 F O R M T IC O S C A P T U L O 15: LA G A R A N T A DE C A L ID A D 347
definidas en el proceso se realizan y que las desviaciones, de haberlas, se 6 . Revisiones del software. En esta seccin se definen los tipos de revisiones,
documenten y gestionen segn el proceso predefinido, auditar los resultados sus objetivos y mecanismos. En detalle:
del proceso y registrar y comunicar sus conclusiones, coordinar los cambios 6.1 Propsito
y definir las mtricas de la calidad del software a utilizar, verificando sus
resultados. 6.2 Requisitos mnimos
6.3 Otras revisiones y auditorias
Como ya hemos dicho el estndar IEEE 730-2002 proporciona la
estructura de la documentacin del Plan de Calidad de una organizacin de 7. Pruebas. En este punto se identifican y detallan las pruebas no incluidas en el
software. Este estndar est elaborado segn el siguiente contenido: plan de verificacin y validacin.
1. Propsito. Este punto proporciona una visin simplificada del plan. 8 . Informe de errores y acciones correctoras. En este punto se indica como se
reportarn los problemas encontrados y se har su seguimiento.
2. Documentos de referencia. En este punto se determinan estndares,
procedimientos y documentos relacionados. 9. Herramientas, tcnicas y metodologas. En este punto se describen las
herramientas, tcnicas y metodologas utilizadas como soporte del proceso de
3. Gestin. En este punto se asignan responsabilidades para cada actividad de calidad.
la gestin de calidad, estructura organizativa y responsabilidad del plan. En
detalle: 10. Control de medios. En este punto se define la gestin del medio fsico de
3.1 Organizacin. cada producto software.
3.2 Tareas. 11. Control de proveedor. En este punto se define el control de calidad del
3.3 Roles y responsabilidades. softw'are proporcionado por proveedores externos.
3.4 Recursos estimados de garanta de calidad.
12. Coleccin de registros, mantenimiento y conservacin. En este punto se
define el histrico de documentacin de cada proceso.
4. Documentacin. En este punto se describe la documentacin que se va a
generar en el proceso y, para cada documento, se indica el objetivo del
13. Formacin. En este punto se determina la formacin necesaria del equipo
documento, la plantilla, norma y/o estndar que se usa para elaborar el
involucrado en la gestin de calidad.
documento y el contenido mnimo que debe tener dicho documento. En detalle:
4.1 Propsito. 14. Gestin del riesgo. En este punto Se indican los mtodos a utilizar para
identificar y controlar los riesgos identificados en el proyecto y las actividades
4.2 Requisitos mnimos de documentacin.
a realizar para cumplir este objetivo.
4.3 Otra documentacin.
15. Glosario. En este punto se incluye un diccionario de trminos y
5. Estndares, prcticas, convenciones y mtricas. En este punto se hace abreviaturas utilizadas.
referencia a los estndares de documentacin, de diseo, de prueba, etc. y se
describe para cada propiedad de calidad identificada, las mtricas que se 16. Procedimiento de cambio e historial del plan de calidad. En este punto se
utilizarn para medir dicha propiedad de calidad. En detalle: establece el procedimiento de modificacin del plan y sus versiones.
5.1 Propsito
5.2 Contenido
348 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 F O R M T IC O S __________________________________ C A P T U L O 15: l.A G A R A N T A D E C A L I D A D _______ ____________ 349
University) CMM es una aplicacin de sentido comn de los conceptos de Es posible distinguir etapas de distinta madurez en el proceso;
gestin de procesos y mejora de la calidad al desarrollo y mantenimiento del Hay cosas que deben ser aplicadas antes que otras para mejorar la
software. madurez del proceso;
La madurez disminuir, a menos que se mantenga, es decir, conservar
Podemos distinguir una organizacin de software inmadura por las el mismo nivel de madurez requiere un esfuerzo permanente.
siguientes caractersticas:
La evaluacin de una organizacin como adecuada a un nivel de CMM se
Los procesos se improvisan. basa en los niveles de madurez descritos, en las reas claves de la organizacin
Los procesos establecidos no se siguen. y, para cada una de ellas, sus caractersticas y sus prcticas comunes, segn
Poco dispuesta al cambio. muestra la figura 15.5.
Se centra en resolver crisis inmediatas.
La programacin y el presupuesto de los proyectos se exceden
indican Capacidad
generalmente.
del proceso
No hay bases para juzgar la calidad del producto y problemas en el
proceso.
Si hay plazos rgidos, se sacrifican funcionalidad y calidad del producto alcanzan
para satisfacer el plan.
Cuando los proyectos est fuera de plan, las revisiones o pruebas se
recortan o eliminan. se aplican /implementacin oN
Vlnsttucionallzaciri
Por otra parte, una organizacin madura, o con un nivel de madurez
considerable, tendr las caractersticas siguientes: describen Infraestructura
o actividades
Se controlan la calidad de los productos y la satisfaccin del cliente.
Figura 15.5 Proceso de evaluacin del CMM.
Se realizan anlisis cuantitativo sobre el producto y el proceso.
Los presupuestos y programaciones se basan en datos histricos
Segn Gartner, CMM puede aportar un 10 por ciento de ahorro en costes
(reales).
de produccin, un 145 por ciento de mejora en las desviaciones de plazo de los
Normalmente se cumplen las estimaciones.
proyectos o un 15 por ciento de reduccin de errores en el producto terminado.
Se desarrollan habilidades para gestionar el desarrollo de software y los No obstante, pocas compaas pequeas o medianas se han embarcado en
procesos de mantenimiento. proyectos de CMM. Segn la consultora Profit Gestin Informtica solo 1.300
El proceso se comunica de forma precisa a los trabajadores y nuevos entidades a escala mundial se encuentran certificadas en algn nivel de CMM.
empleados. Las figuras siguientes, 15.6 y 15.7, muestran respectivamente los porcentajes
Los procesos se actualizan y se controlan las mejoras. de participacin de las organizaciones de software geogrficamente en los
Los roles y responsabilidades estn claras. procesos de certificacin de CMM y los resultados obtenidos por niveles
(fuente SEI).
El CMM se centra en tres aspectos, que son los que influyen en el producto
software: las personas, la tecnologa y el proceso; y en cuatro conceptos base
que ayudan a la organizacin a comprender y adaptarse al nuevo
planteamiento:
C an ad y
El nuevo modelo CMMI ofrece un marco comn para todas las disciplinas
Sudam rica y agrega una nueva forma de representacin adems de la conocida
2% representacin por niveles. La nueva forma de representacin se llama
Asia y
Continua y est orientada a medir la mejora en los procesos de manera
Pacifico Sur
3 1%
individual en vez de hacerlo de manera conjunta como la representacin por
niveles.
Europa
A sia y 5 6% Dentro de esta nueva generacin de modelos, el sucesor directo del CMM
Pacfico original es el denominado CMMI-SW. Este modelo presenta una mayor
Norte cobertura con respecto a las reas de proceso, y agrega el concepto de
10% representacin continua. Los nombres de algunos niveles establecidos por
CMMI cambian respecto a los del modelo CMM; ahora el nivel 2.Repetible
Figura 15.6 Participacin el los procesos de certificacin CM M en el ano ha pasado a denominarse 2.Gestionado'; y el nivel 4.Gestionado se
2000. denomina 4. Cuantitativamente gestionado.
Segn dicen los expertos en el rea de la Ingeniera del Software (vase la obra Solicitud de propuestas
Plan de gestin config
de Sommerville), a lo largo de la historia, el mantenimiento del software se ha Adquisicin
^ w
D
iorrador del contrato identificacin versiones G e s t i n d e
dificultado mucho como consecuencia de la deficiente documentacin del ^ W C o n fig u r a c i n
Inform es de estado
diseo. Por tanto, realizar una documentacin tcnica de calidad sobre el
proceso y el software obtenido ser tan importante como la propia calidad de
Propuesta
0 ^ W
c
M anual de procedimiento s
este software. Suministro Contrato ^
^ fe W C a lid a d
M anual de calidad
Informe de verificacin
e
Especificaciones ^ fe,
p
pocas, sobre el tratamiento documental en la Ingeniera del Software. Estas V a lid a c i n
propuestas, empiezan ahora a ser consideradas por las organizaciones que M anual de usuario Informe de auditoria
mercado dominado, en la actualidad, por la exigencia a las organizaciones del Doc.resolucin problemas
Cuadernos de carga
t R e s o lu c i n de
p r o b le m a s
de los proyectos de software.
Plan d e desarrollo a Plan de gestin proyecto
El inters por la calidad ha sido un hecho constante en toda la historia de la
evolucin de la ingeniera del software. A finales de los aos ochenta este
etodologia desarrollo
c 4------------------------------
Plan de gestin del riesgo G e s t i n
nformacin de errores
^ W1
inters experiment un gran auge como consecuencia de la aparicin de la |Operaci~ 1 Definicin infraestructura
normativa internacional de calidad industrial propuesta por ISO. Con la llegada an de mantenimiento
w
^
^
fe
W In fr a e s t r u c
de la serie ISO 9000 en 1987, todos los sectores industriales sufrieron una
revolucin en sus procesos de trabajo a travs de los sistemas de calidad
iforme d e problemas O Informes d e mtricas sw
tu ra
riterios evaluac.modif
n <. ------------------------------ M e jo ra
quedaron al margen de esta poderosa corriente, si bien, debido a la peculiar miento Material de formacin
naturaleza del software, requiri la creacin de una norma especfica de Plan de migracin <. ------------------------------ F o r m a c i n |
aplicacin, la ISO 9000-3. Con la aparicin de esta norma, llegaron las Plan retirada software
auditorias de sistemas de calidad, las certificaciones, etc. ISO 9001, considera
una adecuada documentacin lo fundamental para garantizar la calidad. Figura 15.8 Procesos y algunos de los documentos implicados en el ciclo de
vida de! software segn ISO.
La documentacin en los proyectos software es de suma importancia, esta
importancia se pone de manifiesto por tratarse del elemento integrador de los En la figura 15.8 se muestran los procesos y algunos documentos
diferentes aspectos de un proyecto software (segn Ayer y Patrinnostro). implicados en el ciclo de vida del software segn ISO en su norma 12007, para
2 Parte de esta seccin es un resumen de nuestro trabajo: "SfV Documentation as an 3 Vanse referencias bibliogrficas en de la normas ISO 12207 (1996), ISO 9126 (1991) e ISO
E ngineering Process", publicado en la revista del ACM SIGSoft, Software Engineering Notes. 9001 (2000) para obtener informacin ms detallada.
356 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 F O R M T IC O S C A P TU LO 15: LA G A R A N T A D E C A L ID A D 357
Dada la importancia de la documentacin se considera, actualmente, un Figura 5.9. Fases de! ciclo de vida de a documentacin del software.
nuevo aspecto en la ingeniera del software: la ingeniera de la documentacin
del software. Por ingeniera se entiende el conjunto de mtodos, tcnicas y Las cinco fases del ciclo de vida, a su vez, se dividen en una serie de
herramientas para el diseo, construccin y utilizacin de productos diversos, etapas durante las cuales se deberan llevar a cabo las tareas que, de forma
tambin la produccin de la documentacin, que contiene la informacin conjunta, garanticen un completo tratamiento de los diferentes aspectos de
necesaria para el mantenimiento de un proyecto de desarrollo de software, gestin de los documentos implicados en un proyecto. El objetivo de cada una
debera abordarse como si de un proceso de ingeniera se tratara; realizando, en de estas fases es el siguiente:
primer lugar, un anlisis riguroso de las necesidades documentales para,
posteriormente, proceder a la definicin y diseo de los documentos Planificado de la documentacin: El objetivo de esta fase es el estudio de las
identificados; despus a su construccin, posteriormente a la preparacin para necesidades de documentacin del proyecto de software que se vaya a
su recuperacin y, finalmente, a su explotacin en el seno de la organizacin. desarrollar, elaborando un Plan de Documentacin que establezca, entre '
otros, el tipo de documentos a elaborar, la tecnologa que se utilizar y la
En este sentido, las tcnicas documentales, se ajustan a normativa secuencia de operaciones para la produccin y distribucin de los documentos,
internacional como Z39.58-1992, estndar ISO de 1992, como lenguaje comn y para la construccin del lenguaje documental que se utilizar durante su
para la recuperacin de la informacin en lnea. indizacin. Este plan ser el punto de partida de la siguiente fase, la de diseo.
La secuencia de actividades a realizar durante la fase de planificacin es la
La Ingeniera de la Documentacin de! Software se debe fundamentar en siguiente:
una metodologa de desarrollo de documentos que establezca, por una parte, el
ciclo de vida compuesto por las fases y etapas que constituyen el proceso 1) Identificar las necesidades de documentacin;
documental y, por otra parte, el conjunto de tcnicas que debern aplicarse en 2) Definir los documentos y sus relaciones;
cada una de las actividades del ciclo de vida. 3) Establecer la organizacin documental;
4) Elaborar el Plan de produccin y distribucin de documentos;
En la figura siguiente (figura 15.9) se muestra el ciclo de vida establecido 5) Elaborar el Plan de construccin del lenguaje documental;
para los documentos, basado en las recomendaciones de ISO y ANSI. 6) Estudiar diferentes alternativas tecnolgicas.
358 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 F O R M T IC O S C A P T U L O 15: L A G A R A N T A D E C A L ID A D 359
CAPTULO 16
ORGANIZACION Y CONTROL DE UN
PROYECTO
Describir la estructura del proyecto y cual es la estructura ms adecuada miembros. Por tanto, el nmero de miembros de un equipo debera estar entre 3
para cada tipo de problema. y 8 personas. En caso de necesidad de quipos con mayor nmero de miembros,
sera bueno establecer equipos pequeos, cada uno con un coordinador, y un
Introducir el Modelo de Madurez (CMM) para la gestin del personal. equipo de coordinadores responsable de la comunicacin entre equipos.
Definir las actividades de seguimiento y control de proyectos Es muy importante y decisiva la figura del jefe de proyecto, sus
caractersticas personales, sus habilidades y su capacidad de liderazgo. Este
asunto ya ha sido tratado ampliamente en el captulo 2 .
16.1 ESTRUCTURA DE LOS GRUPOS DE TRABAJO Respecto a la estructura del equipo, podemos decirla para cada proyecto,
pero en general hay definidas varias estructuras estndar, sus ventajas y sus
El estudio, anlisis, desarrollo y mantenimiento del software y, en general, de inconvenientes. Es responsabilidad del gestor de proyectos utilizar la ms
sistemas de informacin, en definitiva, las tareas que forman parte de un adecuada en cada caso. Entre estas estructuras podemos distinguir:
proyecto informtico, no suelen realizarse de forma individual. Se ha pasado a
la gestin de la informacin de forma manual o con desarrollos artesanales a la Equipos centralizados. A cada miembro del equipo, el jefe de proyecto
ingeniera de sistemas y la ingeniera del software. El trabajo de los le asigna tareas individuales y desconoce las tareas asignadas a los otros
componentes de un proyecto informtico tiene una gran parte de trabajo en miembros del equipo. La comunicacin se realiza, siempre
equipo. Algunos autores llegan a considerar que la media de tiempo dedicado a directamente con el jefe de proyecto, al que, cada miembro, tiene que
la interaccin con otras personas es del cincuenta por ciento del tiempo total de responder del desarrollo sus tareas asignadas. Los miembros del equipo
trabajo en un proyecto informtico. no participan de decisiones ni planificacin del trabajo. El problema de
este tipo de equipos es la falta de motivacin de sus miembros, al no
Por tanto, teniendo en cuenta la importancia del trabajo en equipo en los sentirse partcipes de un grupo y el riesgo de autoritarismo dentro del
proyectos informticos, el gestor de proyecto tiene, como tarea fundamental, equipo. La figura 16.1 muestra la estructura de comunicacin en este
crear equipos que funcionen y crear buenas relaciones de comunicacin entre tipo de equipos:
ellos, con otros equipos y con l mismo. Para establecer los equipos de trabajo
Jefe de proyecto
eficientes debemos tener en cuenta la cantidad y tipologa de sus miembros, el
tipo de estructura del propio equipo y el entorno donde va a desarrollar su
trabajo.
conjuntamente por todos sus miembros. Cada equipo elige un portavoz Jefe de proyecto
que se encarga de la comunicacin con los portavoces de los otros
equipos y con el jefe de proyecto. El problema de este tipo de equipos
es la cantidad de tiempo que se debe dedicar a la comunicacin entre
los componentes y con equipos externos y el riesgo de toma de
decisiones lentas y difciles (al ser compartidas a igualdad de
condiciones) y, en algunos casos, ligeras o poco meditadas por falta de Jefe de equipo Jefe de equipo
responsabilidad individual. La figura 16.2 muestra la estructura de
comunicacin en este tipo de equipos:
Jefe de proyecto
Organizacin Funcional: Se trata de lina organizacin jerarquizada con empresa pero que, a su vez, no forman la totalidad de la organizacin.
grupos o departamentos especializados en realizar trabajos sobre temas Se les atribuye la posibilidad mayor de afrontar problemas sobre todo
concretos. A su vez cada uno de estos departamentos se divide en porque sus decisiones, debido sobre todo a su forma de elaboracin,
secciones que gestionan cada una de las reas de negocio concretas de tienen una gran aceptacin entre el grupo de directivos de la empresa,
que dispone la organizacin. adems la toma de decisiones suelen ser menos subjetivas por su forma
colegiada. A pesar de este tipo de ventajas tambin presenta algunos
Matriz organizativa de dependencias: En este tipo de organizaciones tipos de problemas, debidos fundamentalmente a la prdida de tiempos
suele existir una doble dependencia funcional y otra dependencia en la toma de las decisiones, la excesiva evasin de responsabilidades
orgnica que facilita el desarrollo de los proyectos al no tener que y, en muchos casos, se observa la existencia de grupos dominantes que
pasar la informacin por las jerarquas existentes para los asuntos tratan de imponer su opinin en contra del resto y que hace que, por
concretos de proyectos en ejecucin. La flexibilidad es la caracterstica tener que llegar a una conclusin, puesta en comn, no se llega a tener
de este tipo de organizaciones. la decisin ptima.
La figura 16.4 muestra grficamente la relacin entre las etapas descritas. Para realizar las actividades de seguimiento contamos con los datos que
genera el proyecto: los entregables de cada tarea, el resultado de las revisiones,
inspecciones y controles de calidad, algunos de ellos con participacin del
N iv e l 5 - O p tim iz a d o cliente, los documento de planificacin de tareas (PERT, CPM, etc.) y de
N iv el 4 - G e s tio n a d o
16.4 SEGUIMIENTO Y CONTROL La Real Academia Espaola de la Lengua define control como
regulacin, manual o automtica, sobre un sistema, es decir, es un proceso
Como decamos en la introduccin del captulo, la planificacin de proyectos que utiliza recursos manuales y automticos para conseguir que el proyecto se
es un proceso cclico y continuo, que comprende no slo la elaboracin realice de forma ordenada y segn lo previsto.
peridica de planes sino tambin su revisin peridica y evaluacin. Esta
actividad se denomina seguimiento y control de proyectos. Para un buen control de proyectos, al principio del proyecto se deben
definir estndares que midan la productividad y la calidad de los resultados, se
El seguimiento de un proyecto se realiza analizando la situacin real del deben establecer los puntos mnimos y deseables donde obtener informes de
proyecto para comprobar que los costes no sean mayores que los esperados en progreso y los entregables que sern objetos de seguimiento. Durante el
cada fase del proyecto, que no existan retrasos en ninguna actividad, proyecto se debe recoger la informacin antes definida y compararla con la
especialmente las crticas y que se cumplan las condiciones de calidad planificacin inicial y los ajustes posteriores realizados en posibles
definidas con el cliente, es decir, que no se dejen de verificar las condiciones replanificaciones. Se definir, para cada estndar y punto de control
bsicas acordadas (tres vrtices del tringulo de triple compromiso, visto en el establecido, los niveles de cumplimiento y las desviaciones. El ltimo paso
captulo tercero).
37 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 F O R M T IC O S
Las acciones a tomar para corregir las desviaciones pueden incidir sobre la
utilizacin de recursos y modificar la planificacin establecida, procurando que
no afecten a la calidad, el plazo de entrega y el coste del proyecto. Si alguno de CAPTULO 17
estos tres parmetros debe ser obligatoriamente modificado, es necesario llegar
a un consenso con el cliente y en algunos casos aplicar clusulas especiales del PROYECTOS ESPECIALES DE INGENIERA
contrato, corno penalizaciones.
DEL SOFTWARE
Cuando las desviaciones don tan grandes o tan importantes que peligra el
xito del proyecto hablamos de crisis del proyecto. En estos casos las acciones
de controla a tomar pueden ser drsticas, pero siempre definidas en el tiempo.
No es posible intentar resolver una crisis dando un plazo de tiempo Este apartado, casi final, pretende acercar al lector a algunos proyectos
indeterminado. Si la crisis dura ms de un tiempo limitado (puede ser un mes, informticos especiales por su importancia. Esta importancia puede estar dada
pero depende del tiempo total del proyecto) sera conveniente estudiar de por varios factores, como pueden ser:
nuevo la viabilidad del proyecto.
La cantidad de proyectos de este tipo que se llevan a cabo;
Las acciones correctivas que se pueden tomar en una crisis pasan por la Su larga duracin y/o alto coste;
comunicacin oficial de la crisis a todo el equipo, explicando la situacin, Su importancia estratgica dentro de los Sistemas de Informacin
posibles causas y las acciones a tomar. Una vez informado oficialmente todo el Empresarial;
equipo es ms fcil contar con su colaboracin. La mayora de las acciones Su novedad o actualidad;
correctivas tiene que ver con la gestin de recursos, nueva contratacin, Las importantes ventajas que aportan a los Sistemas de Informacin;
aumento de horas de trabajo del personal existente, reasignacin de puestos,
K
establecimiento de prioridades en las tareas, etc. Una vez resuelta la crisis, en Trataremos tres tipos de proyectos, que hemos denominado especiales, lo
un plazo mximo establecido, la situacin debe volver a la normalidad, largo de este tema. En primer lugar hablaremos de los proyectos de
asignado de nuevo recursos y prioridades. reingeniera del software y de ingeniera inversa como solucin para el
mantenimiento del software y mejora de los sistemas informticos,
Siempre se debe establecer un seguimiento y control especial en las detenindonos en un tipo particular de reingeniera, no de software, sino de
ltimas fases del proyecto, ya es conocido el hecho de que la mayora de los procesos, situndola como paso previo a la implantacin o actualizacin de un
proyectos avanzan con normalidad hasta completar el 90%, mientras que el sistema de informacin. Tambin hablaremos de los repositorios como centro
10% restante se detiene y llega a ser hasta un 40% del nuevo total en coste y en de operaciones de los procesos de reingeniera.
tiempo.
A continuacin, haremos referencia a los proyectos de reutilizacin de
Es muy importante para el buen desarrollo del proyecto que las acciones software, concepto cada vez ms amplio y que empieza a formar parte, como
de seguimiento y control se realicen sobre las actividades del proyecto, no un nuevo tipo de gestin, de todos los proyectos informticos. Sobre este tema
sobre el personal del proyecto. Hay que controlar lo que se hace no al que lo es importante recordar su conexin con la orientacin a objetos, las libreras
hace. Es importante difundir la informacin entre el personal y hacerle software y el concepto ingenieril de la gestin del ciclo de vida del software.
partcipe del xito o fracaso del proyecto, estableciendo el punto justo entre
recompensa y disciplina. Por ltimo, hablaremos de un tipo de proyecto cada vez ms frecuente en
organizaciones de muy diversas clases: la implantacin de paquetes estndar.
Cada vez ms, frente al software a medida, se utilizan paquetes de software
37 2 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 C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S DI; IN G E N IE R IA D E L S O F T W A R E 373
Describir el concepto y la utilizacin de la Reingeniera del Software y F ig u ra 7.1 P roceso de re in g en iera d e l softw are
la Ingeniera Inversa.
La ingeniera inversa del software permite recuperar el diseo de una
Definir los repositorios como elemento central en la reingeniera.
aplicacin (modelos de la arquitectura del software, modelos de datos y
modelos de interfaces de usuario) a partir de su cdigo fuente. Las actuales
Introducir la Reingeniera de Procesos en el contexto de los proyectos
herramientas de ingeniera inversa, adems de funcionar en modo grfico,
informticos.
permiten, una vez que han analizado y comprendido el viejo cdigo, utilizarlo
en una nueva plataforma o en un proyecto posterior. Pero, adems, documentan
Definir la reutilizacin del software y sus ventajas. el cdigo para que los analistas tengan una idea de lo que ese software
realmente ejecuta.
Explicar los proyectos de adaptacin e instalacin de paquetes software
estndar. Uno de los trucos de la ingeniera inversa es asegurar que el nuevo cdigo
nunca ms se volver tan enigmtico como el original, cuando el nuevo cdigo
se tiene en un estado "comprensible" es conveniente asegurarse de que hace lo
que debe y no esconde viejas funciones viciadas del pasado, alguna de las
17.1 REINGENIERA DEL SOFTWARE. herramientas obliga a que el cdigo resultante este encajado en alguna de las
mtricas disponibles y que no pueda salirse de ella como garanta de calidad.
Vamos a ver como la reingeniera puede ser utilizada para solucionar
problemas de mantenimiento del software y la migracin de nuevas a viejas Podemos definir tambin la ingeniera inversa avanzada como la
tecnologas. recuperacin del anlisis (requisitos, modelos funcionales, entrevistas, etc.) a
partir del cdigo fuente. Como podemos deducir se denomina avanzada porque
Pero a dnde llega realmente la reingeniera del software? Tal vez va ms all de la ingeniera inversa, que solo recupera el diseo.
tengamos que explicar los problemas que se han presentado en algunas
organizaciones que tenan un antiguo ordenador y unas viejas aplicaciones que Como hemos visto, la reingeniera en Ingeniera del Software es el proceso
han tenido que migrar y que no eran dominadas por casi nadie en la de examinar un sistema de software existente con el fin de modificarlo con la
organizacin y, adems no estaban suficientemente documentadas, sin embargo ayuda de herramientas automticas para:
funcionaba!. La reingeniera del software supone el examen y alteracin de un
sistema software para reconstruirlo de una forma nueva. Es una actividad Prever su futura mantenibilidad
fuertemente conectada con las herramientas de mantenimiento automatizado
Actualizar su tecnologa
del software.
Prolongar su esperanza de vida
Incrementar la productividad del mantenimiento
La reingeniera supone la aplicacin de un proceso de ingeniera inversa y
otro de ingeniera directa del software para reconstruirlo. Podemos ver este
esquema en la figura 17.1.
374 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 F O R M T IC O S C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S D E IN G E N IE R IA D E L S O F T W A R E 375
Desde este punto de vista existen varios tipos de reingeniera, segn la Reestructuracin del cdigo del programa: violacin de estndares,
parte del ciclo de vida que se quiera mejorar. En este sentido podemos cdigo no estructurado, documentacin pobre, nombres de variables de
encontrar software para la reingeniera segn los siguientes tipos: pobre significado, lgica compleja.
Anlisis: procesos que estudian un sistema con el objetivo de Reestructuracin de los datos: organizacin de datos frgil, nombre de
comprender su funcionamiento y comportamiento y as poder extraer registros mal definidos, definicin de datos no estndar, ausencia de
informacin para la reingeniera o para medir su calidad. diccionario de datos.
Reestructuracin: Es el proceso que se encarga de cambiar la forma del Ingeniera inversa, migracin: viejas tecnologas, viejos lenguajes o
software sin alterar su funcionamiento. El objetivo primario es hacer los versiones o sistemas de gestin de bases de datos, emulaciones,
programas ms fciles de entender. Los mantenimientos tienden a ausencia de especificaciones de diseo.
corromper la estructura del software. La reestructuracin lo hace ms
comprensible, simplificando las condiciones, formatendolo para Sustitucin total o parcial: eleccin pobre de algoritmos, funcionalidad
hacerlo ms legible, eliminando saltos incondicionales, agrupando en incorrecta o incompleta, inseguridad y/o desconfianza, defectos en el
forma de mdulos distintas partes del software relacionadas para diseo de bases de datos.
simplificar interfaces entre mdulos, etc.
Para cubrir todo este campo de actuacin tan amplio y que adems cada
Ingeniera inversa: Son procesos de anlisis de sistemas para reconstruir vez est siendo ms utilizado se han desarrollado distintas herramientas.
una descripcin de sus componentes y sus relaciones. El objetivo de la Vamos a clasificarlas en funcin de su utilidad. Distinguimos los siguientes
ingeniera inversa es documentar el sistema y descubrir la informacin tipos de herramientas para la reingeniera:
de diseo con el nimo de facilitar la comprensin del programa. La
funcionalidad del sistema no cambia. Programas analizadores: traceadores de lgica y de datos y
referenciadores en cruz.
Migracin: proceso de convertir un sistema software desde un lenguaje
a otro, adaptndolo a otro sistema operativo o actualizando su Programas mtricos: monitorizadores normalizados, analizadores de
tecnologa. Puede ser necesario debido a la escasez de personal calidad, comprobadores de complejidad.
cualificado a la modificacin del software de soporte o de la plataforma
hardware o a cambios en la estrategia de la organizacin. Programas para la reestructuracin: reestructuradores de procesos
lgicos, estandarizadores de nombres lgicos y de definiciones,
Reingeniera de datos. Consiste en analizar y reorganizar las estructuras reformateadores/mejoradores de presentacin.
de datos y/o los valores de los datos. Este proceso es necesario cuando
existe una degradacin en la base de datos (igual que ocurre con los Ingeniera inversa: ingeniera inversa de datos, ingeniera inversa de la
programas, las estructuras de datos tambin se corrompen con el lgica de procesos.
mantenimiento), cuando el volumen de datos es inmanejable y se debe
generar un histrico o cuando un software errneo ha introducido Programas Comprobadores: generadores de datos, testeadores de
valores incorrectos. procesos: algebraicos o estadsticos, depuradores, comparadores.
Veremos ahora algunos ejemplos del tipo de actuacin recomendada en el Traductores/Conversores: traductores de lenguajes.
mbito de la reingeniera segn el problema que encontramos en el software:
Manejadores de cambios o de configuracin: manejadores del control
de cambios, controladores de libreras, constructores de sistemas.
376 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 F O R M T IC O S C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S DE IN G E N IE R IA D E L S O F T W A R E 377
especificaciones de procesos y mdulos, diagramas de entidad-relacin financiado por Europa, de donde es originario, en un plan ESPRIT a
y de control de transacciones, diagramas de Warnier, tablas de decisin, diez aos. Permite proceso distribuido (tanto en almacenamiento como
matrices de estado-suceso, registros de elementos de datos, campos en proceso), manejo de ventanas heterogneas, datawarehouse, etc.
(tanto de datos como de pantallas), pantallas, mapas, programas y
mdulos.
IRDS: Information Resource Dictionary System. Desarrollado por el 17.3 REINGENIERA DE PROCESOS DE NEGOCIO.
National Institute o f Standars and Technology, incluye seis mdulos:
ncleo del diccionario del sistema, esquema funcional bsico, En la evolucin del ciclo de vida de un producto software se deben adaptar los
seguridad, facilidad para extensin del ciclo de vida, facilidad para los procedimientos de negocio a las nuevas tecnologas. La reingeniera de
procedimientos e interfaz para los programas de aplicacin. procesos de negocio se utiliza para realizar esta adaptacin y, normalmente,
Fundamentado en la arquitectura Entidad-Relacin organiza toda la constituye un proyecto anterior (a veces forma parte del propio proyecto) a
informacin entorno a los esquemas: esquema de la capa de cualquier proyecto de implantacin o modificacin importante a un Sistema de
descripcin, esquema capa de datos, datos en s mismos, etc. Informacin Empresarial.
SAA de IBM y el ciclo AD. SAA (estndar de hecho) es una coleccin Empleada inicialmente por Hammer en 1990 en un informe del MIT sobre
de principios, objetivos y normas que cubren aspectos de los mtodos de gestin que mas xito tendran en la dcada actual, es el
comunicaciones, accesos al usuario, y desarrollo de aplicaciones para replanteo fundamental y el rediseo radical de los negocios para conseguir una
entornos MVS, VM, AS/400 y OS/2. AD/Cycle es la base para facilitar mejora drstica en medidas crticas del rendimiento tales como costo, calidad,
un esquema para el desarrollo de aplicaciones integradas sobre la servicio y velocidad.
plataforma SAA que ofrece: soporte de funciones completas de ciclo de
vida, inlerfaces de usuario comunes, repositorios comunes y Se distingue del cambio organizativo (segn Andrews y Stalick en 1993)
arquitectura abierta. en:
ATIS: A tools Integration Standard (1PSE: Integrated Proyect Support El cambio solo puede producirse cuando se hayan destruido las formas
Enviroment: object-oriented interface) de DEC&Atherton Technology. de pensar y operar. La Reingeniera crea lo que no hay.
Define un repositorio comn y cargable desde otras aplicaciones CASE
aportando una interfaz propia. Incluye control de versiones, manejo de Los resultados concretos deben de ponerse en manifiesto rpidamente.
configuraciones, herramientas de comunicacin del grupo, relaciones
entre los objetos software y extensiones dinmicas para herramientas Las tecnologas de la informacin deben de jugar un papel clave en
adicionales. Su corazn lo constituye el denominado BackPlane, cualquier esfuerzo de cambio organizacional.
organizado como un escritorio orientado a objetos con soporte a
catlogos, control de la integracin, control de workflow, integracin de Cualquier cambio afecta a todas las partes de la organizacin.
datos, modelos de integracin de usuarios y herramientas de integracin
incremental de procesos. La metodologa para el desarrollo de proyectos de reingeniera de procesos
de negocio se construye como respuesta a una serie de cuestiones simples,
PCTE: Portable Common Tool Enviroment. Es un interfaz estndar como:
cuyo fin es asegurar la portabilidad de CASEs en
microcomputadoras/redes LAN. La idea es especificar un interfaz como Se necesita aplicar reingeniera a esta operacin? En caso afirmativo
un conjunto de funciones que corren entre un sistema operativo y las Cules son los lmites, el alcance y los puntos intermedios de la
herramientas CASE para dar generalidad a los entornos. PCTE tiene operacin de reingeniera?Cmo se debe estructurar el proyecto?Qu
varias ampliaciones pero se encuentra en un modo experimental y est personas?
38 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 F O R M A T IC O S C A P T U L O 17: P R O Y E C T O S E S P E C IA L E S D E IN G E N IE R IA D E L S O F T W A R E 381
Cul es el diseo detallado de la operacin reingeniada? Cmo 5. Planificar la Implementacin (de 2 a 4 semanas). El propsito es
funciona el proceso? Cmo es la organizacin? Qu sistema se desarrollar un plan de accin realista para implementar el proyecto de
necesita? Que sistema de creencia o de cultura debe implantarse? reingeniera. El resultado sera un plan de implementacin.
Funcionar el nuevo diseo de la operacin? Ser necesario hacer 6. Obtener la Aprobacin-Implementacin (de 1 a 2 semanas). El
cambios al diseo? propsito es obtener los fondos y los recursos para empezar la
implantacin del proyecto. El resultado sera una peticin de recursos
consolidada.
Cul es el Plan para que se triplemente este diseo? Qu se requiere
para que esto ocurra? Cunto durar? Cules son sus riesgos?
Cunto costar? 7. Implementar el Rediseo (de 6 meses a 3 aos). El propsito es
transitar la operacin de negocios del entorno actual al entorno
reingeniado. El resultado sera obtener conclusiones de los resultados
Se debe invertir en la implantacin de un diseo de reingeniera?
de las mediciones.
La implementacin avanza como se plante? Que correcciones o
8. Transicin hacia un Estado de Perfeccionamiento (permanente). El
cambios deben de hacerse para asegurar una transicin completa al
propsito es terminar las actividades del equipo del proyecto y
ambiente de la visin?
conseguir la mejora continua del entorno reingeniado. El resultado
sera un funcionamiento continuamente mejorado.
Est preparada la operacin reingenierada para una continua mejora
del proceso?
electrnicos montan nuevas placas de circuitos impresos incorporando chips a Comparte las especificaciones del sistema, diseo, cdigo, y otros
sus circuitos. documentos del proyecto producidos por el grupo.
Existen muchos componentes de software reutilizables ms all de los Vamos a listar, al igual que las ventajas, los inconvenientes o problemas
mdulos software. Caper Jones1 define muchos otros conceptos que pueden ser que podemos encontrar al aplicar la reusabilidad:
fcilmente reutilizables entre los que se encuentran:
Cuestiones de lo que es realmente reusable.
Los Planes del Proyecto
La estimacin de costes Dificultad para descubrir componentes comunes sobre el sistema.
La arquitectura
Especificaciones y modelos de requisitos Problemas de estandarizacin de programas.
Diseos
Cdigos fuente Decisiones de lo que debe poseer una librera y de lo que debe de estar
Documentacin de usuario y tcnica fuera de ella.
Interfases humanas
Datos Desconocimiento de los requerimientos de interfase y de la calidad
interna de los componentes del software.
Casos de prueba
Otros posibles componentes reusables pueden ser: prototipos, esqueletos Desconocimiento de los efectos posibles en el cambio.
de estructuras de programas y de datos, modelos de datos, proceso de control
de ciclo de vida del software, etc. Descripcin y clasificacin de los componentes software.
En el artculo antes mencionado se ofrece un estudio econmico de los No aceptacin por parte de las metodologas.
beneficios encontrados cuando una empresa aplica razonadamente los
principios de reutilizacin con disciplina. Algunas ventajas de la reutilizacin Dificultades en manejo en los cambios.
son:
Un componente software reusable puede costar 25 veces mas que un
Reduce tiempo de desarrollo y costo. componente no diseado para reusabilidad.
Aumenta la calidad del software. Los beneficios de la reusabilidad no son a corto plazo.
La reutilizacin oportunista se produce en aquellas organizaciones que, Facilitar herramientas para soportar un desarrollo basado en software
despus de poseer una amplia experiencia en la construccin de sistemas de reusable.
informacin, tratan de acoplar los mdulos desarrollados anteriormente para
tratar de acortar la planificacin de un determinado proyecto. En los sistemas Manejar una librera de partes reusables.
de reutilizacin oportunista surge el problema de tener que adaptar el software
viejo para que sirva para el nuevo proyecto o seguir el enfoque contrario; es Usar una metodologa de desarrollo que favorezca la reusabilidad.
decir, construir un sistema desde cero pero tratando de reciclar componentes
software del viejo sistema. Afinar la gestin del proyecto esforzndose en el reuso.
Igualmente se debe de planificar el tipo de reutilizacin que se desea para Manejar componentes que cumplan con las siguientes caractersticas:
la empresa y aqu, surge de nuevo el dilema: Construir o comprar. En otras
palabras: Reutilizacin interna o externa. En principio no se debe descartar la o Aditividad: posibilidad de combinar componentes con un mnimo
idea de comprar componentes externos como hacer las factoras de electrnica esfuerzo y sin iteraciones destructivas,
al adquirir sus componentes. Los componentes externos suelen estar bien o Base matemtica formal: que permita la definicin exacta de las
desarrollados, bien probados y, por la difusin de las redes comerciales, suele condiciones en las que puede implementarse cada uno de los
ser ms barato que el construirlos internamente. mdulos para conservar las propiedades de cada componente,
o Autocontenidos: cada componente debe contener una sola idea,
Algunos prefieren construirse sus propias herramientas as como los o Fcil descripcin.
antiguos artesanos disponan de sus tiles de trabajo realizados por ellos o Independencia del lenguaje de programacin,
mismos, sin embargo este camino es bastante costoso y, a no ser que la o Verificable: facilidad a los test,
empresa trate de controlar su propia tecnologa por razones de estrategia de o Interfase simple: nmero de parmetros mnimo,
empresa, esta opcin deber ser desechada de antemano. o Facilidad de cambio.
El xito de los componentes reutilizables se ha fundamentado en los Las herramientas que nos ayuden a gestionar un software reutilizable
nuevos paradigmas de la programacin orientada a objetos que hace que el debern estar basadas en, al menos los siguientes componentes:
equipo de desarrollo se centre en sus problemas y no en utilidades y mdulos
general istas que puede encontrar en el mercado a un precio muy inferior al de Una base de datos documental con capacidad para alojar los
fabricacin interna. Por otra parte la modularidad y la ocultacin de los niveles componentes en su estado puro para poder ser utilizados por los
de datos, junto con el polimorfismo, ha hecho que los fabricantes de software miembros del equipo de desarrollo.
cada da estn confiando ms y ms en los componentes reutilizables.
Un sistema de clasificacin de componentes.
Este tipo de abstraccin de la solucin permite que las empresas de
desarrollo de software sean cada da ms competitivas pudiendo construir sus
Un sistema de recuperacin de los componentes.
soluciones en un menor plazo de ejecucin, de una forma ms fiable y
reduciendo el coste total del producto. Pero para ello vamos a presentar algunas
Un conjunto de herramientas colaborativas.
prcticas que deben llevar a cabo las empresas para reutilizar el software con
calidad:
Una herramienta CASE que identifique y controle el subconjunto de
componentes utilizados en cada proyecto y su gestin de la
Elegir un formalismo apropiado para representar todos los componentes
configuracin.
software reusables.
386 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 C A P T U L O 17: P R Q V h C T O S E S P E C IA L E S DE IN G E N IE R IA DHL S O F T W A R E 387
Definimos como paquete software estndar un entorno soware (conjunto de Una vez decidida la compra de un producto ya desarrollado es muy
programas, bases de datos, herramientas de desarrollo y/o de gestin, importante elegir cual, para ello es aconsejable seguir los siguientes pasos:
documentacin, etc.) que proporciona una cierta funcionalidad y que es
comercializado por una empresa soware que lo ha desarrollado y asegura su 1. Determinar que funcionalidad se quiere que cubra el paquete. Es
continuidad. Segn la importancia del paquete y la empresa comercial, adems conveniente establecer dos listas: funciones fundamentales y deseables.
del propio paquete estndar podemos obtener, al comprar el paquete, ayuda a la
adaptacin del mismo a nuestro entorno y nuestras necesidades de informacin, 2. Estudiar los paquetes existentes en el mercado. Es conveniente hacerse
ayuda a la implantacin, soporte y monitorizacin del sistema durante su aconsejar por consultores especialistas. Es importante tener en cuenta
utilizacin, resolucin on-line y/o batch a consultas y problemas, foros de estos puntos:
usuarios, certificaciones y otros utilidades que proporcionan sus asesores y
consultores. La empresa que distribuye el paquete tenga solvencia, est
establecida en la zona donde se quiere implementar y tenga los
La primera decisin a tomar cuando una compaa decide implantar un recursos necesarios para dar soporte.
sistema informtico es si comprar un paquete software o desarrollar ella misma
los programas que implementen el sistema. Las empresas pequeas no tienen El paquete sea compatible con el hardware existente en la
mucha eleccin ya que no cuentan con los medios para desarrollar un sistema empresa.
tan complejo. Las empresas ms grandes deben decidir entre las ventajas que
tienen ambas posibilidades. Est ya instalado en otras empresas. En este caso sera
conveniente entrar en contacto con los responsables del paquete
Las principales ventajas de comprar un paquete software son las en alguna de estas empresas.
siguientes:
3. Ponerse en contacto con los representantes de los paquetes
En caso de sistemas complejos la necesidad de software (programas, seleccionados dndoles informacin sobre el entorno donde se quiere
datos y documentacin) suele ser muy grande, por lo que el coste de implementar. Ser necesario incluir lo siguiente:
desarrollarlo internamente excede al de la compra.
Lista de la funcionalidad deseada.
El tiempo de desarrollar el software internamente es, seguramente,
menor que el de instalar un paquete comprado, ya hecho y probado. Informacin sobre la cantidad de datos a tratar.
Los analistas y programadores que trabajan en las empresas que Informacin sobre la estructura del hardware existente y la
comercializan estos paquetes poseen una experiencia probada en los posibilidad de ampliarlo con vistas a la nueva instalacin.
temas especficos a implementar.
Informacin sobre el sistema informativo existente con el que
Los paquetes a la venta normalmente estn ya instalados en otras el paquete tendr que convivir y conectarse.
empresas, lo cual implica que han sido ya probados y corregidos.
4. Estudiar las propuestas recibidas. Aquellas que no puedan satisfacer las
En cambio, el principal argumento para desarrollar un paquete en casa es funciones fundamentales debern ser descartadas inmediatamente. Se
que la empresa no encuentre ninguno entre los existentes que cubra sus estudiarn los restantes teniendo en cuenta los siguientes factores de
necesidades. Hace unos aos era una situacin bastante corriente, pero, decisin:
388 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 F O R M T IC O S C A P T U L O 17 P R O Y E C T O S E S PE C IA L E S D E IN G E N IE R IA D EL S O F T W A R E 389
La calidad del soporte a la instalacin: cursos, manuales, Veamos, de forma resumida, las fases fundamentales por las que debe
disponibilidad de personal experto, etc. pasar un proyecto de implantacin de paquetes estndar:
Caractersticas del paquete frente al usuario (user-friendly). 1. Organizacin y diseo conceptual. En esta fase se realiza la
preparacin del proyecto, definiendo objetivos, extensin de la
Facilidad de modificacin y mantenimiento de los programas. implementacin., estndares y estrategias, fechas y secuencias, costes y
organizacin del equipo de proyecto. Tambin se debe definir el
entorno final y proporcionar un entorno de prueba, entrenar al equipo
Coste.
de proyecto, definir funciones y procesos del modelo de negocio,
5. Basndose en estos puntos el grupo de paquetes seleccionado debe determinar parmetros y usuarios clave, as como, interfaces con otros
sistemas y mejoras.
quedar reducido a un nmero entre dos y cuatro. Se har un estudio
ms profundo de estos, con contacto directo con los vendedores del
2. Diseo detallado y realizacin. Durante esta fase se debe detallar la
paquete que incluir presentaciones y demostraciones de
configuracin del sistema segn el diseo conceptual obtenido en la
funcionamiento. Al final se har un informe detallado de cada uno de
fase anterior: establecer la configuracin global, la estructura de la
ellos.
compaa, los datos maestros, etc. Tambin se detallan los procesos
definidos asocindoles una secuencia de funciones existentes en el
6. La alta direccin decidir el paquete a instalar con los datos aportados
paquete, interfases con otros sistemas y/o desarrollos a medida. Por
en el punto precedente.
ltimo se realizan las modificaciones, parametrizaciones y nuevos
desarrollos necesarios.
Hasta ahora hemos visto dos soluciones: comprar software estndar o
3. Migracin. Esta fase cubre los aspectos de formacin y carga de datos
desarrollarlo a medida. A veces es factible una solucin intermedia que incluye
necesarios para el buen funcionamiento del nuevo sistema. Se lleva a
ventajas de las dos anteriores. Esta solucin consiste en comprar un paquete y
cabo la formacin de los usuarios finales en las reas del paquete que
personalizarlo adaptndolo de forma ms precisa a nuestras necesidades. Al
van a utiliza, formando a todos en un modulo inicial de visin general.
adoptar esta solucin hay que elegir cuidadosamente el paquete a comprar
Se realiza el traspaso efectivo de datos manuales o informatizados,
como acabamos de ver, debiendo el paquete elegido realizar todas las
tanto estticos como dinmicos, al nuevo sistema, cargndolos
funciones fundamentales. Adems es conveniente tener en cuenta lo siguiente:
directamente o convirtindolos segn la nueva estructura. La carga de
datos dinmicos (aquellos que estn vivos en la organizacin y pueden
Establecer claramente, antes de empezar las modificaciones, el lmite
ser objeto de actualizacin en cualquier momento) debe realizarse en el
donde se quiere llegar. Es fcil caer en la tentacin de aumentar sin
momento de cierre del sistema viejo.
medida las funciones que se quiere que realice el paquete hasta llegar a
desarrollar prcticamente un software a medida. Esto supone no obtener
4. Puesta en marcha y mantenimiento inicial. Durante esta fase se debe
ninguna de las ventajas de las dos soluciones anteriores.
poner el sistema a disposicin de los usuarios. De forma habitual, las
primeras semanas de utilizacin del sistema necesitan un seguimiento
Crear un grupo de trabajo utilizando personal interno y de la sociedad
cercano: atender las dudas y problemas que encuentran los usuarios en
vendedora o distribuidora del paquete para realizar las modificaciones a
su trabajo, resolver los posibles errores del software (normalmente el
los programas. De esta forma el personal interno responsable en un
software comprado est ya probado y es correcto, por lo que esto se da
futuro del software del paquete adquiere conocimientos fundamentales
ms en interfaces y modificaciones), monitorizar los tiempos de
390 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 F O R M T IC O S
AUDITORIA INFORMTICA
Prof. Roberto Barellino Piala
La auditoria financiera, se realiza para verificar el estado de las cuentas certificacin C'ISA, no basta con superar el examen, sino que tambin se debe
anuales de una organizacin. Para ello, se siguen estndares y normativas que acreditar al menos 5 aos de experiencia en sistemas de informacin y el
estn perfectamente aceptados y son conocidos. El objetivo que se pretende en compromiso de una evaluacin peridica por el ISACA.
este tipo de auditoria, ser el presentar la realidad de la situacin financiera de
la organizacin. El auditor informtico debe poseer una serie de capacidades tcnicas y
ticas que le permitan desarrollar su trabajo con calidad, objetividad y
En la auditora de gestin, se verifican los distintos procesos, correccin. Para conseguir una buena calidad, es fundamental su formacin
procedimientos y tareas que se desarrollan en una organizacin, para lograr la tcnica, diligencia y capacidad profesional, adems de trabajar con
eficacia, eficiencia y reduccin de costes. responsabilidad y guardar siempre el secreto profesional. Debe tener presente
principios ticos, y as aplicarlos durante su funcin auditora, como son la
La finalidad de la auditora de cumplimiento es verificar si las bsqueda de la verdad, independencia, trato no discriminatorio y la no
operaciones, procesos y actividades que se desarrollan dentro de la injerencia.
organizacin se adecan a las normas y estndares establecidos por la propia
direccin. En general, para cualquier tipo de auditoria, y en concreto para la
informtica, se debe avalar, dicha funcin auditora, por el apoyo incondicional
La auditora informtica establece los controles necesarios para verificar de la direccin de la organizacin, si esto no ocurre no se llegar al fin
el correcto funcionamiento de los sistemas y recursos informticos, planes de deseado.
contingencia, seguridad, integridad de los datos, etc. El auditor informtico
en una organizacin se debe establecer como el garante de la veracidad, validez
y completitud de la informacin que usa la organizacin. 18.2 SISTEMA DE CONTROL INTERNO EN TECNOLOGAS DE LA
INFORMACIN
Por supuesto, la funcin del auditor informtico depender de una serie de
factores, que en general son: la propia organizacin de la empresa, es decir, qu La informacin que se utiliza en cualquier organizacin, se define, de manera
nivel de importancia le dan a las tecnologas de la informacin la direccin; la informal, como los datos que han sido manipulados para tomar, con ellos, una
estructura interna de la funcin informtica y las relaciones que deben existir decisin. No slo en un entorno informtico, sino tambin en entornos
entre los distintos mbitos o departamentos de la empresa. financieros, de gestin, de coordinacin, de personal, etc. Por tanto, no es
exagerado afirmar, que la informacin es un bien preciado en una empresa, ya
En la actualidad, un auditor informtico tiene a su disposicin una serie de que si se posee una correcta informacin, la calidad en la toma de decisiones
asociaciones profesionales a nivel internacional y nacional que le ayudan y ser ptima.
aconsejan en la realizacin de la funcin de auditoria informtica. A nivel
nacional, podemos destacar ALI (Asociacin de Doctores, Licenciados e El trmino conocido como control interno, se puede ver como el proceso,
Ingenieros en Informtica) que an no siendo su principal objetivo, si que avalado por la direccin de la organizacin, que asegura en la medida de lo
puede orientar y encaminar cualquier problema de un profesional sobre la posible que se alcanzarn los objetivos de negocio. En nuestro caso, desde el
realizacin de una auditoria informtica. La asociacin ms importante de punto de vista de las tecnologas de la informacin a travs de la
carcter internacional es ISACA (International Standard Audit & Control implementacin de una auditoria informtica.
Association) que tiene como funciones bsicas la realizacin de un cdigo de
tica profesional (independencia y objetividad), la emisin de normas o Pero, cmo se da cuenta una organizacin de la necesidad de implantar
sistemas de control que garanticen la calidad de la funcin de cualquier tipo de un sistema de control interno? Existen una serie de sntomas que hacen
auditoria informtica y la certificacin internacional mediante un examen necesaria, en una organizacin, el establecimiento de un marco de control
CISA (Certified Information Systems Auditor). La certificacin CISA es interno. La auditora informtica verifica y evala los controles internos
promovida por el ISACA una vez al ao en prcticamente todos los pases del establecidos en una empresa. Algunos de los factores que hacen necesario el
mundo, en Espaa, por supuesto, tambin se realiza. Aunque, para obtener la desarrollo de un sistema de control interno son:
394 P L A N I F I C A C I N Y G E S T I N D E S IS T E M A S IN F O R M T I C O S C A P T U L O 18 A U D IT O R IA IN F O R M T IC A 395
La informacin no es fiable.
Los objetivos del negocio y las tecnologas de la informacin de la
organizacin no estn alineados.
Incremento considerable en inversiones informticas no justificadas
razonablemente.
Descontrol e infrautilizacin de los recursos informticos de la
organizacin.
Los usuarios / clientes no son atendidos, ni se solucionan sus problemas
ante cualquier incidencia informtica o si se soluciona sta llega
demasiado tarde.
Dentro del dominio, adquisicin e implcmentacin, las soluciones que la MI Supervisar procesos.
organizacin incorpore sobre las Tecnologas de la Informacin deben ser M2 Evaluar la suficiencia del control interno.
identificadas, desarrolladas o adquiridas a terceros, as como implementadas e M3 Obtener seguridad independiente.
integradas dentro del proceso de negocio. Adems, este dominio cubre los M4 Proporcionar auditoria independiente.
cambios y el mantenimiento realizado a sistemas ya existentes. El dominio est T abla 18.4 O bjetivo s de C ontrol d e l D om inio Supervisin.
formado por los siguientes objetivos de control, que se muestran:
Dentro de cada objetivo de control, de los relacionados anteriormente, se
A ll Identificar soluciones. establecen una serie criterios, indicadores y factores que sirven para medir el *
AI2 Adquirir y mantener el software. grado de adecuacin del objetivo de control con las prcticas desarrolladas en
AI3 Adquirir y mantener la arquitectura tecnolgica. la organizacin.
AI4 Desarrollar y mantener procedimientos en tecnologas de la informacin.
AI5 Instalar y verificar sistemas. En todos los objetivos de control, aparecen la definicin y enumeracin de
AI6 Gestionar cambios._________________________________________________ los factores crticos para el xito, que son una serie de acciones importantes
que de no realizarse son crticas para el xito del objetivo que se est
T abla 18.2 O b jetivo s d e C ontrol d el D o m in io A d q u isici n e Im plantacin.
evaluando. Por ejemplo, un buen estudiante debe: estudiar todos los das, asistir
a clase, realizar las prcticas encomendadas, etc. dentro de estas tareas es un
En el dominio, entrega y soporte, se hace referencia a la entrega de los factor crtico para el xito, la actividad estudiar todos los das, ya que si no se
servicios requeridos, que abarca desde las operaciones ms tradicionales hasta realiza, el objetivo que es aprobar el examen de una asignatura, no tendr
la formacin del personal, pasando por la seguridad y aspectos de continuidad lugar.
del negocio. Los objetivos de control del dominio entrega y soporte son los
siguientes: Los indicadores de objetivos clave establecen una serie de medidas que
39 8 P L A N IF IC A C I N Y G E S T I N D E SIST E M A S IN F O R M A T IC O S C A P T U L O 18: A U D IT O R IA IN F O R M A T IC A 399
indican, despus de realizar un proceso, la eficacia de ste. Por tanto, indicar Elaborar el informe final.
si un proceso ha alcanzado o no sus objetivos. Elaborar un plan de ayuda.
Los indicadores de rendimiento clave, presentes en todos los objetivos de A continuacin se desarrollan brevemente cada una de stas fases:
control, indican el grado de eficiencia, es decir, lo bien que se est
desarrollando el objetivo de control. Ser, por tanto, una vigilancia interna de 1. Estudio inicial de los Sistemas de Informacin que se van a
los procesos que se implementan en un objetivo de control. evaluar y de la propia organizacin. Tambin es importante,
conocer el alcance y objetivos de la auditoria a realizar, que
debern estar consensuados con la direccin de la organizacin.
18.3 ORGANIZACIN Y FASES DE LA AUDITORIA INFORMTICA Los objetivos por los cuales se realiza el estudio inicial, estn
normalmente relacionados con la reduccin de los costes, aumento
Un departamento de auditoria informtica deber estar formado, si es posible, de la calidad, y en general la operatividad ptima de los Sistemas
por profesionales con perfil informtico, que posean el certificado CISA. En de Informacin.
general, un auditor informtico, debe conocer y mantener los conocimientos
terico-tcnicos para realizar su trabajo de forma adecuada, as pues, se deben 2. Elaborar un plan de trabajo, establecindose los recursos (tanto
establecer planes de formacin continua del personal adscrito al departamento materiales como humanos) y los hitos necesarios para establecer
de auditoria informtica. En dicho departamento, se nombrar a un director, los puntos de control en el desarrollo de la auditoria informtica.
quien ser el responsable de la elaboracin de un plan operativo de trabajo, este
plan ser llevado a la prctica, por un nmero indeterminado de auditores que 3. Desarrollar la auditoria. Donde se implementa el plan de trabajo
sern quienes realicen las distintas auditorias informticas. El tamao del de la etapa anterior. Esta fase la podemos considerar como la
departamento (nmero de auditores), como es lgico, depender de las auditoria propiamente dicha, utilizando para ello las diferentes
funciones encomendadas por la propia direccin de la organizacin. El tcnicas o herramientas comentadas anteriormente.
departamento rendir cuentas nicamente a la direccin de la organizacin.
4. Elaborar el Diagnstico. Establecer los puntos fuertes y dbiles,
Las herramientas o tcnicas que existen para realizar una auditoria riesgos importantes y leves y por supuesto, si es posible, identificar
informtica son las siguientes: las soluciones de los problemas encontrados.
Cuestionarios / Check lists. 5. Elaborar el informe final. Se crea un informe con las
Las tpicas entrevistas con el personal implicado. conclusiones obtenidas en la fase anterior. Este documento deber
Software especfico de auditoria. tener una redaccin adecuada al personal destinatario del
documento, es decir, la propia direccin de la organizacin.
Con el uso de estas tcnicas, aun cuando el principal valuarte es el
conocimiento y la experiencia del auditor, se puede desarrollar una auditoria 6 . Elaborar un plan de ayuda. Establecer las actividades necesarias
informtica, sta tiene siempre una serie de fases que dependen en cierta para solucionar en la medida de lo posible las deficiencias
medida del propio problema a auditar. Las etapas tpicas de la auditoria encontradas en el proceso de la auditoria informtica.
informtica son:
En cuanto a la estrategia general en una organizacin respecto de la
Estudio inicial. implantacin de la funcin de auditoria informtica, se aconseja elegir entre
Elaborar un plan de trabajo. seguir una auditoria contina durante todo el proceso que implique el uso de
Desarrollar la auditoria. las tecnologas de la informacin, estableciendo revisiones en puntos de control
determinados por su importancia o criticidad; o realizar slo una auditoria
Elaborar el diagnstico.
previa y posterior a dicho proceso que valide los resultados previstos y
400 PL A N IFIC A C I N Y G ESTIO N DE SISTEMAS INFORM TICOS _________________________________ CAPTULO 18: AUDITORIA IN FO R M TIC A _ _____ ________ 401
determine su alineacin con los objetivos de negocio. contingencia sea cual sea la gravedad de los accidentes ocurridos y las
coberturas de los seguros suscritos.
18,4 CLASES DE AUDITORIA INFORMTICA Un apartado aparte, se merece la proteccin de los datos confidenciales,
ya que en este tipo de datos tienen un tratamiento especial1. La
Existen diferentes tipos de auditoria informtica, a continuacin se comenta auditora de la seguridad verificar la existencia de tcnicas para
brevemente algunas de las clases de auditoria informtica ms importantes. conseguir la integridad, proteccin, consistencia y exactitud de los
datos confidenciales, normalmente este tipo de tcnicas estn
La auditoria de la gestin de los Sistemas de Informacin, se llevar a relacionadas con la criptografa, que cifra los datos especialmente
cabo mediante dos tareas fundamentales: sensibles tanto dentro de un nico sistema informtico como en la
comunicacin entre distintos sistemas informticos.
La primera, la planificacin, donde se verifican la existencia de planes a
corto, medio y largo plazo sobre tecnologas de la informacin en La auditoria de las comunicacioncs corporativas tanto internas (Redes
relacin con los objetivos de negocio de la propia organizacin. de Area Local / Intranet) como externas (Internet), debe verificar, gestionar,
controlar y proteger las comunicaciones y a los usuarios. La auditoria debe
La segunda actividad ser la coordinacin, que controlar que se tener en cuenta una serie de puntos que se enumeran a continuacin:
alcancen los objetivos incorporados en los planes de Sistemas de
Informacin, en esta actividad aparece un elemento importante como es La gestin y diseo adecuado de las redes de ordenadores corporativas,
el de Comit o Consejo de Informtica, cuya tarea fundamental ser la incorporando sistemas de control de gestin para controlar tanto la
de planificar y organizar la propia funcin informtica de la propia informacin de las comunicaciones como a los usuarios.
organizacin, el Consejo aprobar o no los planes, las inversiones
(gestin econmica) y ser adems un punto de dialogo entre los * Control de la gestin de la seguridad de las comunicaciones. La
usuarios y los informticos. proteccin de los datos de la red, ya sea utilizando tcnicas
criptogrficas o en casos extremos seguridad fsica. Se recomienda e
La auditoria de la seguridad con extensiones sobre la integridad y la uso de herramientas de seguridad.
confidencialidad de los datos personales, tiene como objetivo bsico el
asegurar el mantenimiento de la funcin informtica de una empresa. Para * Control de la gestin de las comunicaciones desde el punto de vista de
cumplir este objetivo, aparecen distintos puntos de vista de la seguridad: protocolos de comunicaciones implicados en todas las comunicaciones
de la organizacin.
Seguridad Fsica, de las instalaciones y materiales. La auditoria de la
seguridad verificar las medidas ante por ejemplo, un incendio, Control de explotacin de la red, a travs de la formacin del personal
climatizacin adecuada, proteccin de acceso fsica a algunas adecuado, revisiones de las comunicaciones de la red, escalabilidad y
estancias, etc. crecimiento de la red, etc.
Seguridad Lgica, de los principales datos de la organizacin, La auditoria de la produccin software, donde se verifican los criterios
verificando los sistemas de copias de seguridad, controlando los de adquisicin, desarrollo y mantenimiento de aplicaciones software. La
accesos a los sistemas informticos y utilizando tcnicas de auditoria comprobar:
autenticacin como es, por ejemplo, la de usuario/contrasea. Tambin
es importante que se almacene cierta informacin sobre quien entra, Las normas para la adquisicin del software que necesita la
cuando y que hace en el sistema. organizacin y un seguimiento de los contratos de compra realizados,
Planes de contingencia y Seguros. Se deben verificar los planes de 1 Ley Orgnica 15/99 de 13 de Diciembre de Proteccin de D atos de Carcter Personal
402 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 F O R M T IC O S
Integracin. Describe las medidas necesarias para garantizar una Desarrollados por personas.
coordinacin adecuada de los distintos elementos del proyecto. Limitados por recursos determinados.
Alcance. Describe los pasos que hay que seguir para asegurar Son planificados, ejecutados, y controlados.
que el trabajo realizado para terminar el proyecto con xito sea
el necesario y no exceda los lmites del campo en cuestin. Las operaciones y los proyectos difieren principalmente en que las
Tiempo. Describe los procesos requeridos para asegurar que el operaciones son sucesivas y repetitivas mientras que los proyectos son
cumplimiento de los tiempos del proyecto. temporales y nicos. El hecho de que sea temporal implica que tiene definido
Costos. Describe las decisiones y medidas a tomar para un inicio y un fin, cuando los objetivos se han cumplido o se da por verificado
garantizar que el coste del proyecto no supere el presupuesto que no pueden cumplirse. El hecho de que sea nico quiere decir que el
aprobado. producto o servicio es diferente de todos los productos o servicios similares.
Calidad. Describe el modo de proceder para conseguir el fin con
el cual el proyecto ha sido concebido satisfaciendo todas las Los proyectos pueden desarrollarse por un solo departamento o incluir a
necesidades definidas. toda la organizacin, pueden durar das o aos e involucrar a pocas personas o
a cientos de ellas. Iodos son proyectos.
Recursos Humanos. Describe el mtodo de distribucin del
trabajo entre las personas para lograr el mejor uso de las
La gestin de proyectos es la aplicacin de conocimientos, habilidades,
cualidades de cada participante en el proyecto.
herramientas y tcnicas a actividades de proyectos de forma que cumplan las
Comunicacin. Describe los pasos necesarios para realizar a
necesidades (requisitos identificados) y expectativas (requisitos no
tiempo la generacin, recopilacin, disposicin,
identificados) de los peticionarios del proyecto. Cumplir estas necesidades o
almacenamiento y difusin de manera puntual y adecuada de la
expectativas significar llegar a un compromiso entre las diferentes personas
informacin sobre el proyecto.
involucradas en cuanto a alcance, tiempo, coste y calidad.
Riesgos. Describe las decisiones oportunas para la
identificacin, anlisis y tratamiento de los riesgos que conlleva
Los proyectos y la administracin de proyectos operan en un ambiente ms
el proyecto.
amplio que el del proyecto mismo. Administrar da a da las actividades del
Consecucin. Describe la manera de adquirir productos y proyecto es necesario para el xito de este, pero no suficiente. Hay que definir
servicios de entidades externas que no pertenecen al mbito de un contexto de trabajo y una forma de organizacin que PMBOK establece en
organizacin del proyecto. tres apartados: Fases y Ciclo de Vida, Procesos y reas de Conocimiento.
406 PL A N IFIC A C I N Y G E S T I N DE SIST E M A S IN FO R M T IC O S ANEXO I: P R O JE C T M A N A G E M E N T B O D Y O F K N O W L E D G E (P M B O K ) 407
No hay que confundir el ciclo de vida del proyecto con el ciclo de vida del
producto.
A1.3 PROCESOS
Reconoce que el proyecto debe comenzar y compromete a toda la organizacin o Desarrollo de la programacin. Analizar la secuencia de las
con ello. actividades, la duracin de cada una y las necesidades de
recursos para poder crear la programacin del proyecto.
El proceso de Iniciacin contiene un nico subproceso:
o Planificacin de recursos. Determinar que recursos (personas,
Iniciacin. Comprometer a la organizacin para que se de comienzo a la equipos, materiales, etc.) y que cantidad de cada uno de ellos se
siguiente fase del proyecto. debe utilizar para ejecutar las actividades del proyecto.
Desarrolla y mantiene un esquema revisable de tareas a desarrollar para o Presupuesto de los costes. Descomponer la estimacin general
completa^ el proyecto. Este esquema se denomina plan del proyecto. de costes entre los tems individuales de trabajo.
El proceso de Planificacin divide sus subprocesos en dos tipos: o Desarrollo del plan del proyecto. Obtener un solo documento
coherente, y lgico integrando los resultados de otros procesos
Subprocesos bsicos. Algunos procesos de planificacin tienen unas de planificacin.
dependencias claras que requieren que sean ejecutados de la misma
manera en la mayora de los proyectos. Estos subprocesos pueden ser Subprocesos de facilitacin. Las interacciones entre este tipo de
repetidos varias veces durante cualquier fase de un proyecto. Son los procesos de planificacin dependen ms de la naturaleza del proyecto.
siguientes: Aunque estos procesos son ejecutados de forma intermitente y cuando
son necesarios durante el proyecto, no son opcionales.
o Planificacin del alcance del proyecto. Desarrollar un
documento de alcance del proyecto que sirva de base a o Planificacin de la calidad. Identificar que estndares de calidad
decisiones futuras. son relevantes al proyecto y determinar como satisfacerlos.
o Definicin del alcance del proyecto. Subdividir las principales o Planificacin organizativa. Identificar, documentar, y asignar
entregas del proyecto en componentes ms pequeos y roles en el proyecto, responsabilidades y relaciones de
manejables. comunicacin.
o Definicin de las actividades. Identificar las actividades o Adquisicin del personal. Conseguir los recursos humanos
especficas que tienen que ser desarrolladas para poder producir necesarios, asignarlos y ponerlos a trabajar en el proyecto.
los entregables del proyecto.
o Planificacin de las comunicaciones. Determinar las
o Secuencia de las actividades. Identificar y documentar las necesidades de informacin y comunicacin entre los
interdependencias de las actividades. participantes interesados del proyecto: quien necesita que
informacin, cuando la necesitar y como se le entregar.
110 PL A N IF IC A C I N Y G ES TIN D E SIS T E M A S IN FO R M T IC O S A N EX O I: P R O JE C T M A N A G E M E N T B O D Y O F K N O W L E D G E (P M B O K ) 411
o Identificacin del riesgo. Determinar que riesgos posiblemente o Desarrollo del equipo. Desarrollar las habilidades individuales y
afecten al proyecto y documentar las caractersticas de cada uno. de grupo para la mejora del desarrollo del proyecto.
o Anlisis cualitativo de riesgos. Evaluar para cada riesgo o Distribucin de la informacin. Hacer que la informacin
identificado su vulnerabilidad o probabilidad de que ocurra ese necesaria esle disponible para los participantes interesados del
riesgo. proyecto de manera oportuna.
o Anlisis cuantitativo del riesgo. Evaluar para cada riesgo o Realizacin de solicitudes. Documentar y hacer pblicas las
identificado el impacto que puede producir en el proyecto. solicitudes.
o Desarrollo de la respuesta al riesgo. Definir actividades de o Seleccin de fuentes. Escoger entre proveedores interesados.
mejora, de minimizacin del riego y de respuesta a amenazas.
o Administracin del contrato. Administrar las relaciones con el
o Planificacin de adquisiciones. Determinar que adquirir y proveedor.
cuando.
Gestin de Proyectos
o Control de calidad. Monitorizar resultados especficos del
proyecto para determinar si cumplen con los estndares
relevantes de calidad e identificar las acciones a tomar para
eliminar las causas que producen resultados no satisfactorios. G estin del Tiemoo II Gestin de Intearacin Gestin de Calidad
Definicin de actividades | Desarrollo del plan del proyecto. Planificacin de la calidad
Secuencia de actividades B Ejecucin del plan del proyecto Aseguramiento de la calidad
o Monitorizacin y control de riesgos. Seguir las posibles Estimacin duracin de actividades 1 _ Control general de cambios Control de calidad
Desarrollo de la programacin 1
situaciones de riesgo y los posibles cambios en los riesgos Control de la programacin N
Planificacin de adquisiciones (Planificacin). Revisar todo el texto para asegurar que sea claro, completo y relevante.
Planificacin de solicitudes (Planificacin).
Realizacin de solicitudes (Ejecucin). Asegurar la consistencia en la terminologa y ubicacin de entradas,
Seleccin de fuentes (Ejecucin). salidas, herramientas y tcnicas de los procesos. Identificar el origen de
Administracin del contrato (Ejecucin). todas las entradas y el destino de todas las salidas.
Cierre del contrato (Cierre).
Cambiar el texto cuando sea posible con el fin de mejorar la
traducibilidad del documento y considerar palabras y frases que puedan
tener connotaciones culturales negativas.
A l . 10 V E R S I N 2004
Ampliar el ndice y el glosario.
El Project Management Institute ha emitido la ltima versin del PMBOK que
ser publicada a fines del 2004. En el prefacio al borrador de esta tercera Corregir errores existentes en el documento anterior.
edicin del PMBOK, PMI explica el alcance del proyecto de actualizacin de
la versin 2000 del PMBOK citando los siguientes puntos: Las principales diferencias entre la versin anteriormente desarrollado en
este libro (versin 2000 ) con el borrador de la nueva versin (versin 2004)
Cambiar los criterios para la inclusin de material pasando de son las siguientes:
generalmente aceptados en la mayor parte de los proyectos la mayor
parte del tiempo a generalmente reconocidos corno buenas prcticas 1. Se ha clarificado la distincin entre los ciclos de vida del
en la mayor parte de los proyectos la mayor parte del tiempo. De esta proyecto y ciclo de vida del producto.
forma se hace hincapi en que el conocimientos y prcticas descritas se
aplican a la mayor parte de proyectos la mayor parte del tiempo, y que 2. Se han incrementado los procesos definidos de 39 a 44.
hay un consenso amplio sobre su utilidad y valor.
3. Se ha expandido el foco de los Grupos de Procesos y procesos
Aadir nuevo material que refleje el crecimiento de las prcticas y versus las reas de conocimiento.
conocimientos en el campo de la gestin de proyectos documentando
aquellas prcticas, herramientas y tcnicas u otros tems relevantes que 4. Se ha cambiado de nombre y lugar al Captulo 3 (Los Procesos
generalmente se reconocen como buenas prcticas. de Gestin de Proyectos para el proyecto). Como parte de este
cambio se ha revisado en profundidad el Captulo 3 sobre los
Ampliar la importancia y el tratamiento de los Grupos de Procesos. procesos de la gestin de proyectos con el fin de indicar que los
procesos, entradas y salidas mencionadas en este captulo son la
Ampliar el tratamiento de la integracin y transmitir de una manera ms base del estndar para la gestin de proyectos en un proyecto
nico. Se han reubicado los procesos de la gestin de proyectos
apropiada su importancia para los proyectos.
418 P L A N IFIC A C I N Y G E S T I N DE SISTE M A S IN FO R M TIC O S A N EX O 1: P R O JE C T M A N A G E M E N T B O D Y O F K N O W L E D G E ( PM H O K > 419
con el fin de mostrar la integracin de los procesos. Se lian Se introdujo un nuevo diagrama denominado Estructura de
aadido seis procesos y se ha cambiado el nombre a 14 Descomposicin de los Riesgos (Risk Breakdown Structure).
procesos.
15. Se ha ahora incluido informacin sobre retroalimentacin
5. Se ha ampliado el Grupo de Procesos de Inicio y el Grupo de {feedback) y sobre las reuniones de revisin del estado del
Procesos de Cierre. proyecto para acentuar la importancia de estos procesos en la
comunicacin en el proyecto.
6 . Se ha aadido Monitorizacin al Grupo de Procesos de Control
ya existente. 16. Todas las entradas, herramientas y tcnicas y salidas se han
revisado para soportar una mejor integracin de los procesos.
7. Se ha enfatizado la necesidad de mencionar los cinco Grupos de
Procesos y sus procesos constitutivos en cada proyecto. 17. El glosario se ha revisado significativamente y se han aadido
trminos. Algunos trminos se han clasificado para evitar
8. Se ha revisado y ampliado la discusin de la integracin y su confusiones.
importancia para la gestin del proyecto y para su xito. Este
cambio proporciona ms detalles de las interrelaciones entre los 18. Se han aadido los siguientes procesos:
procesos, incluyendo los procesos de inicio y cierre del Desarrollo del Chartcr del Proyecto (Seccin 4.1)
proyecto. Desarrollo del Documento del Alcance del Proyecto
(Seccin 4.2).
9. Se ha aadido una seccin que identifica las reas de Monitorizacin y Control del Trabajo del Proyecto
experiencia necesaria para un proyecto, dada la gran cantidad de (Seccin 4.5)
reas en las que el equipo de proyecto debe tener competencia. Cierre del Proyecto (Seccin 4.7)
Crear el WBS (Seccin 5.3)
10. Se ha ampliado la descripcin los distintos usos de la Oficina de Estimacin de los Recursos para las Actividades
Gestin de Proyectos en las organizaciones {Project (Seccin 6.3)
Management Office) Gestionar al Equipo del Proyecto (Seccin 9.4)
ANEXO II
r
r Gestin de Proyectos de la Administracin
f Publica Espaola (METRICA)
(
(
(
MTRICA es una metodologa de planificacin, desarrollo y mantenimiento de
r
sistemas de informacin. La metodologa de desarrollo de sistemas METRICA
( fue diseada por la Subdireccin General de Coordinacin Informtica del
( Ministerio para las Administraciones Pblicas ante la necesidad de disponer de
r una Tecnologa de la Informacin que soportara dinmica y eficazmente el
( funcionamiento normal de los distintos departamentos que componen la
Administracin a medida que creca el volumen de informacin a manejar pol
(
la misma. Esta metodologa y las tcnicas y herramientas aconsejadas estn
r
disponibles en la Web del Consejo Superior de Informtica: vvww.map.es/csi.
r
( La metodologa METRICA Versin 3 ofrece a las Organizaciones un
r instrumento til para la sistematizacin de las actividades que dan soporte al
c ciclo de vida del software dentro del marco que permite alcanzar los siguientes
objetivos:
r
( Proporcionar o definir Sistemas de Informacin que ayuden a conseguir
( los fines de la Organizacin mediante la definicin de un marco
r estratgico para el desarrollo de los mismos.
(
( Dotar a la Organizacin de productos software que satisfagan las
necesidades de los usuarios dando una mayor importancia al anlisis de
(
requisitos.
(
( Mejorar la productividad de los departamentos de Sistemas y
( Tecnologas de la Informacin y las Comunicaciones, permitiendo una
( mayor capacidad de adaptacin a los cambios y teniendo en cuenta la
< reutilizacin en la medida de lo posible.
<
Facilitar la comunicacin y entendimiento entre los distintos
(
participantes en la produccin de software a lo largo del ciclo de vida
(
(
(
422 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 F O R M T IC O S A N E X O I I : G E S T I N DI: P R O Y E C T O S D E LA A D M IN IS T R A C IO N P B L IC A E S P A O L A (M E T R IC A ) 423
del proyecto, teniendo en cuenta su papel y responsabilidad, as como GESTIN DE CONFIGURACIN (GC).
las necesidades de todos y cada uno de ellos. ASEGURAMIENTO DE CALIDAD (CAL).
SEGURIDAD (SEG).
Facilitar la operacin, mantenimiento y uso de los productos software
obtenidos.
En el desarrollo de METRICA se han considerado las metodologas y A2.1 INTERFAZ DE GESTIN DE PROYECTOS I)E MTRICA
proyectos de estandarizacin en curso siguientes: VERSIN 3
SSADM: Metodologa Pblica Britnica. La Gestin de Proyectos tiene como finalidad principal la planificacin, el
MER1SE: Metodologa Pblica Francesa. seguimiento y control de las actividades y de los recursos humanos y
SUMMIT-D: Metodologa de Coopers & Lybrard. materiales que intervienen en el desarrollo de un Sistema de Informacin.
EUROMTODO: Marco Metodolgico Europeo. Como consecuencia de este control es posible conocer en todo momento qu
Plan General de Garanta de Calidad aplicable al desarrollo de equipos problemas se producen y resolverlos o paliarlos de manera inmediata.
lgicos.
La Interfaz de Gestin de Proyectos de MTRICA Versin 3 contempla
MTRICA Versin 3 tiene un enfoque orientado al proceso que cubre el proyectos de desarrollo de Sistemas de Informacin en sentido amplio. Es
Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de decir, acorde con EUROMTODO se consideran proyectos de desarrollo de
Informacin. La metodologa descompone cada uno de los procesos en nuevos Sistemas de Informacin y tambin los proyectos de ampliacin y
actividades, y stas a su vez en tareas. As los procesos de la estructura mejora de los ya existentes; estos ltimos, contemplados en MTRICA
principal de MTRICA Versin 3 son los siguientes: Versin 3 al proceso de Mantenimiento del Sistema de Informacin (MSI).
PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI). Las actividades de la Interfaz de Gestin de Proyectos se presentan en el
DESARROLLO DE SISTEMAS DE INFORMACIN. siguiente esquema, en el que se aprecian las reas que cubre. Se distinguen tres
MANTENIMIENTO DE SISTEMAS DE INFORMACIN (MSI). grupos de actividades:
En cuanto al Proceso de Desarrollo de Sistemas de Informacin, para Actividades de Inicio del Proyecto (GPI). AI principio del proyecto, al
facilitar la comprensin y dada su amplitud y complejidad se ha subdividido en concluir el proceso Estudio de Viabilidad del Sistema, se realizarn las
cinco procesos: actividades de Estimacin de Esfuerzo y Planificacin del proyecto.
ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS). Actividades de Seguimiento y Control (GPS). Comprenden desde la
ANLISIS DEL SISTEMA DE INFORMACIN (ASI). asignacin de las tareas hasta su aceptacin interna por parte del equipo
DISEO DEL SISTEMA DE INFORMACIN (DSI). de proyecto, incluyendo la gestin de incidencias y cambios en los
CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI). requisitos que puedan presentarse y afectar a la planificacin del
IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS). proyecto. El Seguimiento y Control del proyecto se realizan durante los
procesos de Anlisis, Diseo, Construccin, Implantacin y
En una nica estructura la metodologa MTRICA Versin 3 cubre Aceptacin, y Mantenimiento del Sistema de Informacin, para vigilar
distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a el correcto desarrollo de las actividades y tareas establecidas en la
travs de interfaces la realizacin de los procesos de apoyo u organizativos: planificacin.
Actividades de Finalizacin del Proyecto (GPF). Por ltimo, al concluir Como mtodo sirve para definir, planificar y ejecutar la adquisicin de un
el proyecto se realizan las tareas propias de Cierre del Proyecto y sistema de informacin y los servicios relacionados. Se utiliza para valorar y
Registro de la Documentacin de Gestin. determinar:
La figura A 2.1 muestra la relacin entre la interfaz de Gestin de la situacin del problema y los riesgos asociados
Proyectos y los procesos principales de METRICA. el objetivo de la adquisicin
la estrategia de ia adquisicin, de la adaptacin del sistema de
informacin y de la provisin de servicios
el "plan de entregas", el aspecto ms relevante de las relaciones cliente-
proveedor a nivel contractual.
El seguimiento y control del proyecto tiene como objetivo fundamental la El objetivo de esta actividad es la asignacin de tareas a los miembros del
vigilancia de todas las actividades de desarrollo del sistema. Es una de las equipo de proyecto, documentando los datos necesarios para su control
labores ms importantes en todo desarrollo de sistemas, ya que un adecuado posterior.
control hace posible evitar desviaciones en costes y plazos, o al menos
detectarlas cuanto antes. Esta actividad tiene una nica tarea:
La figura A2.2 muestra la secuencia de actividades de Seguimiento y Tarea GPS 1.1: Asignacin de Tarea. Para que una tarea finalice con
Control del Proyecto: xito es importante asignarla a un tcnico capaz de desarrollarla, por lo
que el Jefe de Proyecto debe estudiar muy bien cada tarea antes de su
GPS6
Aribsisde GPS7
Aprobacin
asignacin y ser consciente de los conocimientos y capacidades de los
la peticin
delasoludt
requisitos
de cambio componentes del equipo de proyecto. El Jefe de Proyecto debe reflejar
en la planificacin las asignaciones realizadas, indicando el nombre del
tcnico, nombre y descripcin de la tarea, esfuerzo estimado, fecha real
GPS1 GPS 2 GPS 3 GPS10 GPS12
GPS 13
Asignacin Corrunioao Seguimenti Fmazacit
efe ricrea
_ Reunrcnesch
seguimento Aceptacin de comienzo y fecha prevista de finalizacin.
delatada alequpo detareas
de tareas del proyecto pianificaceli
Dentro de las actividades de Seguimiento y Control se trata de manera Esta actividad tiene una nica tarea:
especial la Gestin de Incidencias, que puede ser la clave del xito o fracaso de
un proyecto. Incidencias son aquellos hechos inesperados y anmalos que se Tarea GPS 2.1: Informar al Equipo del Proyecto. El Jefe de Proyecto
presentan durante la realizacin de las actividades y tareas del proyecto, y que informa a los integrantes del equipo de las caractersticas del proyecto,
producen desviaciones en la planificacin. haciendo especial nfasis en sus caractersticas particulares. Una vez
que todos los miembros del equipo conocen el proyecto global,
Mencin especial merecen los cambios de requisitos, ya que son un tipo comunica la asignacin de trabajos a cada uno de los miembros.
especial de incidencia que exige un tratamiento especial. Uno de los propsitos
del establecimiento de procedimientos para la Gestin de Cambios en los Actividad GPS 3: Seguimiento de tarcas
Requisitos es el de asegurar que, cuando existan cambios en los
requerimientos, su impacto en el proyecto pueda cuantificarse y acordarse con Esta actividad tiene como objetivo el control de todas las tareas que estn
el Cliente o Usuario en cuanto a plazo, esfuerzo y compensacin econmica si siendo desarrolladas, revisando con cada uno de los responsables de las tareas
corresponde. Adems, para cada cambio, se registrar la siguiente informacin: cul es su estado en el momento del seguimiento, su evolucin previsible y los
Formulario de Peticin de Cambio. problemas que estn encontrando para su desarrollo.
Catlogo de Necesidades.
Anlisis Funcional del Cambio. Esta actividad tiene una nica tarea:
Estimacin de Esfuerzo.
Variaciones en Coste y Plazos. Tarea GPS 3.1: Seguimiento de Tareas. El responsable de cada tarea
debe informar de:
A ctividad GPS I: A signacin d etallada de tareas
o La fecha real de comienzo.
430 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 F O R M T IC O S ANEXO I I : G E S T I N D E P R O Y E C T O S DO LA A D M IN IS T R A C I N P B L IC A E S P A O L A (M E T R IC A ) 431
o El tiempo empleado hasta el momento en su realizacin, medidas necesarias de forma que no vuelvan a producirse o, al menos,
o Apreciacin del tiempo que queda para terminarla, que se reduzcan en la mayor medida posible, y por otra parte para que
o El tanto por ciento de avance sobre el total, los costes originados por dichas incidencias sean imputados a quien
o Los problemas o incidencias encontradas. corresponda. Toda incidencia producida durante el desarrollo del
proyecto debe reflejarse en el Registro de Incidencias.
A partir de la informacin obtenida del equipo de desarrollo, el Jefe de
Proyecto debe determinar el estado de cada tarea, indicando la previsin Actividad GPS 5: Peticin de cambios de requisitos
de finalizacin de cada una. Asimismo, debe prestar atencin a las
incidencias y desviaciones. La primera actividad en la Gestin de Cambios es la peticin realizada por el
usuario para alterar las especificaciones iniciales.
Actividad GPS 4: Anlisis y registro de la incidencia
Esta actividad tiene una nica tarea:
Con esta actividad se persigue conocer el impacto producido por una
incidencia en cuanto a: Tarea GPS 5.1: Registro de la Peticin de Cambio de Requisitos. El
usuario formula una peticin de cambio de los requisitos iniciales, que
Tareas afectadas por la incidencia. hace llegar al Jefe de Proyecto. Cuando el Jefe de Proyecto la recibe
Horas de trabajo perdidas. debe registrarla de inmediato.
Retrasos ocasionados.
Actividad GPS 6: Anlisis de la peticin de cambio de requisitos
Esta actividad se compone de las siguientes tareas:
Toda peticin de cambio debe ser analizada en detalle por el Equipo del
Tarea GPS 4.1: Analizar Impacto. Es fundamental conocer que tareas se Proyecto, contemplando los posibles cambios en la funcionalidad y el impacto
vern afectadas por una incidencia, en mayor o menor grado, para que el cambio pedido tendra sobre el resto del Sistema de Informacin.
poder realizar una evaluacin del coste de la misma. Una vez
identificadas las tareas a las que afecta la incidencia se evala su Esta actividad se compone de las siguientes tareas:
impacto en trminos de:
Tarea GPS 6 .1: Estudio de la Peticin de Cambio de Requisitos. El Jefe
o Horas necesarias para resolverla, de Proyecto entrega la peticin de cambio al Equipo del Proyecto para
o Retrasos previstos, su estudio, en el que participa el usuario si es necesario.
o Recursos afectados.
Tarea GPS 6.2 Impacto de la Peticin de Cambio de Requisitos. Una
Tarea GPS 4.2: Propuesta de Solucin de la Incidencia. Dependiendo vez conocidas las nuevas necesidades, el Equipo del Proyecto por
del tipo de incidencia se plantean posibles alternativas de solucin. El medio de sus analistas realizar un anlisis funcional de alto nivel de
Jefe de Proyecto elegir entre las alternativas propuestas la forma de los nuevos requerimientos y el correspondiente diseo tcnico a
solucionar la incidencia, designando en su caso al miembro o miembros grandes rasgos.
del equipo de proyecto encargados de realizar los trabajos. De acuerdo
con la solucin adoptada habr que revisar y ajustar la planificacin del Tarea GPS 6.3 Estudio de Alternativas y Propuesta de Solucin. A
proyecto. partir del Anlisis Funcional y Diseo Tcnico obtenido en la tarea
anterior, el Jefe de Proyecto y el Equipo de Proyecto estudiarn las
Tarea GPS 4.3: Registrar la Incidencia. El objetivo de esta tarea es posibles alternativas de solucin, considerando para cada alternativa los
doble: por una parte se intenta resaltar los sucesos que inciden recursos, esfuerzo, tiempo y coste que supone, presentando la ms
negativamente sobre el desarrollo del proyecto para que se adopten las adecuada al Comit de Seguimiento para su aprobacin.
43 2 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 F O R M T IC O S A N E X O I I : G E S T I N DE P R O Y E C T O S D E LA A D M IN IS T R A C I N P B L IC A E S P A O L A (M E T R IC A ) 433
Esta actividad tiene como objeto que el Comit de Seguimiento considere la Esta actividad tiene una nica tarea:
solucin propuesta en la actividad anterior y decida sobre la procedencia o
improcedencia del cambio de requisitos. I'area GPS 9.1: Registro del Cambio de Requisitos. Al registrar el
cambio de requisitos se deja constancia de la solucin adoptada y de su
Esta actividad tiene una nica tarea: impacto en el desarrollo del proyecto.
Tarea GPS 7.1: Aprobacin de la Solucin. Es necesario que el Comit Actividad GPS 10: Finalizacin de la tarea
de Seguimiento est de acuerdo con los costes que el cambio va a
ocasionar y con la dilatacin que se producir en los plazos de entrega. Debe quedar registro en la ficha de asignacin de la tarea de su finalizacin,
La peticin puede ser rechazada, aprobada, pospuesta o enviada a esfuerzo empleado y aprobacin del responsable.
revisin en cuanto a la solucin adoptada. Esta actividad tiene una nica tarea:
Actividad GPS 8: Estimacin del esfuerzo y planificacin de la solucin Tarea GPS 10.1: Comprobacin de la Tarea. El miembro del equipo del
proyecto al que se le ha asignado al desarrollo de una tarea es quien est
Una vez aprobada la peticin de cambio de requisitos y previo a iniciar el en disposicin de darla por concluida, reflejando en la ficha de
desarrollo de la solucin, es preciso estimar con mayor detalle el esfuerzo que asignacin de tarea la fecha de finalizacin y el esfuerzo real empleado.
el cambio supone y planificar las actividades necesarias para la realizacin del El Jefe de Proyecto o el responsable deber comprobar que la tai'ea ha
cambio de requisitos. finalizado correctamente, firmando la ficha de asignacin de tareas con
los datos relativos a su finalizacin.
Esta actividad se compone de las siguientes tareas:
Actividad GPS 11: Actualizacin de la planificacin
Tarea GPS 8.1: Estimacin de Esfuerzo para el Cambio. A partir de la
solucin aprobada para la peticin de cambio, es necesario hacer una A medida que se van finalizando las tareas y una vez que son comprobadas
estimacin del esfuerzo requerido para llevarla a cabo. Para ello habr habr que actualizar la planificacin, ya que puede que se hayan producido
que realizar las mismas operaciones que en la actividad GPI 1, pero desviaciones. Adems se preparar una previsin de lo que puede ocurrir en el
teniendo en cuenta si la parte del sistema que hay que modificar est futuro al considerar la nueva situacin, y se elaborar un informe de
totalmente desarrollada, parcialmente desarrollada o sin desarrollar, seguimiento.
para descontar o no el esfuerzo correspondiente en la estimacin
original. Esta actividad se compone de las siguientes tareas:
Tarea GPS 8.2: Planificacin de los Cambios. Una vez hecha la Tarea GPS 11.1: Actualizacin de Tareas. Con los datos obtenidos en el
estimacin del esfuerzo es necesario planificar las actividades Seguimiento de Tareas (GPS 3.1), Gestin de Incidencias (GPS 4.2) y
necesarias para la realizacin del cambio, de la misma forma que en la Cambios de Requisitos (GPS 8.2), el Jefe de Proyecto debe actualizar la
actividad GPI 2.4 o la GPS 11.1, utilizando la tcnica de planificacin Planificacin detallada del Proyecto para adecuar el estado de cada
ms apropiada. tarea a la situacin real.
A ctividad G PS 9: R egistro del cam bio de requisitos Tarea GPS 11.2: Obtencin de la Extrapolacin, el Jefe de Proyecto y el
Comit de Seguimiento deben conocer con exactitud cual ser la
evolucin flitura del proyecto si contina desarrollndose tal y como
43 4 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 F O R M T IC O S A N E X O II: G E S T I N D E P R O Y E C T O S D E LA A D M IN IS T R A C I N P U B L IC A E S P A O L A (M E T R IC A ) 435
Actividad GPS 12: Reuniones de seguimiento Actividad GPF 1: Cierre del Proyecto
Las reuniones de seguimiento tienen lugar entre el Jefe y el Equipo del Esta actividad consiste en resumir los datos del proyecto, en cuanto a
Proyecto (internas) o entre el Jefe de Proyecto y el Comit de Seguimiento funcionalidad, tecnologa, equipo tcnico, formacin recibida, experiencias,
(externas). Su finalidad es presentar la informacin sobre la marcha del logros, problemas encontrados y, en general, cualquier dato que el Jefe de
proyecto y estudiar las posibles desviaciones e incidencias, tomando decisiones Proyecto considere de inters.
o adquiriendo compromisos para determinar y realizar las acciones apropiadas
que resuelvan dichas desviaciones o incidencias. Esta actividad se compone de las siguientes tareas:
Esta actividad tiene una nica tarea: Tarea GPF 1.1: Inclusin en Histrico de Proyectos. El Histrico de
Proyectos es esencialmente una base de datos, en soporte magntico o
Tarea GPS 12.1: Reunin Interna de Seguimiento. Cuando el Jefe de en papel, donde se recoge toda la informacin importante de todos los
Proyecto tiene toda la informacin sobre la marcha del proyecto y el sistemas que se desarrollan en una organizacin, lo que en Ingeniera
seguimiento de tareas (GPS 3.1), debe reunirse con todo el equipo del del Software se denomina mtricas de gestin de proyectos. A modo de
proyecto para terminar de analizar las desviaciones. ejemplo se propone incluir en el Histrico de Proyectos informacin
sobre:
Actividad GPS 13: Aceptacin
o Plataforma tecnolgica (sistema operativo, base de datos,
La aceptacin interna consiste en la verificacin por el Equipo del Proyecto del monitor de teleproceso, sistema de comunicaciones, lenguajes,
cumplimiento de las especificaciones de un conjunto de tareas. Este es un paso etc.).
previo a la aceptacin por parte del Cliente. o Entorno metodolgico (metodologa de anlisis, de diseo, de
programacin, herramientas CASE, generadores, ele.),
Esta actividad tiene una nica tarea: o Rutinas y mdulos generales empleados (accesos a ficheros,
conversiones, clculos, etc.),
Tarea GPS 13.1: Verificacin de Aceptacin Interna. El Jefe de o Aspectos funcionales del sistema,
Proyecto debe verificar personalmente que los resultados de las o Incidencias dignas de mencin.
actividades son los esperados. En este caso deber expresar su o Organizacin del proyecto (indicando los tcnicos que
aceptacin en el acta correspondiente. participaron y sus funciones).