Software libre

Ingenieradel software en

UF o r m a c i n d e P o s g r a d o

Marc Gibert Ginest

entornos de SL

lvaro Pea Gonzlez

XP04/90795/01133

Primera edicin: marzo 2005 Fundaci per a la Universitat Oberta de CatalunyaAv. Tibidabo, 39-43, 08035 BarcelonaMaterial realizado por Eureca Media, SL Autor: Jordi Mas, David Megas Jimnez, Marc Gibert Ginest, lvaro Pea GonzlezDepsito legal: B-1.560-2005ISBN:

Se garantiza permiso para copiar, distribuir y modificar este documento segn los trminos de la GNU Free Documentation License,Version 1.2 o cualquiera posterior publicada por la Free Software Foundation , sin secciones invariantes ni textos de cubierta delantera o trasera. Se dispone de una copia de la licencia en el apndice A, junto con una tradicin no oficial en el Apndice B.Puede encontrarse una versin de la ltima versin de este documento en http://curso-sobre.berlios.de/introsobre.

Jordi Mas Hernndez David Megas Jimnez David Aycart Prez

Coordinador Coordinador Autor

Ingeniero de software en la empresa de cdigo abierto Ximian, donde

trabaja en la implementacin del proyecto libre Mono. Como voluntario, colabora en el desarrollo del

procesador de textos Abiword y en la ingeniera de las versiones en cataln del proyecto Mozilla y Gnome.

Coordinador general de Softcatal. Como consultor ha trabajado para empresas como Menta, Telpolis,

Vodafone, Lotus, eresMas, Amena y Terra Espaa.

Ingeniero de Informtica por la UAB. Magster en Tcnicas Avanzadas de

Automatizacin de Procesos por la UAB. Doctor en Informtica por la UAB.

Profesor de los Estudios de Informtica

y Multimedia de la UOC.

Director de desarrollo formativo de Free Software Certification.

Socio fundador de Free Software

Certification.

Socio fundador de Esware Linux S.A.

Marc Gibert Ginest Martn Hernndez Matas lvaro Pea Gonzlez

Autor Autor Autor

Ingeniero en Informtica por la

Universidad Ramon Llull. Socio fundador y jefe de proyectos de Cometa Technologies, empresa

dedicada a dar soluciones en tecnologas de la informacin, basadas en el uso de estndares y

herramientas de cdigo abierto. Profesor del Mster de Seguridad en Tecnologas de la Informacin en

Ingeniera y Arquitectura La Salle y consultor del Mster Internacional de Software Libre de la UOC (Universitat

Oberta de Catalunya).

Ingeniero tcnico informtico de la

Universidad Politcnica de Madrid.

Training manager de Free Software Certification.

Tcnico superior en desarrollo

de aplicaciones informticas.

Desarrollador de aplicaciones comerciales en Verial Software, director de proyectos en la

consultora CFI.

Actualmente es jefe de desarrollo de Esware y colabora en el Proyecto GNOME.

3Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

ndice

Agradecimientos .............................................................. 9

1. Introduccin a la ingeniera del software.................. 111.1. Introduccin ......................................................... 111.2. Objetivos............................................................... 121.3. Un poco de historia ............................................... 121.4. Conceptos ............................................................. 141.5. Gestin de proyectos.............................................. 14

1.5.1.Ciclo de vida del software ............................. 171.5.2.Anlisis de requisitos .................................... 201.5.3. Estimacin de costes..................................... 211.5.4.Diseo ......................................................... 221.5.5.Documentacin ............................................ 231.5.6. Pruebas y calidad ......................................... 241.5.7. Seguridad .................................................... 25

1.6. Ejemplos de metodologas...................................... 281.6.1.Metodologa prxima al software libre:

eXtreme Programming .................................. 281.6.2.Metodologa clsica: Mtrica v3 .................... 37

1.7. Resumen ............................................................... 581.8. Otras fuentes de referencia e informacin ............... 59

2. Diseo de software a objeto con UML....................... 612.1. Introduccin .......................................................... 612.2. Objetivos............................................................... 622.3. Revisin de conceptos del diseo orientado

a objeto y UML...................................................... 622.3.1. Introduccin a la orientacin a objetos .......... 632.3.2.Historia........................................................ 662.3.3.Clases y objetos ........................................... 672.3.4. Encapsulacin.............................................. 682.3.5. Reusando la implementacin. Composicin... 702.3.6. Reusando la interfaz. Herencia...................... 702.3.7. Polimorfismo................................................ 732.3.8. Superclases abstractas e interfaces ................ 752.3.9. La orientacin a objetos y la notacin UML.... 762.3.10. Introduccin a UML.................................... 782.3.11. Conclusiones ............................................. 80

Software libre

4

AN

OTA

CIO

NES

FUOC XXX

2.4. Definicin del caso prctico .................................... 802.5. Diagramas de casos de uso .................................... 842.6. Diagramas de secuencia......................................... 892.7. Diagramas de componentes ................................... 952.8. Diagrama de actividades ........................................ 982.9. Diagrama de clases................................................ 1012.10.Diagrama de despliegue ....................................... 1072.11.Diagrama de estados............................................ 1092.12.Diagrama de colaboracin.................................... 1132.13.Generacin de cdigo........................................... 115

2.13.1. Dia con Dia2Code .................................... 1162.13.2. Umbrello .................................................. 1212.13.3. ArgoUML.................................................. 127

2.14.Resumen .............................................................. 1312.15.Otras fuentes de referencia e informacin.............. 132

3. Control de calidad y pruebas..................................... 1353.1. Introduccin ........................................................... 1353.2. Objetivos ............................................................... 1353.3. Control de calidad y pruebas .................................. 136

3.3.1. Trminos comunes........................................ 1373.3.2. Principios de la comprobacin de software..... 138

3.4. Tcnicas manuales de comprobacin de software .... 1393.5. Tcnicas automticas de comprobacin

de software ............................................................ 1403.5.1. White-box testing .......................................... 1403.5.2. Black-box testing........................................... 1413.5.3. Unidades de comprobacin .......................... 141

3.6. Sistemas de control de errores ................................ 1433.6.1. Reportado en errores .................................... 1433.6.2. Anatoma de un informe de error .................. 1453.6.3. Ciclo de vida de un error .............................. 1463.6.4. Bugzilla........................................................ 1483.6.5. Gnats........................................................... 150

3.7. Conclusiones ......................................................... 1513.8. Otras fuentes de referencia e informacin ............... 152

4. Construccin de software en entorno GNU .............. 1534.1. Introduccin .......................................................... 1534.2. Objetivos .............................................................. 1534.3. Instalando todo lo necesario. Autotools .................. 153

4.3.1. Fichero de configuracin de usuario (input) ... 1544.3.2. Ficheros generados (output) ......................... 1564.3.3. Como mantener ficheros de entrada ............ 159

5Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

4.3.4. Empaquetar ficheros output ......................... 1594.3.5.Changelogs y documentacin ...................... 1604.3.6.Creacin de configure.in ............................. 1624.3.7. Que sigifica portabilidad? .......................... 1624.3.8. Introduccin al sh portable .......................... 1634.3.9.Chequeos necesarios ................................... 163

4.4. Introduccin a GNU Automake .............................. 1654.4.1. Principios generales de automake ................ 1654.4.2. Introduccin a las primarias ......................... 1664.4.3. Programas y librerias ................................... 1674.4.4.Mltiples directorios ..................................... 1684.4.5.Cmo probarlo ........................................... 168

4.5. La libreria GNU Libtool ......................................... 1694.5.1.Cdigo independiente ................................. 1704.5.2. Librerias compartidas .................................. 1714.5.3. Librerias estticas ........................................ 1724.5.4. Enlazar una librera. Dependencias

entre librerias .............................................. 1724.5.5.Usar libreras de conveniencia ..................... 1734.5.6. Instalacin de librerias y ejecutables ............. 1734.5.7.Desinstalacin ............................................. 1744.5.8.GNU Libtool, configure.in y Makefile.am ...... 1744.5.9. Integracin con configure.in, opciones extra

y macros para Libtool .................................. 1744.5.10. Integracin con Makefile.am, creacin

de librerias con Automake y linkadocontra librerias Libtool ............................... 175

4.5.11. Utilizacin de libtoolize .............................. 1764.5.12. Versionado de libreras .............................. 177

4.6. Conclusiones ........................................................ 178

5. Control de versiones ................................................. 1815.1. Introduccin ......................................................... 1815.2. Objetivos .............................................................. 1825.3. Sistemas de control de versiones ............................ 182

5.3.1.Algunos trminos comunes .......................... 1835.3.2.Caractersticas de los sistemas de control

de versiones ................................................ 1845.3.3. Principales sistemas de control de versiones .. 1855.3.4. Sistemas de comparticin ............................ 186

5.4. Primeros pasos con CVS ........................................ 1875.4.1. Instalacin de CVS ...................................... 1875.4.2.Obtener un directorio de trabajo

de un proyecto ya existente .......................... 1885.4.3. Sincronizndose con el repositorio ............... 190

Software libre

6

AN

OTA

CIO

NES

FUOC XP04/90795/01133

5.4.4. Cambios al repositorio ................................. 1925.4.5. Publicando cambios con diff y patch ............. 193

5.5. Creacin y administracin de repositorios .............. 1945.5.1. Tipos de conexin al repositorio ................... 1965.5.2. Importando proyectos ya existentes ............... 1975.5.3. Aadiendo archivos o directorios .................. 1985.5.4. Los archivos binarios .................................... 1995.5.5. Eliminando archivos y directorios .................. 2005.5.6. Moviendo archivos ....................................... 200

5.6. Trabajando con versiones, etiquetas y ramas .......... 2005.6.1. Etiquetas y revisiones ................................... 2015.6.2. Creacin de ramas ...................................... 202

5.7. Bonsai: gestin de CVS va web ............................. 2045.7.1. Subversion .................................................. 2045.7.2. Instalacin de Subversion ............................. 2045.7.3. Obtener un directorio de trabajo

de un proyecto ya existente .......................... 2065.7.4. Creacin de repositorios .............................. 2065.7.5. Comandos bsicos con Subversion ............... 208

5.8. Conclusin ............................................................ 2105.9. Otras fuentes de referencia e informacin .............. 211

6. Gestin de software ................................................... 2136.1. Introduccin ........................................................... 2136.2. Objetivos ............................................................... 2136.3. El empaquetador universal: tar ............................... 214

6.3.1. Comprimiendo: gzip..................................... 2166.3.2. Usando tar, gzip, y unos disquetes................. 219

6.4. RPM....................................................................... 2206.4.1. Trabajar con RPM......................................... 2216.4.2. Instalacin.................................................... 2226.4.3. Actualizacin................................................ 2256.4.4. Consulta ...................................................... 2266.4.5. Desinstalacin.............................................. 2286.4.6. Verificacin .................................................. 2286.4.7. Creacin de paquetes y gestin de parches.... 2296.4.8. Para finalizar con RPM.................................. 231

6.5. DEB ....................................................................... 2336.5.1. APT, DPKG, DSELECT, APTITUDE,

CONSOLE APT, etc....................................... 2346.5.2. APT, comandos bsicos................................. 2346.5.3. DPKG .......................................................... 2406.5.4. Creacin de paquetes deb y gestin

de parches ................................................... 243

7Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

6.5.5.Alien (convertir paquetes DEB, RPM y TGZ) .... 2466.5.6.Comandos bsicos Alien .............................. 246

6.6. Conclusiones......................................................... 247

7. Sistemas de creacin de documentacin ................... 2497.1. Introduccin .......................................................... 2497.2. Objetivos............................................................... 2497.3. Documentacin libre: estndares y automatizacin.. 250

7.3.1. La documentacin del software ..................... 2507.3.2. El problema de documentar software libre ..... 2517.3.3. Licencias libres para la documentacin.......... 2527.3.4. Formatos libres y propietarios ....................... 2527.3.5.Herramientas de control y administracin

de versiones................................................. 2537.4. Creacin de pginas de manual............................. 254

7.4.1. Secciones de las pginas de manual ............. 2547.4.2.Camino de bsqueda de pginas man.......... 2557.4.3. Jerarqua de captulos de las pginas man .... 2567.4.4.Generacin de pginas man usando

herramientas estndares............................... 2577.4.5.Generacin de pginas de manual

usando perlpod......................................... 2587.5. TeX y LaTeX ........................................................... 259

7.5.1. Instalacin ................................................... 2607.5.2.Utilizacin.................................................... 2607.5.3. Fichero fuente LaTeX .................................... 2617.5.4.Clases de documentos.................................. 2617.5.5. Extensiones o paquetes................................. 2627.5.6. Edicin WYSWYG con LaTeX ......................... 262

7.6. SGML.................................................................... 2627.6.1.Documentacin en formato html ................... 2637.6.2.Documentacin en formato Docbook ............ 265

7.7. Doxygen. Documentacin de cdigo fuente............. 2677.7.1.Utilizacin.................................................... 2677.7.2.Documentacin en los cdigos fuentes .......... 268

7.8. Conclusiones......................................................... 2707.9. Otras fuentes de referencia e informacin ............... 270

8. Comunidades virtuales y recursos existentes ........... 2718.1. Introduccin ......................................................... 2718.2. Objetivos .............................................................. 271

8.2.1.www.tldp.org .............................................. 2728.3. Recursos documentales para el ingeniero

en software libre ................................................... 2728.3.1.http://www.freestandards.org ...................... 273

Software libre

8

AN

OTA

CIO

NES

FUOC XP04/90795/01133

8.3.2. http://www.unix.org ..................................... 2748.3.3. http://www.opensource.org .......................... 2758.3.4. http://standards.ieee.org/reading/ieee/

std_public/description/posix/ ........................ 2768.3.5. http://www.faqs.org ..................................... 2778.3.6. http://www.dwheeler.com/oss_fs_refs.html .... 2788.3.7. http://www.mail-archive.com ....................... 279

8.4. Comunidad .......................................................... 2798.4.1. http://mail.gnu.org/archive/html/ ................ 2808.4.2. http://www.advogato.org/ ........................... 2818.4.3. Sourceforge.net ........................................... 282

8.5. Albergar proyectos de software libre ....................... 2828.5.1. Creacin de una cuenta de usuario .............. 2838.5.2. Alta de nuevo proyecto ................................ 2848.5.3. Utilidades que Sourceforge pone a disposicin

de los usuarios de un proyecto ..................... 2868.5.4. Software-libre.org ........................................ 2908.5.5. Publicitar proyectos de software libre y obtener

notoriedad .................................................. 2918.5.6. Freshmeat.net .............................................. 292

8.6. Cmo obtener notoriedad para nuestrosproyectos? ............................................................ 297

8.7. Conclusiones ........................................................ 299

Appendix A. GNU Free Documentation License ............ 301A.1. PREAMBLE .......................................................... 301A.2. APPLICABILITY AND DEFINITIONS ....................... 302A.3. VERBATIM COPYING ........................................... 304A.4. COPYING IN QUANTITY ..................................... 304A.5. MODIFICATIONS ................................................ 305A.6. COMBINING DOCUMENTS ................................ 308A.7. COLLECTIONS OFCUMENTS .............................. 308A.8. AGGREGATION WITH INDEPENDENT WORKS .... 309A.9. TRANSLATION .................................................... 309A.10. TERMINATION .................................................... 310A.11. FUTURE REVISIONS OF THIS LICENSE ................. 310A.12. ADDENDUM: How to use this License

for your documents ............................................. 311

9Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Los autores agradecen a la Fundacin para la Universitat Oberta de

Catalunya (http://www.uoc.edu) la financiacin de la primera edi-

cin de esta obra, enmarcada en el Mster Internacional en Software

Libre ofrecido por la citada institucin.

Agradecimientos

11

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Este primer captulo del curso Ingeniera del software en entornos de

software libre, proporciona las bases para conocer los conceptos

principales involucrados en la ingeniera del software en general, y

su aplicacin al software libre en particular.

A lo largo del captulo, veremos que la ingeniera del software es

casi tan antigua como el propio software, y tambin que, parte de

los problemas que hicieron nacer este sector de la industria del soft-

ware siguen vigentes, la mayora sin una solucin clara y definida.

Pese a ello, se han hecho grandes avances en todos los campos,

desde la estimacin del coste, pasando por la gestin de los equi-

pos de trabajo, documentacin, y muy notablemente en pruebas,

calidad y seguridad.

Despus de introducir brevemente los conceptos ms importantes,

pasamos directamente a examinar dos metodologas concretas

bastante populares. En primer lugar, veremos la metodologa eXtreme

Programming, quiz la ms prxima a la forma de organizar y

participar en proyectos de software libre. A continuacin, daremos

un vistazo a Mtrica v3, una metodologa clsica que es impres-

cindible conocer si se han de realizar proyectos con la Administra-

cin espaola.

Existen cientos de metodologas (pblicas y particulares de empre-

sas), pero los conceptos introducidos a lo largo de este mdulo nos

proporcionarn los conocimientos necesarios para evaluar su ido-

neidad en nuestro mbito de trabajo o proyecto concreto, y para pro-

fundizar en los aspectos de la ingeniera del software que ms nos

hayan llamado la atencin.

1. Introduccin a la ingeniera del software

1.1. Introduccin

Software libre

12

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Tomar conciencia de la importancia de los procesos y actividades re-

lacionados con la ingeniera del software en proyectos de todo tipo.

Conocer los conceptos bsicos involucrados, que nos permitirn

documentarnos ms ampliamente cuando nos sea necesario, y

evaluar metodologas concretas.

Familiarizarse con la metodologa eXtreme Programming, y con los

nuevos paradigmas de gestin, diseo y desarrollo que plantea.

Conocer la estructura general de la metodologa Mtrica v3, y sus

principales procesos, actividades e interfaces.

El trmino ingeniera del software empez a usarse a finales de la d-

cada de los sesenta, para expresar el rea de conocimiento que se

estaba desarrollando en torno a las problemticas que ofreca el

software en ese momento.

En esa poca, el crecimiento espectacular de la demanda de siste-

mas de computacin cada vez ms y ms complejos, asociado a

la inmadurez del propio sector informtico (totalmente ligado al

electrnico) y a la falta de mtodos y recursos, provoc lo que se

llam la crisis del software (en palabras de Edsger Dijkstra) entre

los aos 1965 y 1985.

Durante esa poca muchos proyectos importantes superaban con

creces los presupuestos y fechas estimados, algunos de ellos eran tan

crticos (sistemas de control de aeropuertos, equipos para medicina,

etc.) que sus implicaciones iban ms all de las prdidas millonarias

que causaban.

La crisis del software pas, no tanto por la mejora en la gestin de

los proyectos, sino en parte porque no es razonable estar en crisis

1.2. Objetivos

1.3. Un poco de historia

Alguno de los proyectosms representativos de lapoca, como el desarrollodel sistema OS/360 de IBM,tard ms de una dcadaen finalizarse, y fue el pri-mero que involucr a msde 1.000 programadores.Ms adelante, el jefe delproyecto en Mythical ManMonth, Fred Books, reco-nocera que se haban co-metido errores de millonesde dlares, y pronunciarala conocida ley de Brooks:

Asignar ms programado-res a un proyecto ya retrasa-do, suele retrasar an msel proyecto.

Nota

13

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

ms de veinte aos, y en parte porque se estaban haciendo progre-

sos en los procesos de diseo y metodologas.

As pues, desde 1985 hasta el presente, han ido apareciendo herra-

mientas, metodologas y tecnologas que se presentaban como la so-

lucin definitiva al problema de la planificacin, previsin de costes

y aseguramiento de la calidad en el desarrollo de software.

Entre las herramientas, la programacin estructurada, la programa-

cin orientada a objetos, a los aspectos, las herramientas CASE, el

lenguaje de programacin ADA, la documentacin, los estndares,

CORBA, los servicios web y el lenguaje UML (entre otros) fueron to-

dos anunciados en su momento como la solucin a los problemas de

la ingeniera del software, la llamada bala de plata (por silver bullet).

Y lo que es ms, cada ao surgen nuevas ideas e iniciativas encami-

nadas a ello.

Por supuesto, tambin ha habido quien ha culpado a los programa-

dores por su indisciplina o anarqua en sus desarrollos. La ignorancia

y algunos casos excntricos contribuyeron a crear una imagen falsa

del programador, que hoy en da an perdura. Aunque muchas veces

l es el sufridor de alguna de estas metodologas o de una pobre

implementacin de las mismas, parece lgico que, como participante

activo en el proyecto, las metodologas ms modernas empiecen a te-

nerle ms en cuenta.

En combinacin con las herramientas, tambin se han hecho esfuer-

zos por incorporar los mtodos formales al desarrollo de software,

argumentando que si se probaba formalmente que los desarrollos

hacan lo que se les requera, la industria del software sera tan pre-

decible como lo son otras ramas de la ingeniera.

Entre las metodologas y procesos, adems de Mtrica v3 (promovi-

da por la Secretara del Consejo Superior de Informtica) y eXtreme

Programming, que veremos en detalle ms adelante, destacan mu-

chos otros como RUP (rational unified process desarrollado por Rational

Software Corp. ahora una divisin de IBM), SSADM (structured systems

analysis and design methodology promovido por el Gobierno brit-

nico) o el mtodo de evaluacin de la capacidad de desarrollo de los

equipos o empresas conocido como CMMI (capability maturity model

Software libre

14

AN

OTA

CIO

NES

FUOC XP04/90795/01133

integration). Paralelamente, suelen usarse tambin mtodos de pre-

diccin de costes como COCOMO o los puntos de funcin.

Las ltimas iniciativas en este campo son mltiples y se extienden a

lo largo de todo el proceso relacionado con el software. Los ms aca-

dmicos se inclinan por una estructura de componentes, servicios,

con orientacin a objetos o a aspectos en la implementacin; aun-

que tambin es igual de significativo el desarrollo de las herramien-

tas que nos ayuden a representar y compartir estos diseos, as como

a valorar el esfuerzo y el valor que aaden al producto final. Es real-

mente un campo fascinante, donde tanto en los seminarios o en las

grandes consultoras, como en los pequeos laboratorios se innova

cada da y se presentan buenas ideas.

En este captulo, veremos los conceptos ms comunes asociados con

la ingeniera del software, aplicables tanto a entornos de software li-

bre, como al resto. Todos ellos disponen de abundante bibliografa,

y de algunos cursos y msters especializados en su aprendizaje y

aplicacin a los procesos de desarrollo. Aqu nicamente los defini-

remos para tener una base sobre la que tratar los ejemplos de me-

todologa que veremos en los captulos siguientes.

1.4.1. Gestin de proyectos

La gestin de proyectos es la disciplina que agrupa y ordena el con-

junto de tareas o actividades destinadas a obtener unos objetivos.

Esto incluye la planificacin, definicin, ordenamiento y gestin de

las actividades que formarn el proyecto software.

En su primera expresin, la buena gestin de un proyecto es la que

es capaz de reducir al mnimo las posibilidades de fallo de ste du-

rante todo el transcurso del mismo. Pudiendo entenderse como fallo,

la no consecucin de los requisitos iniciales del proyecto, la inviabi-

lidad econmica del mismo, un resultado que impida mantenerlo o

le impida evolucionar, etc.

1.4. Conceptos

15

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Otra visin ms orientada al mbito de costes y econmico del proyecto

es la que define la buena gestin como la que optimiza el uso de los re-

cursos (tiempo, dinero, personas, equipos, etc.) en cada fase del mismo.

Muy comnmente, la gestin del proyecto se lleva a cabo por el di-

rector del proyecto, normalmente una sola persona que no tiene por

qu participar activamente en las actividades del mismo, pero que

s que se ocupa de monitorizar su progreso y de la interaccin entre

los diferentes grupos que intervienen en ste para minimizar el ries-

go de fallo del proyecto.

Adems de hojas de clculo de control de horas por tarea, uso de

recursos, etc., los diagramas de Gantt son muy usados en estos en-

tornos por mostrar de una forma clara la sucesin de tareas, recur-

sos involucrados y sus dependencias.

En los diagramas de Gantt , representamos las actividades que hay que

realizar en forma de rbol (mitad izquierda de la figura), indicando su

fecha de inicio y su duracin estimada. El programa representa la acti-

vidad sobre un calendario (mitad derecha de la figura) y nos permite de-

finir las dependencias entre las actividades. Al indicar que una tarea

debe empezarse al terminar otra, o que deben empezar a la vez o ter-

minar las dos simultneamente, el diagrama va modificando automti-

camente la situacin de las actividades en el tiempo.

Figura 1. Captura de pantalla del software GPL Imendio Planner mostrando un diagrama de Gantt

Software libre

16

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Dependiendo de la complejidad del programa que utilicemos para

representar el diagrama, podremos especificar tambin los recursos

disponibles, los necesarios para cada tarea, etc. y seremos capaces de

detectar conflictos en la planificacin, como intervalos en los que no

dispondremos de los recursos necesarios, o cul va a ser el camino cr-

tico del proyecto (la sucesin de tareas que por sus dependencias van

a determinar la duracin mxima del proyecto).

Concretamente, en entornos de software libre, no existe una forma

tradicional de gestionar un proyecto. Un buen ejemplo de ello es

el artculo de Eric S. Raymond, La Catedral y el Bazar, en el que se

describe la forma tradicional de gestionar un proyecto como analo-

ga de construir una catedral, y se compara la forma como se ges-

tionan muchos proyectos de software libre al funcionamiento de un

bazar.

Proyectos grandes de software libre, como el desarrollo del ncleo Li-

nux o el servidor web Apache, estn formados por un comit de ges-

tin del proyecto (o una sola persona como dictador benevolente)

que deciden los siguientes pasos que habr que llevar a cabo en el

proyecto, y que inmediatamente delegan en otras personas o equi-

pos los cambios que hay que realizar para llegar a los objetivos. La

aprobacin de los cambios realizados o bien la incorporacin de

nuevas funcionalidades propuestas por los usuarios u otros desarro-

lladores sigue el proceso inverso hasta llegar al comit de aproba-

cin que decide si se incorporan al proyecto o no.

Por supuesto, en este tipo de gestin de proyectos, juega un papel

fundamental las herramientas de soporte y comunicacin entre los

diferentes equipos. Programas de gestin de incidencias como el co-

nocido Bugzilla o entornos como Sourceforge que ayudan a los ges-

tores del proyecto o a los comits organizadores a conocer el estado

del proyecto, la opinin de sus usuarios, las aportaciones de los de-

sarrolladores, etc.

Proyectos pequeos o medianos de software libre no acostumbran a

seguir una metodologa tradicional, y se orientan ms a una gestin

gil del proyecto, siguiendo principios acordes con el software libre,

primando la publicacin de nuevas funcionalidades y versiones del

proyecto al cumplimiento de un calendario rgido de actividades e hitos.

El camino crtico de un pro-yecto se define como la se-cuencia de tareas quesuman el intervalo de tiem-po ms largo del mismo.As pues, determina la dura-cin mnima del proyecto,ya que un retraso en algunade sus tareas tiene un im-pacto directo en su duracintotal.

Nota

http://www.bugzilla.org/

http://sourceforge.net/

Web

17

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

En estos proyectos, el director del mismo suele intervenir muy estre-

chamente en el desarrollo y en el resto de actividades.

Este ltimo tipo de proyectos suelen gestionarse mediante simples lis-

tas de requisitos y fallos por resolver, que por la naturaleza distribui-

da de los proyectos de software libre, deber estar disponible para

su consulta y modificacin por parte de los desarrolladores y usua-

rios. El gestor o los desarrolladores sern los que den prioridad a las

tareas, y decidan cules van a incorporar en las nuevas releases del

proyecto.

1.4.2. Ciclo de vida del software

Se llama ciclo de vida del software a las fases por las que pasa un pro-

yecto software desde que es concebido, hasta que est listo para usarse.

Tpicamente, incluye las siguientes actividades: toma de requisitos, an-

lisis, diseo, desarrollo, pruebas (validacin, aseguramiento de la cali-

dad), instalacin (implantacin), uso, mantenimiento y obsolescencia.

El proyecto tiende a pasar iterativamente por estas fases, en lugar de

hacerlo de forma lineal. As pues, se han propuesto varios modelos

(en cascada, incremental, evolutivo, en espiral, o concurrente, por ci-

tar algunos) para describir el progreso real del proyecto.

Figura 2. Tpico ciclo de vida de un proyecto software

Software libre

18

AN

OTA

CIO

NES

FUOC XP04/90795/01133

El modelo en cascada es el ms simple de todos ellos y sirve de base

para el resto. Simplemente asigna unas actividades a cada fase, que

servirn para completarla y para proporcionar los requisitos de la si-

guiente. As, el proyecto no se disea hasta que ha sido analizado, o

se desarrolla hasta que ha sido diseado, o se prueba hasta que ha

sido desarrollado, etc.

Los modelos incremental y evolutivo son una variacin del modelo en

cascada en la que ste se aplica a subconjuntos del proyecto. Depen-

diendo de si los subconjuntos son partes del total (modelo incremental)

o bien versiones completas pero con menos prestaciones (modelo evo-

lutivo) estaremos aplicando uno u otro.

El modelo en espiral se basa en la creacin de prototipos del proyec-

to, que pasan por las fases anteriores, y que van acercndose suce-

sivamente a los objetivos finales. As pues, nos permite examinar y

validar repetidamente los requisitos y diseos del proyecto antes de

acometer nuevas fases de desarrollo.

Figura 3. Modelo en cascada

19

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Finalmente, el modelo iterativo o incremental es el que permite que

las fases de anlisis, diseo, desarrollo y pruebas se retroalimenten

continuamente, y que empiecen lo antes posible. Permitir atender a

posibles cambios en las necesidades del usuario o a nuevas herra-

mientas o componentes que los desarrolladores descubran y que fa-

ciliten el diseo o proporcionen nuevas funcionalidades.

Figura 4. Modelo en espiral

Figura 5. Modelo iterativo

Software libre

20

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Se trata de obtener lo ms rpidamente una versin funcional del

software, y aadirle prestaciones a partir de lo que se ha aprendido

en la versin anterior. El aprendizaje proviene tanto del desarrollo

anterior, como del uso del software, si es posible. En este tipo de de-

sarrollo es imprescindible establecer una lista de control del proyec-

to, donde iremos registrando las funcionalidades que faltan por

implementar, las reacciones de los usuarios, etc. y que nos propor-

cionar las bases para cada nueva iteracin.

Este ltimo mtodo es el ms usado (aunque sea involuntaria-

mente) en proyectos de software libre, por la propia naturaleza

cambiante de los requisitos o la aportacin constante de nuevos

colaboradores.

1.4.3. Anlisis de requisitos

El anlisis de requisitos es la primera fase de la vida de un proyecto.

En ella, habr que recoger tanto las necesidades del usuario del

producto, al ms alto nivel, como la especificacin de los requisitos

software del sistema.

Para guiarnos en ese proceso, existen multitud de plantillas, libros y

metodologas orientados a extraer del usuario (o cliente) lo que real-

mente quiere que haga el sistema. Sin duda, no es una tarea sencilla.

El proyecto ReadySET hospedado en http://www.tigris.org proporciona

un conjunto de plantillas de documentos para la gestin de un proyec-

to de desarrollo software, extremadamente til y de cdigo abierto.

Siguiendo estas plantillas, vemos que la especificacin de requisitos

del sistema incluye, como mnimo:

Los casos de uso: actores que intervendrn en el uso del producto

y sus posibles acciones.

Sus requisitos funcionales: prestaciones del producto en la prime-

ra versin y posible planificacin para las futuras versiones.

Sus requisitos no funcionales: de rendimiento, de usabilidad, de

seguridad, etc.

21

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

En entornos de software libre, muy frecuentemente el fundador (y

gestor) del proyecto ser tambin su primer usuario, pero esto no le

exime de esta tarea, que determinar el alcance del proyecto al me-

nos en sus primeras versiones, y permitir a los desarrolladores que

se vayan incorporando al proyecto, hacerse una idea de su progreso

y objetivos, as como dnde prestar su ayuda.

1.4.4. Estimacin de costes

La estimacin de costes (recursos, equipos y tiempo empleado) es

una de las razones de ser de la ingeniera del software. Aunque no

siempre aplicable en entornos de software libre, donde no suele ser

posible realizar una planificacin de recursos disponibles, es conve-

niente conocer las mtricas y mtodos que nos permitirn predecir el

esfuerzo que supondr implementar un sistema o alguna de sus

prestaciones.

La estimacin suele realizarse basndose en modelos matemticos

que parten del tamao estimado del proyecto, y de constantes que

lo ajustan segn las tecnologas usadas, recursos de que disponemos,

etc. Los modelos nos permiten estimar el esfuerzo requerido (habitual-

mente en horas/hombre o meses/hombre) para terminar el proyecto.

Obviamente, la clave est en estimar el tamao del proyecto. Aun

sabiendo lo poco indicativo que puede llegar a ser, son bastantes los

modelos que usan las lneas de cdigo para determinar el tamao

de un proyecto (COCOMO, COCOMO II). Otros modelos usan los

denominados puntos de funcin, que son una medida de la com-

plejidad de cada funcionalidad a partir de las entradas que recibe,

las salidas que aporta, su interaccin con otras funcionalidades o re-

cursos, etc.

Existen tambin mtricas para lenguajes orientados a objetos, que

tienen en cuenta factores como los mtodos por clase, las herencias

entre objetos, la interaccin entre ellos, su grado de dependencia

(que complica el mantenimiento, etc.).

No es el objetivo de este captulo ahondar en estos conceptos, que

requeriran muchas pginas de frmulas, tablas, as como casos de

Software libre

22

AN

OTA

CIO

NES

FUOC XP04/90795/01133

xito o fracaso en la estimacin. El estudiante interesado en profun-

dizar encontrar mucha informacin sobre ellos en la bibliografa.

1.4.5. Diseo

La fase de diseo del sistema producir un conjunto de documentos

que describirn un sistema que cumpla con los objetivos de la fase de

anlisis de requisitos. Las decisiones que se tomen en esta fase debe-

rn basarse en esos requisitos y en la comprensin de la tecnologa y

los componentes disponibles.

Debe tenerse en cuenta que muchos de los documentos que se crea-

rn en esta fase van a usarse por los desarrolladores del proyecto

(diagramas de componentes del sistema, arquitectura del mismo,

etc.). Esto implica que deben hacerse lo ms completos posible, y

que la participacin de los desarrolladores en esta fase ayudar a

evitar revisiones innecesarias.

Otros documentos irn destinados a los usuarios del proyecto (p. ej.,

el diseo de la interfaz de usuario), y su aprobacin y entendimiento

de stos tambin ser clave para evitar desviaciones.

Por todo ello, es muy conveniente disponer de listas que nos permi-

tan comprobar que no hemos olvidado ningn aspecto clave en esta

fase. El proyecto ReadySET dispone de plantillas de casi todos los do-

cumentos que podemos necesitar, con los cuestionarios correspon-

dientes y ejemplos.

Extrayendo lo ms significativo, encontramos:

Diagrama estructural: diseo y notas sobre la estructura del siste-

ma en detalle.

Diagrama de comportamiento: diseo y notas sobre el compor-

tamiento del sistema.

Arquitectura del sistema: diseo de sus componentes, de su im-

plantacin e integracin.

23

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Organizacin de cdigo fuente y compilacin: Directorios, opcio-

nes de compilacin, sistemas de control de versiones, etc.

Interfaz de usuario: metforas, estndares a seguir, diseo de los

contextos de interaccin con el usuario, etc.

Sistema de informacin: bases de datos, abstraccin de objetos,

almacenamiento, persistencia, etc.

Seguridad.

1.4.6. Documentacin

La documentacin de un proyecto es de vital importancia para su xi-

to. Ya desde la fase de diseo, como parte de la propia arquitectura

del proyecto, deberemos definir y escoger el sistema de documenta-

cin que usaremos para el proyecto, teniendo en cuenta factores

como los siguientes:

Formatos de los documentos, segn su tipologa y mtodos de ac-

ceso. Deberemos definir los formatos y plantillas elegidos para los

diagramas de diseo, hojas de clculo, hojas de seguimiento del

proyecto, documentos que registren fallos o cambios en las espe-

cificaciones durante el desarrollo, documentos que definan la in-

terfaz de usuario, etc.

Mtodo de acceso y flujo de trabajo de cada tipo de documento.

Quin va a tener acceso a los diferentes tipos de documentos y

bajo qu privilegios. Dnde se van a notificar los cambios que se

realicen (en el propio documento?, en un sistema de control de

versiones?).

En el caso de la documentacin del propio desarrollo (del cdigo

fuente del proyecto), conviene estudiar las herramientas que nos

ofrezca el propio lenguaje para generar la documentacin, ya que

en muchos casos existen herramientas de generacin de documen-

tacin a partir del cdigo fuente y comentarios insertados mediante

una sintaxis determinada que van a ayudar mucho en el proceso. En

el captulo 7 se examinan ejemplos de herramientas de este tipo.

Software libre

24

AN

OTA

CIO

NES

FUOC XP04/90795/01133

En el momento de tomar decisiones de formato y flujos de trabajo

sobre la documentacin, es de vital importancia tener en cuenta los

estndares de formatos de documento existentes, evitando los for-

matos propietarios sobre todo en organizaciones heterogneas don-

de convivan distintos sistemas operativos o en proyectos de software

libre, para dar a la documentacin la mayor accesibilidad posible.

Suele ser una buena decisin escoger un formato de documentacin

fcilmente convertible a otros (p.ej., XML) y as poder disponer de la

documentacin en HTML para su consulta rpida, en PDF para agre-

gar a la documentacin del proyecto, etc.

1.4.7. Pruebas y calidad

La planificacin de prototipos, pruebas y tests para el aseguramiento

de la calidad es tambin un tema muy tratado en la ingeniera del

software.

Para que un proyecto software tenga xito, es necesario que el resul-

tado cuente con la calidad esperada por el cliente o los usuarios. As

pues, la calidad del proyecto deber poderse definir en trminos de

prestaciones, respuestas esperadas a determinadas acciones, o ac-

cesibilidad del producto en diferentes condiciones para poder pro-

barla posteriormente mediante unos tests de calidad especficos.

Deber ser posible realizar un plan de pruebas o de aseguramiento

de la calidad que clasifique las actividades relacionadas con la cali-

dad del producto segn su importancia, y que defina con qu fre-

cuencia y qu resultados se deberan obtener de cada una para

pasar a la siguiente o para cumplir los requisitos para esa release en

particular.

El proceso de aseguramiento de la calidad no trata nicamente de

que el producto pase todos los tests establecidos, sino que implicar

en muchos casos aspectos como:

El uso de hojas de estilo aprobadas por los usuarios.

La confeccin y repaso de checklists sobre funcionalidades.

La revisin peridica del producto con los usuarios.

25

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Las herramientas que pondremos a disposicin de los usuarios

para comunicar los errores o sugerencias.

El uso de herramientas de anlisis para medir la respuesta del

proyecto a determinadas situaciones, o para simular un uso nor-

mal del mismo.

Los modelos tradicionales de ciclo de vida del software incluan la fase

de pruebas como un proceso que haba que llevar a cabo una vez fina-

lizado el desarrollo. Esto se ha probado que resulta altamente contra-

producente, no slo por el coste de arreglar fallos o deficiencias una vez

terminado el desarrollo, sino por la naturaleza evolutiva de muchos pro-

yectos (sobre todo en entornos de software libre), en los que la fase de

desarrollo no termina nunca estrictamente hablando.

As pues, se tiende a incorporar las pruebas (o los mecanismos para

llevarlas a cabo de modo automatizado) en el desarrollo desde el

primer momento. Tecnologas como las pruebas unitarias o modelos

como el pair-programming o el peer-testing nos ayudarn a mante-

ner una disciplina en el desarrollo y a aumentar la calidad del resul-

tado del proyecto.

Los tipos de pruebas, herramientas de gestin de las mismas y los

planes de calidad se tratan en detalle en el captulo 3.

1.4.8. Seguridad

La seguridad en proyectos software ha sido un factor clave desde el

inicio de la ingeniera del software. Igual que en otros conceptos

como la calidad, la seguridad no puede ser un mdulo en el diseo

que tiene lugar fuera de l, ni un proceso que se comprueba al fina-

lizar el desarrollo, sino que se trata de un aspecto del proyecto que

tiene que tenerse en cuenta y planificarse desde la fase de diseo, y

que afectar a lo largo de todo el ciclo de vida del proyecto.

Los principios bsicos de la seguridad de un sistema son los siguientes:

Confidencialidad: los recursos (o funcionalidades sobre ellos) son

accesibles slo para los usuarios (o procesos) autorizados.

Software libre

26

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Integridad: los recursos pueden ser modificables slo por los

usuarios autorizados.

Disponibilidad: los recursos accesibles estn disponibles.

Muy frecuentemente, la seguridad de un proyecto ir ms all del

mismo, afectando al sistema en el que ste se va a implantar, y por

lo tanto deberemos asegurar que su implantacin deja al sistema fi-

nal en un estado seguro.

Es por esta razn por lo que, en la fase de diseo del proyecto, se

debe tener en cuenta la seguridad del mismo, primero de forma ge-

neral mediante un anlisis de riesgos y de actividades destinadas a

mitigarlos, y ms adelante mediante la ampliacin de los casos de

uso segn los principios bsicos de la seguridad comentados ante-

riormente.

El anlisis de riesgos consistir, de forma muy resumida, en las si-

guientes actividades:

Recopilacin de los recursos que deben ser protegidos. La infor-

macin, todo un sistema, un slo dispositivo, etc.

Clasificacin de los actores del proyecto. Cules son sus casos de

uso y qu roles representan.

Recopilacin de requisitos legales y de negocio. Certificaciones que

hay que cumplir, restricciones de encriptacin por exportacin a de-

terminados pases o bien reglas de negocio ms especficas como la

aceptacin o no de la repudiacin por parte de los usuarios.

Con la informacin recopilada, deberamos ser capaces de

construir una tabla en la que, para cada riesgo, estimramos

el coste que tiene por incidente, y a partir de una estimacin de

incidentes por ao, nos permitiera decidir sobre la estrategia

que hay que implantar (aceptar el riesgo tal como es y definir

un plan de contingencia en caso de producirse, o bien mitigarlo

27

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

mediante desarrollos adicionales, otras herramientas o cam-

bios en el diseo que lo permitan).

Sin entrar en detalle, enunciamos a continuacin un conjunto de

buenas prcticas genricas que ayudarn a mitigar los riesgos aso-

ciados a cualquier proyecto:

Asignar el mnimo privilegio posible a cada actor en el sistema.

Simplicidad. La seguridad por ofuscacin no da buenos resultados.

Diseo abierto. Siempre tendremos alternativas para mejorar o

asegurar ms el sistema.

Seguridad por defecto. El sistema debe ser el mximo de seguro

por defecto, si tiene que ser posible relajar las restricciones, debe

tratarse de una accin adicional a realizar con el proyecto ya im-

plantado.

Fallada segura. Si el sistema falla o puede fallar, evitar que lo

haga quedndose en una modalidad insegura.

Minimizar el uso de recursos compartidos.

Trabajar a favor de la usabilidad del proyecto redunda en un me-

jor uso de l y en menores probabilidades de fallos de seguridad

por un mal uso del mismo.

Figura 6

Software libre

28

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Hasta ahora hemos hecho un breve repaso a la historia y los con-

ceptos relacionados con la ingeniera del software en general. A

continuacin, vamos a examinar un poco ms detalladamente dos

metodologas concretas para ver cmo intentan resolver algunos

de los problemas comentados, y poder, as, tomar decisiones en la

gestin de proyectos.

Cabe comentar que no es siempre conveniente escoger y aplicar una

metodologa de forma estricta. Es importante entenderla y conocer

qu nos puede aportar a nuestro proyecto, para aplicarla en esas fa-

ses o procesos en los que nuestro equipo o nuestros usuarios estn

ms cmodos con ella, y no al revs.

En entornos de software libre, no es habitual que los programadores

que colaboran de forma altruista en el proyecto quieran hacerlo bajo

una metodologa demasiado estricta. Sin embargo, valorarn enor-

memente las facilidades de gestin que ofrezca el proyecto, el acceso

a su documentacin, la calidad de la misma, etc., por lo que estarn

mucho ms motivados, y pasarn ms tiempo colaborando en el

proyecto que entendindolo. De la misma manera, determinados co-

laboradores o clientes rechazarn una metodologa demasiado mo-

derna o flexible por desconocimiento.

1.5.1. Metodologa prxima al software libre:eXtreme Programming

eXtreme Programming o programacin eXtrema, es una de las meto-

dologas llamadas giles, para el desarrollo de proyectos de software.

Se basa en los principios de la simplicidad, la comunicacin, la re-

troalimentacin y el coraje para implicar a todo el equipo (y a los

usuarios o clientes) en la gestin del proyecto. En 1996, Kent Back y

Ward Cunningham pusieron en prctica una nueva metodologa

primando la simplicidad y evitando los hbitos que convertan las

cosas fciles en difciles durante el desarrollo de un proyecto en

DaimlerChrysler. El resultado fue la metodologa eXtreme Programming

o XP (que por supuesto nada tiene que ver con software de la compaa

Microsoft).

1.5. Ejemplos de metodologas

29

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

En su forma ms genrica, las metodologas giles proponen una im-

plicacin total del cliente en el proyecto, y llevan al lmite el modelo de

desarrollo evolutivo en espiral. Esto es, realizar un plan de proyecto

basado en versiones del producto acordadas a partir de funcionalida-

des concretas, y realizar el desarrollo para esas funcionalidades con-

cretas. Una vez entregada la versin del proyecto cumpliendo con los

requisitos (no un prototipo, sino una versin funcionando), el proceso

vuelve a iniciarse con un conjunto mayor de funcionalidades.

Los procesos y prcticas de esta metodologa estn basados en la ex-

periencia de equipos de desarrollo, y en los errores cometidos o en-

contrados una y otra vez al utilizar metodologas ms tradicionales.

Sin embargo, veremos que algunas de sus propuestas son bastante

chocantes y otras sern incompatibles con grandes organizaciones o

grandes proyectos.

La proximidad de esta metodologa al entorno del software libre viene

dada por sus principios bsicos, ms que por su aplicacin concreta.

En los prximos apartados examinaremos estos principios y veremos

que algunos estn muy cercanos al software libre, mientras que otros

(sobre todo los que tienen que ver con el cliente, o con la programa-

cin en pares) no suelen ser demasiado aplicables.

eXtreme Programming, puede dividirse en cuatro principios sobre los

que se va iterando hasta que el proyecto ha finalizado (el cliente aprue-

ba el proyecto). Estas fases o principios son planificacin, diseo, de-

sarrollo y pruebas. Aunque a primera vista parece que no estamos

aadiendo nada nuevo a las metodologas tradicionales, es en los de-

talles de cada fase, y en los objetivos que nos marcaremos en cada una

de ellas (iteracin tras iteracin) donde estn las mayores diferencias.

Figura 7

Software libre

30

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Planificacin

La planificacin empieza con la confeccin de las Historias de usua-

rio. De manera similar a los casos de uso, se trata de breves frases es-

critas por el cliente (no ms de tres lneas), en las que se describe una

prestacin o un proceso sin ningn tipo de tecnicismo (es el usuario o

el cliente quien las escribe).

Estas historias de usuario servirn para realizar la planificacin de

releases, as como para los tests de aceptacin con el cliente. Para

cada historia deberamos poder estimar su tiempo ideal de desarro-

llo, que debera ser de 1, 2 o 3 semanas como mximo. Si el tiempo

de desarrollo es mayor, deberemos partir la historia en trozos que no

excedan de esas estimaciones.

A continuacin podemos pasar a la propia planificacin de la prxima

(o primera) release del proyecto. En la reunin de planificacin debe-

remos implicar al cliente, al gestor del proyecto y a los desarrolladores.

El objetivo ser planificar las siguientes releases poniendo en orden las

historias de usuario que faltan por desarrollar. Deber ser el cliente

quien dicte el orden de las historias de usuario, y los desarrollado-

res quienes estimen el tiempo que les llevara idealmente en desa-

rrollarlo (idealmente aqu significa sin tener en cuenta dependencias,

ni otros trabajos o proyectos, pero s incluyendo las pruebas).

Las historias de usuario se suelen reflejar en tarjetas o trozos de papel,

que se van agrupando y clasificando encima de la mesa durante la pla-

nificacin. El resultado deber ser un conjunto de historias que tengan

sentido, y que puedan llevarse a cabo en poco tiempo. Para planificar-

lo, podemos hacerlo segn dos criterios, basndonos en el tiempo has-

ta la siguiente release o en el alcance (entendido como el nmero de

funcionalidades) que deseamos que tenga.

Aqu introducimos un nuevo concepto, la velocidad del proyecto. Esta

velocidad nos servir para decidir cuntas historias de usuario va-

mos a incluir en la prxima release (si estamos planificando en base

al tiempo, ya fijado), o bien cuando vamos a tardar en lanzar la

release (si estamos planificando por alcance, ya fijado). La velocidad

del proyecto es simplemente el nmero de historias de usuario com-

pletadas en la iteracin anterior. Si se trata de la primera iteracin,

habr que hacer una estimacin inicial.

31

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

La velocidad puede aumentarse, si en el transcurso del desarrollo se

finalizan las historias de usuario previstas antes de tiempo. Entonces

los desarrolladores pedirn historias de usuario que estaban planea-

das para la siguiente release. Este mecanismo permite a los desarro-

lladores recuperarse en los periodos duros, para despus acelerar el

desarrollo si es posible. Recordemos que las historias deben tener to-

das una duracin mxima, y que cuanto ms parecido sea el volu-

men de trabajo estimado en cada una de ellas, ms fiable ser la

medida de velocidad del desarrollo.

Este mtodo de planificacin rpido y adaptativo nos permite hacer

un par de iteraciones para tener una medida fiable de lo que ser la

velocidad media del proyecto y estimar as ms detalladamente el

plan de releases (adems de haber empezado ya con el desarrollo

del mismo) en el intervalo de tiempo en que otras metodologas tar-

daran en documentar, planificar y realizar una estimacin completa,

que quiz no sera tan fiable.

En la reunin de planificacin, al inicio de cada iteracin, tambin

habr que incorporar las tareas que hayan generado los tests de

aceptacin que el cliente no haya aprobado. Estas tareas se sumarn

tambin a la velocidad del proyecto, y el cliente, que es quien escoge

las historias de usuario que hay que desarrollar, no podr elegir un

nmero mayor que el de la velocidad del proyecto.

Los desarrolladores convertirn las historias de usuario en tareas (esas

s en lenguaje tcnico) de una duracin mxima de tres das ideales de

programacin cada una. Se escribirn en tarjetas y se pondrn enci-

ma de la mesa para agruparlas, eliminar las repetidas, y asignarlas a

cada programador. Es de vital importancia evitar aadir ms funcio-

nalidades que las que la historia de usuario estrictamente requiera.

Esta tendencia de los gestores de proyectos o analistas acostumbrados

a las metodologas tradicionales debe evitarse en modelos iterativos

como ste, ya que desvirtan las estimaciones y el principio de releases

frecuentes.

Con las tareas resultantes, se volver a comprobar que no estamos

excediendo la velocidad del proyecto, eliminando o aadiendo his-

torias de usuario hasta llegar a su valor. Es posible que historias de

usuario diferentes tengan tareas en comn, y esta fase de la planifi-

cacin nos permitir filtrarlas, para as poder aumentar la velocidad

del proyecto aadiendo ms historias de usuario en esta iteracin.

Software libre

32

AN

OTA

CIO

NES

FUOC XP04/90795/01133

En el momento de planificar el equipo de trabajo encargado de cada

tarea o historia, es importante la movilidad de las personas, intentar

que cada dos o tres iteraciones todo el mundo haya trabajado en todas

las partes del sistema. Conceptos como el pair programming, que vere-

mos en siguientes apartados, tambin pueden ayudar.

Diseo

Durante el diseo de la solucin, y de cada historia de usuario que

lo requiera, la mxima simplicidad posible es la clave para el xito

de esta metodologa. Sabiendo que un diseo complejo siempre tar-

da ms en desarrollarse que uno simple, y que siempre es ms fcil

aadir complejidad a un diseo simple que quitarla de uno comple-

jo, siempre deberemos hacer las cosas lo ms sencillas posible, evi-

tando aadir funcionalidad no contemplada en esa iteracin.

Asimismo, es importante y se ha probado muy til encontrar una me-

tfora para definir el sistema. Es decir, un proceso o sistema que to-

dos conozcan (el cliente, el gestor del proyecto, los desarrolladores)

y que puedan identificar con el proyecto que se est desarrollando.

Encontrar una buena metfora ayudar a tener:

Visin comn: todo el mundo estar de acuerdo en reconocer dnde

est el ncleo del problema, y en cmo funciona la solucin. Nos

ayudar a ver cmo ser el sistema o qu podra llegar a ser.

Vocabulario compartido: la metfora nos ayudar a sugerir un vo-

cabulario comn para los objetos y procesos del sistema. Depen-

diendo de la metfora escogida, el vocabulario puede ser altamente

tcnico o por el contrario muy comn.

Generalizacin: la metfora puede sugerir nuevas ideas o solucio-

nes. Por ejemplo, en la metfora el servicio de atencin al cliente es

una cadena de montaje, nos sugiere que el problema va pasando

de grupo en grupo de gente. Pero tambin nos hace pensar en qu

pasa cuando el problema llega al final de la cadena...

Arquitectura: la metfora dar forma al sistema, nos identificar

los objetos clave y nos sugerir caractersticas de sus interfaces.

33

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Para el diseo del sistema, se sugiere llevar a cabo reuniones entre to-

dos los desarrolladores implicados, donde se toman las decisiones me-

diante el uso de tarjetas CRC (class, responsabilities y collaboration).

Cada tarjeta representa un objeto del sistema, en la que su nombre

aparece escrito en la parte superior, sus responsabilidades en la parte

izquierda y los objetos con los que colabora en la parte derecha.

El proceso de diseo se realiza creando las tarjetas (al inicio slo es-

cribiremos el nombre en ellas, el resto ya se ir completando) y si-

tundolas prximas a las que comparten interfaces o llamadas. Las

tarjetas correspondientes a objetos que heredan o son interfaces de

otros pueden situarse encima o debajo.

Este mecanismo ayuda a que todo el mundo participe y aporte sus

ideas en el diseo moviendo las tarjetas encima de la mesa segn

ste va progresando. Si se llega a un punto muerto y se decide volver

a empezar, ser tan simple como limpiar la mesa y volver a ir si-

tuando las tarjetas. No tendremos que borrar diagramas ni hacer

trabajo extra diseando alternativas. Cuando tengamos el diseo

definitivo, tambin ser ms fcil de mantener en la memoria por

parte de los participantes y es entonces cuando entraremos en deta-

lle en cada objeto y haremos los diagramas necesarios.

Finalmente, es clave tambin el concepto de refactorizacin, es decir,

el hecho de realizar cambios necesarios en las partes de cdigo que

lo requieran, sin modificar su funcionalidad o su interaccin con el

resto del sistema. A medida que vayamos avanzando en iteraciones

en el proyecto, nos veremos obligados a modificar o ampliar partes

de cdigo ya escritas anteriormente. En ese momento, en lugar de

dejar lo que funcionaba sin tocarlo y desarrollar el mdulo adicio-

nal para la nueva funcionalidad, deberemos hacer el esfuerzo de

Figura 8

Software libre

34

AN

OTA

CIO

NES

FUOC XP04/90795/01133

refactorizar el mdulo existente, dejndolo igual de simple pero con

la nueva funcionalidad aadida. Ser siempre mucho ms fcil de

probar, de explicar y de comprender para el resto del equipo.

Este concepto, provocar cambios en el diseo que habamos hecho

en iteraciones anteriores, pero esto no es perjudicial, sino al contra-

rio. Deberemos darnos cuenta de que el diseo evoluciona iteracin

tras iteracin, por lo que el diseo anterior ya estar obsoleto a partir

de ese momento, y acostumbrarnos a ello.

Codificacin

Una primera diferencia importante entre esta metodologa y las lla-

madas tradicionales es la disponibilidad del cliente, que debe ser

total. En lugar de limitarse a escribir durante semanas una hoja de

requisitos, el cliente debe participar en las reuniones de planifica-

cin, tomar decisiones, y estar disponible para los desarrolladores

durante los tests funcionales y de aceptacin.

Debido a la movilidad de los desarrolladores durante el proyecto,

participando en cada iteracin en partes distintas del mismo, es de

vital importancia acordar unos estndares de codificacin y respetar-

los en el desarrollo. Cada lenguaje de programacin tiene sugeren-

cias o reglas ms o menos detalladas al respecto. Deberemos ser tan

concretos como sea posible, no dejando al libre albedro temas

como la indentacin en el cdigo, la sintaxis y nombres de variables,

etc. En casi todos los casos existen unas convenciones recomendadas

por los creadores del lenguaje que cubren estos aspectos.

Siempre es conveniente tener en cuenta estas recomendaciones y uti-

lizarlas tal cual o bien adaptarlas a las preferencias de nuestros pro-

gramadores, pero en cualquier caso es imprescindible definir las

decisiones tomadas al respecto.

Por lo que respecta a la propia codificacin en s, eXtreme Program-

ming nos propone que antepongamos la creacin de los tests unita-

rios al propio desarrollo de las funcionalidades. Los tests unitarios se

explicarn con detalle en el captulo correspondiente, pero bsica-

mente son pequeos trozos de cdigo que prueban las funcionalida-

des de un objeto, de modo que esa prueba pueda incorporarse a un

35

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

proceso de pruebas automatizado. La mayora de los lenguajes tie-

nen hoy en da libreras para crear y ejecutar pruebas unitarias.

La idea que se fragua detrs de esta propuesta es que creando pri-

mero las pruebas que deber pasar nuestro cdigo, tendremos una

idea ms clara de lo que deberemos codificar, y nos guiaremos por

ello, implementando nicamente lo que nos permita pasar la prue-

ba. Tambin tendremos ventajas adicionales al conocer cundo he-

mos acabado de implementar la funcionalidad requerida, o en la

comprensin de la misma.

Otra caracterstica diferencial de eXtreme Programming es el pair pro-

gramming o la programacin por parejas. Se ha demostrado que dos

programadores, trabajando conjuntamente, lo hacen al mismo ritmo

que cada uno por su lado, pero el resultado obtenido es de mucha

ms calidad. Simplemente los dos sentados frente al mismo monitor,

y pasndose el teclado cada cierto tiempo, provoca que mientras uno

est concentrado en el mtodo que est codificando, el otro piense en

cmo ese mtodo va a afectar al resto de objetos y la interaccin, las

dudas y propuestas que surgen reducen considerablemente el nmero

de errores y los problemas de integracin posteriores.

En una metodologa incremental como sta, la integracin con lo

que ya se ha desarrollado en iteraciones anteriores es clave. No hay

una nica solucin a ese problema. Dependiendo del proyecto y del

equipo de trabajo, se pueden proponer soluciones, como por ejem-

plo designar dueos para cada objeto, que conozcan todos los

tests unitarios y de integracin que debe pasar, y se ocupe de inte-

grarlo en cada release. Otra alternativa es que cada pareja de pro-

gramadores se hace responsable de integrar cuando todos los tests

de la tarea que estaban realizando pasan al 100%. De este modo,

aadimos al paradigma release-often (distribuye o implanta a menu-

do) el integrate-often (integra a menudo), reduciendo enormemente

las posibilidades de problemas de integracin.

Pruebas

Ya hemos hablado sobre las pruebas unitarias en la fase anterior, y

se vern en detalle en el apartado correspondiente. Es importante

Software libre

36

AN

OTA

CIO

NES

FUOC XP04/90795/01133

insistir en este tema, ya que, aun en el caso de tener una fecha de

entrega muy prxima, la construccin de las pruebas unitarias va a

ahorrarnos mucho ms tiempo del que invertimos programndolas,

buscando pequeos fallos y protegindonos contra ellos de forma

permanente durante el resto del desarrollo.

Cuanto ms complicada sea la prueba, ms necesaria es para ase-

gurar que despus el desarrollo hace lo que se requiere.

A veces existe la tendencia a pensar que las pruebas unitarias pue-

den hacerse durante los ltimos tres meses de desarrollo. Esto es

errneo, ya que sin esas pruebas, el desarrollo se alarga esos tres

meses, y quiz ms.

Los tests unitarios ayudarn tambin a la refactorizacin, ya que ase-

gurarn que los cambios que hayamos introducido en la iteracin

actual no afecten a la funcionalidad.

Cuando encontremos un fallo o bug en los tests de aceptacin con el

cliente, o durante el uso, deberemos crear un test unitario que lo com-

pruebe. As aseguramos que no vuelve a surgir en siguientes iteraciones.

Los tests de aceptacin se crearn a partir de las historias de usuario.

Una historia puede tener uno o varios tests, segn sea la funcionali-

dad que hay que probar. El cliente es responsable de definir los tests

de aceptacin, que deberan ser automatizables en la medida de lo

posible. Estos test son del tipo caja negra, en el sentido de que ni-

camente nos definen el resultado que debe tener el sistema ante unas

entradas concretas. Los tests de aceptacin que no tengan xito gene-

rarn nuevas tareas para la prxima iteracin, afectando as a la velo-

cidad del proyecto, y proporcionando adems una puntuacin del xito

o fracaso de cada historia de usuario, o de cada equipo de trabajo.

Conclusiones

Hemos visto de manera rpida e introductoria la metodologa eXtreme

Programing, y comentado sus particularidades respecto a las metodo-

logas tradicionales. Sin duda, introduce algunos conceptos novedosos

37

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

y hasta discutibles como el pair-programming, pero tambin usa tc-

nicas ms convencionales como las tarjetas CRC.

Prescindiendo de los detalles, lo que XP propone es un cambio de pa-

radigma a lo largo de toda la metodologa. Las herramientas concretas,

como las pruebas unitarias, las historias de usuario, la refactorizacin,

etc. no son ms que recursos que tambin podramos utilizar en otras

metodologas. Lo verdaderamente destacable de XP es su forma de or-

denar el ciclo de vida del proyecto, y la involucracin con el cliente. Sin

esto, no estamos haciendo XP.

Sus principales caractersticas lo hacen muy adecuado para proyectos

de software libre, aunque, como hemos visto en su breve historia, no fue

concebido con este objetivo. Otros aspectos como el pair-programming

o el diseo colaborativo con tarjetas CRC no son tan aplicables en este

mbito.

1.5.2. Metodologa clsica: Mtrica v3

Mtrica v3 es la metodologa de planificacin, desarrollo y mante-

nimiento de sistemas de informacin promovida por la Secretara del

Consejo Superior de Informtica del Ministerio de Administraciones

Pblicas, que es el rgano interministerial responsable de la poltica

en informtica del Gobierno espaol.

Aunque su mbito inicial es el de las administraciones pblicas, las

mejoras introducidas en la versin 3 y el mejor uso de estndares y

normas de ingeniera del software hacen que su alcance pueda am-

pliarse a las administraciones autonmicas, locales y al resto de em-

presas y organizaciones.

Entre las mejoras introducidas en la versin 3.0 (publicada en el

ao 2000), destaca la incorporacin de nuevos mtodos y tecnolo-

gas (cliente/servidor, interfaz grfica de usuario, orientacin a ob-

jetos), as como la incorporacin de aspectos de gestin (que la

metodologa denomina interfaces) para mejorar aspectos que no perte-

necen a una sola fase, sino que intervienen a lo largo del proyecto,

como son la gestin del mismo, la calidad y la seguridad, entre otros.

Software libre

38

AN

OTA

CIO

NES

FUOC XP04/90795/01133

La estructura de la metodologa sigue el clsico mtodo en cascada

basado en los siguientes procesos:

Planificacin

Desarrollo

Mantenimiento

Cada proceso de los anteriores detalla las actividades y tareas que

hay que realizar, de manera que para cada tarea se indican:

Las tcnicas y prcticas a utilizar.

Los responsables de realizarla.

Sus productos de entrada y salida.

Figura 9

39

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

El aspecto ms destacable de esta metodologa no es tanto lo que pue-

da aportar como innovacin a la ingeniera del software en s, sino el

esfuerzo que se ha hecho por poner a disposicin pblica una metodo-

loga completa, ms o menos actualizada, y que representa un marco

inicial de referencia para presentar proyectos a la Administracin pbli-

ca (que lo exigen como requisito), pero que podemos adaptar a nuestra

empresa o proyecto en el sector privado, si nuestra organizacin se sien-

te ms cmoda con modelos clsicos de desarrollo.

Mtrica v3 define muy bien los documentos de entrada de cada pro-

ceso, actividad y tarea, as como el resultado que genera. A lo largo

de ste y los siguientes apartados, vamos a destacar los ms relevan-

tes. Si se desea ampliar informacin, la documentacin disponible es

muy extensa, y existen ejemplos, cursos de autoformacin, as como

programas auxiliares de ayuda y seleccin de herramientas compa-

tibles con la metodologa.

Planificacin de sistemas de informacin

Este proceso tiene como objetivo ltimo la creacin del Plan de siste-

mas de informacin (PSI) de la organizacin. Adaptando el marco y

los objetivos, podemos utilizar sus actividades para generar el plan

del proyecto en concreto en el que estamos trabajando.

Entre las actividades que deberemos realizar, destacan:

Descripcin de la situacin actual.

Conjunto de modelos que constituye la arquitectura de la infor-

macin.

Priorizacin y calendario de los proyectos a desarrollar.

Evaluacin de los recursos necesarios.

Plan de seguimiento y cumplimiento, bajo una perspectiva estra-

tgica y operativa.

El plan debe ser realizado a alto nivel, sin tecnicismos y con una pers-

pectiva estratgica y operativa. Asimismo, es fundamental que la di-

reccin se implique en su desarrollo. Para la descripcin de la

Software libre

40

AN

OTA

CIO

NES

FUOC XP04/90795/01133

situacin actual, el nivel de detalle depender de la documentacin

de que se disponga y de la predisposicin de la organizacin a una

sustitucin total o parcial del sistema de informacin actual.

El cuadro completo de actividades que hay que llevar a cabo durante

esta fase es el siguiente:

Figura 10

Actividades

1. Inicio del Plan de sistemas de informacin

El objetivo de esta primera actividad es la obtencin de la

descripcin general del Plan de sistemas de informacin,

identificando los objetivos generales en los que se centra,

y el mbito al que afecta dentro de la organizacin.

Se deber identificar tambin a los participantes en la

elaboracin del plan, que definirn los factores crticos

de xito del mismo.

El mtodo de obtencin de esta informacin es la par-

ticipacin en sesiones de trabajo del comit de direc-

cin hasta que nombre a los gestores del proyecto.

2. Definicin y organizacin del plan

Una vez se han determinado los responsables del pro-

yecto, y sus objetivos, deberemos detallar el alcance del

plan, organizar el equipo de personas que lo van a llevar

41

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

a cabo y elaborar un calendario de ejecucin. Este ca-

lendario deber incluir una valoracin en trminos

econmicos a partir de estimaciones, que permitan to-

mar decisiones en cuanto a su aprobacin.

Una vez definido el plan de trabajo para la realizacin

del propio plan, se deber comunicar a la direccin para

su aprobacin definitiva.

3.Estudio de la informacin relevante

La primera actividad, una vez aprobado el plan, deber

ser la recopilacin y anlisis de todos los antecedentes

generales que puedan afectar a los procesos y recursos

contemplados en el plan, as como los resultados que

presentaron. De especial inters sern los estudios reali-

zados con anterioridad, relativos a los sistemas de

informacin del mbito del plan como a su entorno

tecnolgico.

La informacin que obtengamos ser de utilidad para

realizar la toma de requisitos en actividades posteriores.

4. Identificacin de requisitos

La toma de requisitos se realizar mediante el estudio de

los procesos en el mbito del plan. El modelo de estos

procesos, junto con sus actividades y funciones, la infor-

macin implicada en ellos y las unidades organizativas o

recursos que en l participan, se obtendr de reuniones

de trabajo con usuarios expertos o tcnicos implicados.

Una vez contrastadas las conclusiones, se elaborar el

modelo de procesos implicados, unificando en la medida

de lo posible los que guarden relacin entre ellos, con el

objetivo de tener una visin lo ms general posible.

A continuacin se debern analizar las necesidades de

informacin de cada proceso modelado anteriormente,

y se elaborar un modelo de informacin que refleje las

principales entidades y las relaciones existentes entre

ellas en trminos de informacin de entrada/salida, sus

actividades y sus funciones.

Software libre

42

AN

OTA

CIO

NES

FUOC XP04/90795/01133

A continuacin se debern analizar las necesidades de

informacin de cada proceso modelado anteriormen-

te, y se elaborar un modelo de informacin que refleje

las principales entidades y las relaciones existentes en-

tre ellas en trminos de informacin de entrada/salida,

sus actividades y sus funciones.

Finalmente, elaboraremos el catlogo de requisitos a

partir de la informacin obtenida en actividades ante-

riores, y de las necesidades de informacin y proceso

obtenidos previamente. Es importante priorizar los re-

quisitos, sobre la base de las opiniones de los usuarios

y los objetivos del plan.

5. Estudio de los sistemas de informacin actuales

A partir de los sistemas actuales afectados por el plan,

se deber obtener una valoracin de la situacin ac-

tual, basada en criterios como la facilidad de manteni-

miento, documentacin, flexibilidad, facilidad de uso,

nivel de servicio, etc. Los usuarios aportarn aqu los

elementos de valoracin ms importantes.

Es importante obtener una valoracin lo ms objetiva

posible, ya que sta va a influir en la decisin de mejo-

ra o sustitucin de cada proceso o sistema.

6. Diseo del modelo de sistemas de informacin

En este punto tendremos informacin suficiente para

decidir en qu sistemas aplicamos mejoras o bien qu

sistemas sustituimos, y en cada caso, cul deber ser el

sistema resultante.

Una vez tomadas estas decisiones, debemos obtener el

modelo de sistemas de informacin, que incluir un

diagrama de representacin de todos ellos, con sus co-

nexiones e interfaces, y una descripcin de cada siste-

ma con el conjunto de procesos y requisitos que cubre.

43

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

7.Definicin de la arquitectura tecnolgica

En esta actividad debemos proponer una arquitectura

tecnolgica, a alto nivel, que d soporte al modelo de

sistemas de informacin, y que puede incluir, si es ne-

cesario, opciones. Para esta actividad tendremos en

cuenta sobre todo los requisitos de carcter tecnolgi-

co, aunque puede ser necesario comprender el catlo-

go completo de requisitos.

La definicin y eleccin entre las alternativas posibles

deber realizarse sobre la base del entorno actual, los

estndares, y apoyndonos en anlisis coste/beneficio

e impacto en la organizacin de cada alternativa.

8.Definicin del plan de accin

El plan de accin ser el que definir los proyectos con-

cretos a llevar a cabo para la implantacin de los sistemas

y modelos de informacin definidos en las actividades an-

teriores.

Dentro del plan de accin, se incluir un calendario de

proyectos, con posibles alternativas y una estimacin

de recursos. Para la elaboracin de este plan, ser im-

portante tener en cuenta las prioridades que habremos

marcado en materia de requisitos, y los sistemas impli-

cados en cada uno de ellos.

Por ltimo, tambin ser importante la realizacin de un

plan de mantenimiento y control de la ejecucin de los

proyectos.

9.Revisin y aprobacin del plan

Finalmente, debemos presentar la arquitectura de infor-

macin diseada y el plan de accin a los responsables

de la direccin del mismo. Mejoraremos la propuesta si

es necesaria y obtendremos la aprobacin final.

Software libre

44

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Desarrollo de sistemas de informacin

El plan de sistemas tena como objetivo proporcionar un marco es-

tratgico que sirva de referencia. Una vez completado el plan de ac-

cin, pasaremos al desarrollo de cada proyecto.

En l, algunas actividades sern rplicas de actividades realizadas en

el plan de sistemas (toma de requisitos, anlisis de la situacin ac-

tual, etc.). Si el plan se ha realizado con el suficiente nivel de detalle,

o se refera nicamente a un proyecto concreto, estas actividades no

sern necesarias. En caso contrario, sern las primeras en llevarse a

cabo en este proceso.

Estudio de viabilidad

Si el plan de sistemas nos ha dejado con varias alternativas para un

proyecto en concreto, en la primera fase deberemos estudiar la via-

bilidad de cada una, en trminos de impacto en la organizacin e

inversin a realizar.

En todo caso, la primera actividad que Mtrica v3 define en la fase

de desarrollo es el estudio de la viabilidad del proyecto, que debera

generar uno o varios documentos (segn las alternativas considera-

das) con un ndice como el que sigue:

Solucin propuesta:

Descripcin de la solucin

Modelo de descomposicin en subsistemas

Figura 11

45

Ingeniera del software en entornos de SL

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Matriz procesos / Localizacin geogrfica

Matriz datos / Localizacin geogrfica

Entorno tecnolgico y comunicaciones

Estrategia de implantacin global del sistema

Descripcin de procesos manuales

Si la alternativa incluye desarrollo:

Modelo abstracto de datos / Modelo de procesos

Modelo de negocio / Modelo de dominio

Si la alternativa incluye un producto software estndar de mercado:

Descripcin del producto

Evolucin del producto

Costes ocasionados por el producto

Estndares del producto

Descripcin de adaptacin (si es necesaria)

Contexto del sistema (con la definicin de las interfaces)

Impacto en la organizacin de la solucin

Coste / Beneficio de la solucin

Valoracin de riesgos de la solucin

Enfoque del plan de trabajo de la solucin

Planificacin de la solucin

Anlisis del sistema de informacin

El objetivo de este proceso es la obtencin de una especificacin de-

tallada del sistema de informacin que satisfaga las necesidades de

los usuarios y sirva de base para el posterior diseo del sistema.

Mtrica v3 soporta el desarrollo tanto con lenguajes estructurados,

como orientados a objetos, pero las actividades particulares en cada

caso estn integradas en una estructura comn.

Software libre

46

AN

OTA

CIO

NES

FUOC XP04/90795/01133

Las dos primeras actividades sern recuperar y profundizar en la de-

finicin del sistema y la toma de requisitos del mismo, con el objetivo

de detallar al mximo el catlogo de requisitos y describir con preci-

sin el sistema de informacin.

A continuacin empezar el cuerpo del anlisis, formado por cuatro

actividades que se realimentarn entre s, hasta tener el anlisis com-

pleto del sistema. De las cuatro actividades, dos son comunes para

desarrollos estructurados u orientados a objetos, mientras que las

otras dos son diferentes en cada caso.

Las actividades son:

Identificacin de subsistemas