Enfoque producto y proceso Ing. de Soft

Lbles de

AS alarmas comenzaron más de una década antes del acontecimiento. Con menos dedos años a la fecha señalada, los medios de comunicación recogieron la historia. Losoficiales del gobierno expresaron su preocupación, los directores de la industria y de los

comprometieron grandes cantidades de dinero, y por Último, las advertencias catástrofe llegaron a la conciencia del público. El software, al igual que el ahora famoso

error podría fallar, y como resultado, detener el mundo como nosotros lo conocimos.Como vimos durante los últimos meses del año 1999,sin querer, no puedo dejar de pen-

sar en el párrafo profético contenido en la primera página de la cuarta edición de este libro.Decía:

El software de computadora se ha convertido en el alma Es la máquina que conduce a la toma de decisiones comerciales. Sirve de base para la investigación científica moderna y de resolución de pro-blemas de ingeniería. Es el factor clave que diferencia los productos y servicios modernos. Está inmerso ensistemas de todo tipo: de transportes, médicos, de telecomunicaciones, militares, procesos industriales, entre-tenimientos, productos de oficina..., la lista es interminable. El software es casi ineludible en un mun-do moderno. A medida que nos adentremos en el siglo será el que nos conduzca a nuevos avances en todo, desde la educación elemental a la ingeniería genética.

es? El software de computadora esel producto que y construyen

ca programas que se ejecutan

qué es importante? Porqueafecta muy de cerca a cualquier

a y está muyomercio, cuí-

coti-

e impresos y datos que combinan información resultantenúmeros y texto y incluyenrepresentaciones de información de queaudio, vídeo e imágenes. conducea un resultado de alta calidad

lohace?Los ingenierosde soft- que satisface las necesidades de laware construyen, y virtualmente gente que usará el producto. Debescualquier persona en el mundo indus- aplicar un enfoque de ingeniería d etrialiiado lo utiliza bien directa o software.

trabajo.

obtenido?Des-de el punto devista deun ingeniero desoftware, e l producto obtenidoson losprogramas, documentos y los datosque configuran el software de

de elpunto de vista delos usuarios el producto obt

algún modo mund

puedo estar de quelo he hecho L e eel resto libro,selecciona aque-llas ideas que al soft-ware que construyes y aplícalas a tu

Cinco años después de que la cuarta edición de este libro fue escrita, el papel del software como «alma ha llegado a ser más director de software de Intemet ha produ-cido su propia economía de 500 billones de Euros. En la euforia creada por la promesa de unparadigma económico nuevo, los inversores de Wall Street dieron a las pequeñas empresas

estimaciones en billones de dólares antes de que éstas a producir undólar en ventas. Han surgido nuevas industrias dirigidas por software y las antiguas que no se han adaptado a esta nueva tendencia están ahora amenazadas de extinción. El gobierno de Esta-dos Unidos ha mantenido un contencioso frente a la mayor compañía de la industria del soft-ware, como lo mantuvo hace poco tiempo cuando se movilizó para detener las actividades monopolísticas en las industrias del acero y del aceite.

El impacto del software en nuestra sociedad y en la cultura continúa siendo profundo. Almismo tiempo que crece su importancia, la comunidad del software trata continuamente dedesarrollar tecnologías que hagan más sencillo, rápido y menos costosa la construcción de pro-gramas de computadora de alta calidad.

Este libro presenta un marco de trabajo que puede ser usado por aquellos que construyensoftware -aquellosque lo deben hacer bien-. La tecnología que comprende unproceso, un juego de métodos y un conjunto de herramientas se llama ingeniería del software.

3

DEL SOFTWARE. UN ENFOQUE PRACTICO

Hoy en día el software tiene un doble papel. Es un pro-ducto y, al mismo tiempo, el vehículo para entregarlo. Como producto, hace entrega de la potencia informáti-ca que incorpora el hardware informático o, más amplia-mente, una red de computadoras que es accesible por hardware local. Si reside dentro de un teléfono celular u opera dentro de una computadora central, el softwa-re es un transformador de información, produciendo, gestionando, adquiriendo, modificando, mostrando otransmitiendo información que puede ser tan simplecomo un solo bit, o tan complejo como una presenta-ción en multimedia. Como vehículo utilizadopara hacer entrega del producto, el software actúa como la base decontrol de la computadora (sistemas operativos), la comunicación de información (redes) y la creación ycontrol de otros programas (herramientas de softwarey entomos).

El es tonto un producto,como el vehículo poro su entrego

El papel del software ha sufrido un cam-bio significativo durante un periodo de tiempo superior a 50 años. Enormes mejoras en rendimiento delware, profundos cambios de arquitecturas informáticas, grandes aumentos de memoria y capacidad de almace-namiento y una gran variedad de opciones de entrada ysalida han conducido a sistemas más sofisticadosy máscomplejos basados en computadora. La sofisticación y la complejidad pueden producir resultados deslum-brantes cuando un sistema tiene éxito,pero también pue-den suponer grandesproblemas para aquellos que deben construir sistemas complejos.

Librospopulares publicados durante los años 70 y 80proporcionan una visión histórica útil dentro de la per-cepción cambiante de las computadoras y del software,y de su impacto en nuestra cultura. hablaba de una «nueva revolución Toffler

llamó a la llegada de componentes trónicos la «tercera ola del cambio» en la historia de lahumanidad, y Naisbitt predijo la transformación de la sociedad industrial a una «sociedad de informa-ción».Feigenbaumy sugirieronquela informacióny el conocimiento (controlados por com-putadora) serían el foco de poder del siglo veintiuno, y

argumentó que la «comunidad electróni-ca» creada mediante redes y software es la clave para el intercambiode conocimiento alrededor del mundo.

Al comienzo de los años 90, Toffler descri-bió un «cambio de poder» en el que las viejas estructu-ras de poder (gubernamentales, educativas, industriales, económicas y militares) se desintegrarían a medida que

las computadoras y el software nos llevaran a lacratización del conocimiento». A Yourdon lepreocupaba que las compañías en Estados Unidos pudie-ran perder su competitividad en empresas relativas alsoftware y predijo «el declive y la caída del programa-dor americano». Hammer y Champy argu-mentaron que las tecnologías de información iban a desempeñar el papel principal en la de lacompañía». A mediados de los años 90, la persistencia delas computadoras y del una erupción de libros por (por ejemplo: Resisting the Vir-tual editadopor James Brook y Ian y There not Compute de Stephen Talbot). Estos autores critican enormemente la computadora, haciendo énfasis en preocupaciones legítimas pero ignorando los profun-dos beneficios que se han llevado a cabo

más fáciles,que facilitan no

Al final de los años 90, Yourdon volvió a evaluar las perspectivas del software profesional y sugi-rió la y elevación» del programador ame-ricano. A medida que internet creció en importancia, sucambio de pensamiento demostró ser correcto. Al finaldel siglo veinte, el enfoque cambió una vez más. Aquí tuvo lugar el impacto de la «bomba de relojería» Y2K(por ejemplo: Aunquemuchos vieron las predicciones de los críticos del Y2Kcomo reacciones, sus populares lecturas devolvieron ladifusión del software a sus vidas. Hoy en día, com-putación omnipresente» ha producido una gene-ración de aplicaciones de información que tienenconexión en banda ancha a la Web para proporcionar

capa de conexión sobre nuestras casas, oficinas, yautopistas» El papel del software continúa suexpansión.

El programador solitario de antaño ha sido reempla-zado por un equipode especialistasdel software, cada unocentradoen una parte de la tecnología requerida para entre-gar una aplicación concreta. Y de este modo, las cuestio-nes que se preguntaba el programador solitario son las mismas cuestiones que nos preguntamos cuando cons-truimos sistemas basados en computadoras:

4

CAPITULO 1 EL PRODUCTO Y EL PROCESO

Estadísticas de software

qué lleva tanto tiempo terminar los programas? qué son tan elevados los costes de desarrollo?qué no podemos encontrar todos los errores

antes de entregar el software a nuestros clientes? qué nos resulta difícil constatar el progreso con-

forme se desarrolla el software?

En 1970, menos del uno por ciento de las personas podría haber descrito inteligentemente lo que significa-ba «softwarede computadora». Hoy, la mayoría de losprofesionales y muchas personas en general piensan ensu mayoríaque comprenden el software. lo entien-den realmente?

1.2.1.Características del softwarePara poder comprender lo que es el software (y con-secuentemente la ingeniería del software), es impor-tante examinar las características del software que lodiferencian de otras cosas que los hombres pueden construir. Cuando se construye hardware, el procesocreativo humano (análisis, diseño, construcción, prue-ba) se traduce finalmente en una forma física. Si cons-truimos una nueva computadora, nuestro boceto inicial, diagramas formales de diseño y prototipo deprueba, evolucionan hacia un producto físico (chips, tarjetas de circuitos impresos, fuentes de potencia,etc.).

El software es un elemento del sistema que eslógico, en lugar de físico. Por tanto el software tie-ne unas características considerablemente distintas a las del hardware:

c VEEl software se desarrolla, no se fabrica.

El software se desarrolla,

Aunque existen similitudes entre el desarrollo del soft-ware y la construcción del hardware, ambas activida-des son fundamentalmente diferentes. En ambasactividades la buena calidad se adquiere mediante unbuen diseño, pero la fase de construcción delware puede problemas de calidad que no existen (o son fácilmente corregibles) en el software.Ambas actividades dependen de las personas, pero larelación entre las personas dedicadas y el trabajo rea-lizado es completamente diferente para el software (véase el Capítulo 7). Ambas actividades requierenla construcción de un «producto» pero los enfoquesson diferentes.

no se fabrica en un sentido clásico.

Los costes del software se encuentran en la ingeniería. Esto significaque proyectos de software no se puedengestionar como si fueran proyectos de fabricación.

2. El software no se «estropea».La Figura 1.1 describe, para el hardware, la proporciónde falloscomouna función del tiempo. Esa relación, deno-minada frecuentemente «curva de bañera», indica que el hardware exhibe relativamente muchos fallos al pio de su vida (estos fallos son atribuibles normalmente a defectos del diseño o de la fabricación);una vez corre-gidos los defectos, la tasa de falloscae hasta un nivel esta-cionario (bastante bajo, con un poco de optimismo) donde permanece durante un cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, el hardware empie-za a desgastarse y la tasa de fallos se incrementa.

El software no es susceptible a los males del entor-no que hacen que el hardware se estropee. Por tanto, en teoría, la curva de fallos para el software tendría la for-ma que muestra la Figura 1.2.Los defectos no detecta-dos haran que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corri-gen (suponiendo que no se introducen nuevos errores) la curva se aplana, como se muestra. La curva ideali-zada es una gran simplificación de los modelos reales de fallos del software más información en elCapítulo 8). Sin embargo la implicación es clara, el soft-ware no se estropea. se deteriora!

CLAVEEl software no se estropea, pero se deteriora.

Mortalidad Se estropea

al

al

Tiempo

FIGURA 1.1. Curva de fallos del hardware.

5


Esto que parece una contradicción, puede compren-derse mejor considerando curva mostrada en la Figura 1.2. Durante su vida, el software sufre cambios (mantenimiento). Conforme se hacen los cambios, esbastante probable que se introduzcan nuevos defectos, haciendo que la curva de fallos tenga picos como se veen la Figura 1.2.Antes de que la curva pueda volver alestado estacionario original, se solicita otro cambio, haciendo que de nuevo se cree otro pico. Lentamente, el nivel mínimo de fallos comienza a crecer softwarese va deteriorando debido a los cambios-.

Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software. Cuando un componente de hardware se estropea se sustituye por una pieza de repues-to. No hay piezas de repuesto para el software. Cada falloen el software indica un error en el diseño o en el proce-so mediante el que se tradujo el diseño a código máqui-na ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que ladel mantenimiento del hardware.

3. Aunque la industria tiende a ensamblar componen-tes, la mayoría del software se construye a medida.

Consideremos la forma en la que se diseña y se cons-truye el hardware de control para un producto basa-do en computadora. El ingeniero de diseño construye un sencillo esquema de la circuitería digital, hace algún análisis fundamental para asegurar que se con-sigue la función adecuada y va al armario donde seencuentran los catálogos de componentes digitales. Después de seleccionar cada componente, puedecitarse la compra.

Incrementodel índice de fallos

idealizada

Tiempo

FIGURA 1.2. Curvas de fallos real e idealizada del software.

CLAVElos métodos de ingenieríade software se esfuerzanpara reducir magnitudde los picos y inclinaciónde curva 1.2).

A medida que la disciplina del software evoluciona, se crea un grupo de componentes de diseño estándar. Torni-llos estándar y circuitos integrados preparados para la ven-ta son solamente los dos mil coinponentes estándar que utilizan ingenieros mecánicos y eléctricos cuando dise-ñan nuevos sistemas. Los componentes reutilizables se han creado para que el ingeniero pueda concentrarse enelementos verdaderamente innovadores de un diseño, porejemplo, las partes del diseño que representan algo nue-vo. En el mundo del hardware, la reutilización de com-ponentes es una parte natural del proceso de ingeniería.En el mundo del software es algo que sólo ha comenza-do a en una escala amplia.

El componente de software debería diseñarse eimplementarse para que pueda volver a serdo en muchos programas diferentes. En los años 60,se construyeron bibliotecas de subrutinas científicas reutilizables en una amplia serie de aplicaciones cien-tíficas y de ingeniería. Esas bibliotecas de subrutinasreutilizaban de forma efectiva algoritmos bien defi-nidos, pero tenían un dominio de aplicación limita-do. Hoy en día, hemos extendido nuestra visión dereutilización para abarcar no sólo los algorítmos, sinotambién estructuras de datos. Los componentestilizables modernos encapsulan tanto datos como pro-cesos que se aplican a los datos, permitiendo alingeniero del software crear nuevas aplicaciones apartir de las partes reutilizables. Por ejemplo, las interfaces gráficas de usuario de hoy en día se cons-truyen frecuentemente a partir de componentestilizables que permiten la creación de ventanasgráficas, de menús despleglables y de una ampliavariedad de mecanismos de interacción.

c V Emayoría del sigue construyéndose a medida.

1.2.2. Aplicaciones del softwareEl software puede aplicarse en cualquier situación en laque se haya definido previamente un conjunto especí-fico de pasos procedimentales (es decir, un algoritmo)(excepciones notables a esta regla son el software delos sistemas expertos y de redes neuronales). El conte-nido y el determinismo de la información son factores importantes a considerar para determinar la naturaleza de una aplicación de software. El contenido se refiere al significado y a la forma de la información de entra-da y salida. Por ejemplo, muchas aplicaciones banca-rias usan unos datos de entrada muy estructurados (una base de datos) y producen con determina-dos formatos. El software que controla una máquinaautomática (por ejemplo: un control numérico) acepta elementos de datos discretos con una estructura limita-da y produce órdenes concretas para la máquina en rápi-da sucesión.

6

1 EL PRODUCTO Y EL PROCESO

l a revolución del se foto en 13.Lo ingenieríade software basada ense presento en el Capítulo 27.

El determinismo de la información se refiere a ladecibilidad del orden y del tiempo de llegada de losdatos.Un programa de análisisde ingeniería acepta datos que están en un orden predefinido, ejecuta el

de análisis sin interrupción y produce los datosresultantes en un informe o formato gráfico. Se dice quetales aplicaciones son determinadas. Un sistema opera-tivo multiusuario, por otra parte, acepta entradas quetienen un contenido variado y que se producen en ins-tantes arbitrarios, ejecuta algoritmos que pueden serinterrumpidos por condiciones externas y produce una salida que depende de una función del entorno y deltiempo. Las aplicaciones con estas características se diceque son indeterminadas.

Algunas veces es difícil establecer categorías gené-ricas para las aplicaciones del software que sean sig-nificativas. Conforme aumenta la complejidad delsoftware, es más difícil establecer compartimentos nítidamente separados. Las siguientes áreas del soft-ware indican la amplitud de las aplicaciones poten-ciales:

Software de sistemas. El software de sistemas esun conjunto de programas que han sido escritos paraservir a otros programas. Algunos programas de siste-mas (por ejemplo: compiladores, editores y utilidadesde gestión de archivos) procesan estructuras de infor-mación complejas pero determinadas. Otras aplicacio-nes de sistemas (por ejemplo: ciertos componentes del sistema operativo, utilidades de manejo deprocesadores de telecomunicaciones) procesan datos en gran medida indeterminados. En cualquier caso, el área del software de sistemas se caracteriza por una fuerteinteracción con el hardware de la computadora; una granutilización por múltiples usuarios; una operación con-currente que requiere una planificación, unación de recursos y una sofisticada gestión de procesos; unas estructuras de datos complejas y múltiplesfaces externas.

Software de tiempo real. El software quesucesos del mundo real conforme

ocurren, se denomina de tiempo real. Entre los elemen-tos del software de tiempo real se incluyen: un compo-nente de adquisición de datos que recolecta y da formato a la información recibida del entorno externo, un com-ponente de análisis que transforma la información según lorequiera la aplicación,un componentedeque responda al entorno externo, y un componente demonitorización que coordina todos los demás compo-nentes, de forma que pueda mantenerse la repuesta en tiempo real (típicamente en el rango de un milisegundoa un segundo).

Software de gestión. El proceso de la informacióncomercial constituye la mayor de las áreas de aplica-ción del software. Los discretos (por ejem-plo: nóminas, cuentas deetc.) han evolucionado hacia el software de sistemas deinformación de gestión (SIG) que accede a una o másbases de datos que contienen información comercial. Las aplicaciones en esta área reestructuran los datos existentes para facilitar las operaciones comerciales ogestionar la toma de decisiones. Además de las tareas convencionales de procesamientos de datos, las aplica-ciones de software de gestión también realizan cálculo interactivo (por ejemplo: el procesamiento de transac-ciones en puntos de ventas).

Software de ingeniería y científíco. El softwarede ingeniería y científico está caracterizado por los algoritmos de «manejo de números». Las aplicacio-nes van desde la astronomía a la vulcanología, desdeel análisis de la presión de los automotores a la diná-mica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática. Sin embargo, las nuevas aplicaciones del área de

se han alejado de los algoritmos con-vencionales numéricos. El diseño asistido porcomputadora (del inglés CAD), la simulación de sis-temas y otras aplicaciones interactivas, han comen-zado a coger características del software de tiemporeal e incluso del software de sistemas.

Software empotrado. Los productos inteligentes se han convertido en algo común en casi todos los merca-dos de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para con-trolar productos y sistemas de los mercados industria-les y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el con-trol de las teclas de un horno de microondas) o sumi-nistrar una función significativa y con capacidad decontrol (por ejemplo: funciones digitales en un auto-móvil, tales como control de la gasolina, indicadores enel salpicadero, sistemas de frenado, etc.).

Se puede encontrar una de mayores bibliotecasde en

Software de computadoras personales. El mercadodel software de computadoras personales ha germinado en las pasadas dos décadas. El procesamiento de tex-tos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales yredes o acceso a bases de datos externas son algunas delos cientos de aplicaciones.

DEL SOFTWARE. UN ENFOQUE

Software basado en Las páginas Web busca-das por un explorador son software que incorpora ins-trucciones ejecutables (por ejemplo, CGI, HTML, Perl, o Java), y datos (por ejemplo, hipertexto y una varie-dad de de audio y visuales). En esencia, la red viene a ser una gran computadora que proporciona unrecurso software casi ilimitado que puede ser accedidopor cualquiera con un modem.

Softwarede inteligenciaartificial.El softwarede inte-ligencia artificial (IA) hace uso de algoritmosno numéri-cos para resolver problemas complejospara los queno sonadecuadoselcálculooel análisis directo. Lossistemasexper-tos, también llamados sistemas basados en el conocimiento,reconocimientode patrones (imágenes y voz), redes

artificiales, prueba de teoremas, y los juegos sonrepresentativos de las aplicaciones de esta categoría.

Muchos observadores de la industria (incluyendo esteautor) han caracterizado los problemas asociados con el desarrollo del software como una «crisis». Más de unoscuantos libros (por ejemplo:

han recogido el impacto de algunos de losfallos mas importantes que ocurrieron durante la déca-da pasada. No obstante, los mayores éxitos conseguidos por la industria del software han llevado a preguntarse si el término (crisis del software) es aún apropiado. Robert autor de varios libros sobre fallos del soft-ware, representa a aquellos que han sufrido un cambiode pensamiento. Expone ver en mis ensayos históricos de fallos y en mis informes de excep-ción, fallos importantes en medio de muchos éxitos, unacopa que está [ahora] prácticamente

La palabra crisis se define en el diccionario Webstercomo punto decisivo en el curso de algo, momento,etapao evento decisivo o Sin embargo, en térmi-nos decalidad del software total y develocidad con la cualson desarrollados los productos y los sistemasbasados en

computadoras, no ha habido ningún «punto nin-gún decisivo»,solamente un lento cambio evo-lutivo, puntualizado por cambios tecnológicos explosivos en las disciplinas relacionadas con el software.

Cualquiera que busque la palabra crisis en el dic-cionario encontrará otra definición: punto decisivo en el curso de una enfermedad, cuando se ve más clarosi el paciente vivirá o morirá». Esta definición puededarnos una pista sobre la verdadera naturaleza de losproblemas que han acosado el desarrollo del software.

Lo que realmente tenemos es una aflicción crónica'.La palabra se define como «algo que causa penao desastre». Pero la clave de nuestro argumento es la defi-nición del adjetivo crónica:«muy duradero o que reapa-rece con frecuencia continuando indefinidamente». Esbastante más preciso describir los problemas que hemos estado aguantando en el negocio del software como unaaflicción crónica, en vez de como una crisis.

Sin tener en cuenta como lo llamemos, el conjunto de problemas encontrados en el desarrollo del software de computadoras no se limitan al software que fun-ciona correctamente». Es más, el mal abarca los pro-blemas asociados a cómo desarrollar software, cómomantener el volumen cada vez mayor de software exis-tente y cómo poder esperar mantenemos al corriente dela demanda creciente de software.

Vivimos con esta aflicción desde este día hecho,la industria prospera a pesar de Y así, las cosas podrán ser mejores si podemos encontrar y aplicar unremedio.

Muchas de las causas de la crisis del software se pue-den encontrar en una mitología que surge durante los primeros años del desarrollo del software. A diferencia de los mitos antiguos, que a menudo proporcionaban a los hombres lecciones dignas de tener en cuenta, losmitos del software propagaron información errónea y

confusión. Los mitos del software tienen varios atribu-tos que los hacen insidiosos: por ejemplo, aparecieron como declaraciones razonables de hechos (algunas veces conteniendo elementos verdaderos), tuvieron un senti-do intuitivo y frecuentemente fueron promulgados por expertos que «estaban al día».

Esta terminología fue sugerida por el profesor Daniel Tiechrow de laUniversidad de en una conferencia impartida en Ginebra,Suiza, Abril, 1989.

8


Mitos de gestión. Los gestores con responsabilidad sobre el software, como los gestores en la mayoría delas disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el pro-yecto y mejorar la calidad. Igual que se agarra al vacíouna persona que se ahoga, un gestor de software se aga-rra frecuentemente a un mito del software, aunque tal creencia sólo disminuya la presión temporalmente.

Mito. Tenemos ya un libro que está lleno deres y procedimientos para construir software, le pro-porciona ya a mi gente todo lo que necesita saber?

Realidad. Está muy bien que el libro exista, pero jse los trabajadores su existencia?, jrefleja las prácticas modernas de desarrollo de soft-ware?, completo?, diseñado para mejorar eltiempo de entrega mientras mantiene un enfoque decalidad? En muchos casos, la respuesta a todas estas preguntas es

Mito. Mi gente dispone de las herramientas de desa-rrollo de software más avanzadas, después de todo, lescompramos las computadoras más modernas.

Realidad. Se necesita mucho más que el último modelo de computadora grande o de PC para hacer desa-rrollo de software de gran calidad. Las herramientas deingeniería del software asistida por computadora (CASE) son más importantes que el hardware para con-seguir buena calidad y productividad, aunque la mayo-ría de los desarrolladores del software todavía no lasutilicen eficazmente.

Mito. Si fallamos en la planificación, podemos añadirmás programadores y adelantar el tiempo perdido (el lla-mado algunasveces «conceptode la horda

Realidad. El desarrollo de software no es un proce-so mecánico como la fabricación. En palabras de Bro-oks «...añadir gente a un proyecto de softwareretrasado lo retrasa aún Al principio, esta declara-ción puede parecer un contrasentido. Sin embargo, cuan-do se añaden nuevas personas, la necesidad de aprender ycomunicarsecon el equipopuede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo.

añadirse gente, pero sólo de una manera planifica-da y bien coordinada.

l a red de gestión de proyectos de softwareen puede ayudarle a estos y otros mitos.

Mitos del Cliente. Un cliente que solicita una apli-cación de software puede ser una persona del despachode al lado, un grupo técnico de la sala de abajo, el depar-tamento de ventas o una compañía exterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestoresy desarrolladores del software hacen muypoco para corregir la mala información. Los mitos con-ducen a que el cliente se cree una expectativay, final-mente,quede insatisfecho con el que desarrollael software.

Mito. Una declaración general de los objetivos es sufi-ciente para comenzar a escribir los programas -pode-mos dar los detalles más adelante-.

Realidad. Una mala definición inicial es la principal causadel trabajo baldío en software. Es esencialuna des-cripción formal y detallada del ámbito de la información, funciones, comportamiento, rendimiento, interfaces, liga-duras del diseño y criterios de validación. Estas caracte-rísticas pueden determinarse sólo después de unaexhaustiva comunicación entre el cliente y el analista.

Mito. Los requisitos del proyecto cambian conti-nuamente, pero los cambios pueden acomodarse fácil-mente, ya que el software es flexible.

l a gestión y control cambiocon detalle en el 9

Definición Desarrollo Después de la entrega

FIGURA 1.3. El impacto del cambio.

Realidad. Es verdad que los requisitos del softwa-re cambian, pero el impacto del cambio varía según el momento en que se introduzca. La Figura 1.3 ilustra elimpacto de los cambios. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principiopueden acomodarse fácilmente. El cliente puede revi-sar los requisitos y recomendar las modificaciones conrelativamente poco impacto en el coste. Cuando los cam-bios se solicitan durante el diseño del software, el impac-to en el coste crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de tra-bajo del diseño. Los cambios pueden producir trastor-nos que requieran recursos adicionales e importantesmodificaciones del diseño; es decir, coste adicional. Los

9

DEL SOFTWARE. UN ENFOQUE PRÁCTICO

cambios en la función, rendimiento, interfaces u otrascaracterísticas, durante la implementación(codificacióny prueba) pueden tener un impacto importante sobre el coste. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud máscaro que el mismo cambio pedido al principio.

Mitos de los desarrolladores.Los mitos en los que aún creen muchos desarrolladores se han ido fomen-tando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la pro-gramación se veía como un arte. Las viejas formas yactitudes tardan en morir.

Mito. Una vez que escribimos el programa y hace-mos que funcione, nuestro trabajo ha terminado.

Realidad.Alguien dijo una vez: «cuanto más prontose comience a escribir código, más se tardará en termi-narlo». Los datos industriales indican que entre el 60 y el 80 por ciento de todo elesfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez.

muy duro poro entender lo que tienes que de empezar.No serías copoz de codo

detalle; por más que tomo el menor riesgo.

Mito. Hasta que no tengo el programa «ejecutándo-se»,realmente no tengo forma de comprobar su calidad.

Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garan-tizar la calidad del software: la revisión técnica formal.La revisión del software (descrito en el Capítulo 8) esun «filtrode calidad» que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases dedefectos en el software.

Mito. Lo único que se entrega al terminar el pro-yecto es el programa funcionando.

Un programa que funciona es sólo una par-te de una configuracióndel software que incluye muchoselementos. La documentación proporciona el funda-mento para un buen desarrollo y, lo que es más impor-tante, proporciona guías para la tarea de mantenimientodel software.

Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente. Lamen-tablemente, las actitudes y métodos habituales fomen-tan una pobre gestión y malas prácticas técnicas, incluso cuando la realidad dicta un método mejor. Elreconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prác-ticas para su desarrollo.

El software se ha convertido en el elemento clave dela evolución de los sistemas y productos informáticos. En los pasados 50 años, el software ha pasado de seruna resolución de problemas especializada y una herra-mienta de análisis de información, a ser una industriapor sí misma. Pero la temprana cultura e historia de la«programación» ha creado un conjunto de problemasque persisten todavía hoy. El software se ha converti-do en un factor que limita la evolución de los sistemas informáticos. El software se compone de programas, datos y documentos. Cada uno de estos elementos com-

ponen una configuración que se crea como parte del proceso de la ingeniería del software. El intento de laingeniería del software es proporcionar un marco detrabajo para construir software con mayor calidad.

te pones o no tiempoporodisciplino de lo ingeniería del y te preguntas:

tiempo poder

Brooks, The Mytical Addison-Wes-ley, 1975. 1997.

De Jager, et al, Countdown Business Sur-for the Year 2000, Wiley, 1998.

De Marco, T., Software Cost So Much?,Dorset House, 1995, 9.

Feigenbaum, E. A., y Gene-ration, Addison-Wesley, 1983. 1991.

Flowers, Software Failure, Management lure-Amaicing Stories and Wiley,1997

Glass, L., Software Prentice Hall,

Glass, there a Software Crisis?», IEEE vol. 15, 1, Enero 1998, pp. 104-105.

Hammer, M., y Champy,Reengineeringporation, Publisher, 1993.

Jones, Software Measurement,

Karlson, E., y Kolber, A Basic toHow the Year 2000 Computer Crisis You?,

Next Era Publications, Inc., 1999.

10


Levy, Luddites Are Newsweek, 12de

Levy, New Digital Newsweek,

Lientz, y E. Swanson, Software Maintenance

Naisbitt, Megatoends, Warner Books, 1982.Norman, TheInvisible Press, 1998.

Running Wild-The Next Industrial

Putnam, L., y Myers, Industrial Strength Soft-

Julio de 1995, 55.

31 de Mayo de 1999,

Addison Wesley, 1980.

.

Revolution, 1979.

ware, IEEE Computer Society Press, 1997.

Stoll, Egg, Doubleday, 1989.Toffler, A., The Third Wave, Morrow Publishers,

Toffler, A., Bantam Publishers, 1990.Yourdon, E., The Decline and the

Yourdon, E., The Rise and Resurrection the Ame-

Yourdon, E., Death March Projects, Prentice-Hall,

Yourdon, E., y Yourdon, Time 2000,

1980.

Programmer, Yourdon Press, 1992.

rican Programmer, Yourdon Press, 1996.

1998.

tice-Hall, 1998.

1.1. El software es la característica que diferencia a muchos productos y sistemas Dé ejemplos de dos o tresproductos y de, al menos, un sistema en el que el software, no el hardware, sea el elemento diferenciador.1.2. En los cincuenta y sesenta la programación de com-putadoras era un arte aprendido en un entorno básicamente experimental. ha afectado esto a las prácticas de desa-rrollo del software hoy? 1.3. Muchos autores han tratado el impacto de la de lainformación».Dé varios ejemplos (positivos y negativos) queindiquen el impacto del software en nuestra sociedad. Repa-se algunasreferencias de la Sección 1.1 previas a 1990 e indi-que dónde las predicciones del autor fueron correctas y dónde no lo fueron.1.4. Seleccione una aplicación específica e indique: (a) lacategoría de la aplicación de software (Sección 1.2.2) en laque encaje; (b) el contenido de los datos asociados con la apli-cación; (c) la información determinada de la aplicación.

1.5. A medida que el software se difunde más, los riesgos para el público (debido a programas defectuosos) se convierten en unapreocupación cada vez más significativa. Desarrolle un escena-rio realista del juicio final (distinto a en donde el fallo decomputadorapodría hacer un gran daño (económicoo humano).1.6. Lea detenidamente el grupo de noticias de Internet

y prepare un resumen de riesgos para las personascon las que se hayan tratado Últimamente. Código alternati-vo: Software Engineering Notes publicado por la ACM. 1.7. Escriba un papel que resuma las ventajas recientes enuna de las áreas de aplicaciones de software principales. Entre las selecciones potenciales se incluyen: aplicaciones avanza-das basadas en Web, realidad virtual, redes neuronales artificiales, interfaces humanas avanzadas y agentes inteligentes.1.8. Los mitos destacados en la Sección 1.4 se están vinien- do abajo lentamente a medida que pasan los años. Pero otros se están haciendo un lugar. Intente añadir un mito o dos mitos«nuevos» a cada categoría.

Literalmente existen miles de libros escritos sobre software de computadora. La gran mayoría tratan los lenguajes de pro-gramacióno aplicaciones de software, y sólo unos pocos tratan el software en sí. Pressman y Herron (Software Sock,Dorset House, 1991) presentaron una discusión (dirigida a noprofesionales)acerca del software y del modo en que lo cons-truyen los profesionales.

El libro, éxito de ventas, de Negroponte (Being Digital, Alfred A. Knopf, Inc., 1995) proporciona una visión de lascomputadoras y de su impacto global en el siglo Loslibros de Norman y Bergman (InformationAppliances Beyond, Academic Kauffman,2000) sugieren que el impacto extendido del PC declinaráal mismo tiempo que las aplicaciones de información yla difusión de la programación conecten a todos en el mun-

do industrializado y casi todas las aplicaciones a la nuevainfraestructura de Internet.

(The Software Conspiracy: Why Softwarepanies Put Out Faulty Products, How They Can Hurt You,and What You Can Do, 2000) argumentó queel «azote moderno» de los errores del software puede elimi-narse y sugiere formas para hacerlo. Software Cost So Much?, Dorset House, 1995) ha producidouna colección de ensayos divertidos e interesantes sobre el software y el proceso a través del cual se desarrolla.

En Intemet están disponibles una gran variedad de fuentes de información relacionadas con temas de gestión y desoftware. Se puede encontrar una lista actualizada con refe-rencias a sitios (páginas) web relevantes en man5.com.

11

OWARD Baetjer, Jr. en un libro fascinante que proporciona un punto devista economicista del software y de la ingeniería del software, comenta sobre el Hproceso:Como el software, al igual que el capital, es el conocimiento incorporado, y puesto que el conocimiento

está inicialmente disperso, el desarrollo del software implícito, latente e incompleto en gran medida, es unproceso social de aprendizaje. El proceso es un diálogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una interacción entre los usuarios y losdiseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramien-tas de desarrollo [tecnología]. Es un proceso interactivo donde la herramienta de desarrollo se usa comomedio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento de las personasinvolucradas.

Realmente, construir software de computadora es un proceso de aprendizaje iterativo, y elresultado, algo que Baetjer podría llamar del software», es el conjunto del softwarereunido. denurado v mientras se desarrolla el

es? Cuando trabaja para construirun producto o un sistema, es impor-tante seguir una serie de pasosdecibles -un mapa de carreteras quele ayude a obtener el resultado opor-tuno de calidad-. El mapa de carre-teras a seguir es llamado delsoftware..

lo hace?Los ingenieros de soft-ware y susgestores adaptan el proce-so a sus necesidades y entonces lo siguen.Además las personas que hansolicitado el software tienen un papela desempeñar en el proceso del soft-ware.

qué es importante?Porque pro-porciona estabilidad, control y organi-zación a una actividad que puede, sino se controla, volverse caótica.

son los pasos?A un nivel deta-llado, el proceso que adoptemosdepende del software que estamosconstruyendo. Un proceso puede ser apropiado para crear software de unsistema de aviación, mientras unproceso diferente por completo puedeser adecuado para la creación de unsitio web.

es el producto obtenido? Des-de el punto de vista de un ingeniero de

software, los productos obtenidos son programas, documentos y datos seproducen como consecuencia d e lasactividades de ingeniería del softwaredefinidas por el proceso.

puedo estar seguro de que lo he hecho correctamente?Hayuna cantidad de mecanismos deluacion del proceso del software quepermiten a las organizaciones deter-minar la de su proceso delsoftware. Sin embargo, la calidad, opor-tunidad y viabilidad a largo plazo delproducto que estáconstruyendo son los mejores indicadoresde la eficiencia delproceso que estamos utilizando.

Pero, es exactamente el proceso del softwaredesde un punto de vista técnico? Dentro del con-texto de este libro, definimos un proceso de software como un marco de trabajo de las tareas que se requieren para construir software de alta calidad. «proceso» sinónimo de ingeniería del softwa-re? La respuesta es y «no». Un proceso de software define el enfoque que se toma cuando el soft-ware es tratado por la ingeniería. Pero la ingeniería del software también comprende las tecnologíasque tiene el proceso-métodos técnicos y herramientas automatizadas-.

Aún más importante es que la ingeniería del software la realizan personas creativas, con conoci-miento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropia-do para los productos que construyen y para las demandasde su mercado. La intención de este capítulo es proporcionar un estudio del estado actual del proceso del software y puntualizar sobre el estudiodetallado de los temas de gestión y técnicos presentados en este libro.

13

DEL SOFTWARE. U N E N F O Q U E PRACTICO

Aunque cientos de autores han desarrollado definicio-nes personales de la ingeniería del software, una defi-nición propuesta por Fritz Bauer en unaconferencia de gran influencia sobre estos temas va aservir como base de estudio:

[La ingeniería del software] es el establecimiento y uso de prin-cipios robustos de la ingeniería a fin de obtener económicamentesoftware que sea fiable y que funcione eficientemente sobre máqui-nas reales.

Casi todos los lectores tendrán la tentación de seguir esta definición. No dice mucho sobre los aspec-tos técnicos de la calidad del software; no se enfren-ta directamente con la necesidad de la satisfacción delcliente o de la entrega oportuna del producto; omite la mención de la importancia de mediciones y métri-cas; tampoco expresa la importancia de un procesoavanzado. Y sin embargo, la definición de Bauer nos proporciona una línea base. son los «princi-pios robustos de la ingeniería» aplicables al desarro-llo de software de computadora? construimosel software «económicamente»para que sea «fiable»?

se necesita para crear programas de computa-dora que funcionen no en una máqui-na si no en diferentes «máquinas reales»? Éstas soncuestiones que siguen siendo un reto para los inge-nieros del software.

definimosIngeniería del software?

El IEEE ha desarrollado una definición más completa:

Ingeniería del software: La aplicación de un enfoque sis-temático, disciplinado y cuantificable hacia el desarrollo, opera-ción y mantenimiento del software; es decir, la aplicación de ingenieríaal software. (2) El estudio de enfoques como en

2.1.1. Proceso, métodos y herramientas

La Ingeniería del software es un tecnologíapa. Como muestra la Figura 2.1, cualquier enfoque deingeniería (incluida ingeniería del software) debe apo-yarse sobre un compromiso de organización de cali-dad.

FIGURA 2.1. Capas de la ingeniería del software.

El fundamento de la ingeniería del software es lacapa de proceso. El proceso de la ingeniería del soft-ware es la unión que mantiene juntas las capas de tec-nología y que permite un desarrollo racional y oportunode la ingeniería del software. El proceso define un mar-co de trabajo para un conjunto de Úreas clave de pro-ceso que se deben establecer para la entrega efectiva de la tecnología de la ingeniería del software. Las áreas claves del proceso forman la base del control de gestión de proyectos del software y esta-blecen el contexto en el que se aplican los métodos téc-nicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se esta-blecen hitos, se asegura la calidad y el cambio se ges-tiona adecuadamente.

Los métodos de la ingeniería del software indican «cómo» construir técnicamente el software. Los méto-dos abarcan una gran gama de tareas que incluyen aná-lisis de requisitos, diseño, construcción de programas,pruebas y mantenimiento. Los métodos de la ingenieríadel software dependen de un conjuntode principios bási-cos que gobiernan cada área de la tecnología e incluyenactividades de modelado y otras técnicas descriptivas.

CLAVEl a Ingenieríade comprende un proceso,métodos técnicosy de gestión, y herramientas.

Las herramientas de la Ingeniería del software pro-porcionan un enfoque automático o semi-automáticoparael proceso y para los métodos. Cuando se integran herra-mientas para que la información creada por una herra-mienta la pueda utilizar otra, se establece un sistema desoporte para el desarrollo del software llamado ingenie-ría del software asistida por computadora (CASE).

2.1.2. Una visión general de la ingeniería delsoftware

La ingeniería es el análisis, diseño, construcción, veri-ficación y gestión de entidades técnicas (o sociales).Con independencia de la entidad a la que se va a apli-car ingeniería, se deben cuestionar y responder las siguientes preguntas:

14

2 EL PROCESO

es el problema a resolver?son las características de la entidad que se

utiliza para resolver el problema?se realizará la entidad (y la solución)? se construirá la entidad?

enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la cons-trucción de la entidad?

se apoyará la entidad cuando usuarios soli-citen correcciones, adaptacionesy mejoras de la enti-dad?

Referencia Webes un periódico que proporciona y

comentarios prócticos de ingeniería del software. Estóndisponibles temas directamente en:www.stc.hill.af.mil

A lo largo de este libro, nos vamos a centrar en una sola entidad -el software de computadora-.Para construir la ingeniería del software adecuada-mente, se debe definir un proceso de desarrollo desoftware. En esta sección se consideran las caracte-rísticas genéricas del proceso de software. Más ade-lante, en este mismo capítulo, se tratarán modelos específicos de procesos.

El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas, con indepen-dencia del área de aplicación, tamaño o complejidad del proyecto. Cada fase se encuentra con una o varias cues-tiones de las destacadas anteriormente.

de definición se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software inten-ta identificarqué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, quérestricciones de diseño existen, y qué criterios de vali-dación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del siste-ma y del software. Aunque los métodos aplicados duran-te la fase de definición variarán dependiendo delparadigma de ingeniería del software (o combinaciónde paradigmas) que se aplique, de alguna manera ten-drán lugar tres tareas principales: ingeniería de sistemas o de información (Capítulo planificación del pro-yecto del software (Capítulos 3, 5 , 6 y 7) y análisis delos requisitos (Capítulos 11, 12 y 21).

El software crea tres fases distintas que secentran en definición, desarrollo y mantenimiento.

Lafase de desarrollo se centra en el cómo. Es decir,durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos,cómo ha de implementarse la función dentro de unaarquitectura de software, cómo han de implementarselos detalles procedimentales, cómo han de caracteri-zarse interfaces, cómo ha de traducirse el diseño en unlenguaje de programación (o lenguaje notal) y cómo ha de realizarse la prueba. Los métodos apli-cados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siem-pre: diseño del software (Capítulos 14, 15 y gene-ración de código y prueba del software (Capítulos 16,17 y 22).

Lafase de mantenimiento se centra en el cambio queva asociado a la corrección de errores, a las adaptacio-nes requeridas a medida que evoluciona el entorno delsoftware y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fasede mantenimiento se encuentran cuatro tipos de cam-bios:

Corrección.Incluso llevando a cabo las mejores acti-vidades de garantía de calidad, es muy probable que elcliente descubra los defectos en el software. El mante-nimiento correctivo cambia el software para corregir losdefectos.

Adaptación. Con el paso del tiempo, es probableque cambie el entorno original (por ejemplo: CPU, elsistema operativo, las reglas de empresa, las caracte-rísticas externas de productos) para el que se desarro-lló el software. El mantenimiento adaptativo producemodificaciónen el software para acomodarlo a los cam-bios de su entorno externo.

Mejora. Conforme se utilice el software, elpuede descubrir funciones adicionales que

van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se dete-riora debido al cambio, y por esto elventivo también llamado reingeniería del software, sedebe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el man-tenimiento preventivo hace cambios en programas decomputadora a fin de que se puedan corregir, adaptar ymejorar más fácilmente.

15


Además de estas actividades de mantenimiento, los usuarios de software requieren un mantenimiento con-tinuo. Los asistentes técnicos a distancia, teléfonos deayuda y sitiosWeb de aplicaciones específicas se mentan frecuentemente como parte de la fase de man-tenimiento.

el término «mantenimiento» reconocemos que es mucho más que una simple

de errores.

Hoy en día, el aumento de los programas' legales está forzando a muchas compañías a seguir estrategias de reingeniería del software (Capítulo 30). En un sen-tido global, la reingeniería del software se considera a menudo como una parte de la reingeniería de procesoscomerciales

Las fases y los pasos relacionados descritos en nues-tra visión genérica de la ingeniería del software se com-plementan con un número de actividades protectoras.

Actividades de protección

Entre las actividades típicas de esta categoría se incluyen: Seguimiento y control del proyecto de softwareRevisiones técnicas formales Garantía de calidad del software Gestión de configuración del software Preparación y producción de documentosGestión de reutilizaciónMedicionesGestión de riesgosLas actividades de protección se aplican a lo largo

de todo el proceso del software y se tratan en las partes Segunda y Quinta del libro.

Un proceso de software se puede caracterizar como se muestra en la Figura 2.2. Se establece un marco común del proceso definiendo un pequeño número de activida-des del marco de trabajo que son aplicables a todos losproyectos del software,con independenciade su tamañoo complejidad.Un número de conjuntosde tareas- c a d auno es una colección de tareas de trabajo de ingenieríadel software, hitos de proyectos, productos de trabajo, ypuntos de garantía de calidad-que permiten que las acti-vidades del marco de trabajo se adapten a las caracterís-ticas del proyecto del softwarey a los requisitos del equipo

Actividades del marco detrabajo

Tareas

FIGURA 2.2. El proceso del software.

término es un eufemismo para sottwareantiguo, a menudo diseñado y documentado pobremente, que es crí-tico para el negocio y debe ser soportado durante algunos años.

del proyecto. Finalmente, las actividades de protección-talescomo garantía de calidad del software,gestión deconfiguración del software y medición*-abarcan elmodelo de procesos. Las actividades de protección son independientes de cualquier actividad del marco de tra-bajo y aparecen durante todo el proceso.

En los Últimos años, se ha hecho mucho énfasis enla «madurez del El Softwate Engineering

ha desarrollado un modelo completo quese basa en un conjunto de funciones de ingeniería delsoftware que deberían estar presentes conforme orga-nizaciones alcanzan diferentes niveles de madurez del proceso. Para determinar el estado actual de madurezdel proceso de una organización, el utiliza un cues-tionario de evaluación y un esquema de cinco grados.

Seleccioneun de del proceso común que seproducto, personal y proyecto.

El esquema de grados determina la conformidad con un modelo de capacidad de madurez que defi-ne las actividades clave que se requieren en los dife-rentes niveles de madurez del proceso. El enfoque del

proporciona una medida de la efectividad global de

Estos temas se tratan con más detalle en capítulos posteriores. El autor se está refiriendo al de la Cannegie University.

16

CAPÍTULO 2 EL PROCESO

las prácticas de ingeniería del software de una compa-ñía y establece cinco niveles de madurez del proceso,que se definen de la forma siguiente:

Nivel 1: Inicial. El proceso del software se caracte-riza según el caso, y ocasionalmente incluso de forma caótica. Se definen pocos procesos, y el éxito dependedel esfuerzo individual.

Nivel 2: Repetible. Se establecen los procesos degestión del proyecto para hacer seguimiento del coste, de la planificación y de la funcionalidad. Para repetir éxitos anteriores en proyectos con aplicaciones simila-res se aplica la disciplina necesaria para el proceso.

Nivel 3: Definido. El proceso del software de lasactividades de gestión y de ingeniería se documenta, seestandariza y se integra dentro de un proceso de soft-ware de toda una organización.Todos los proyectos uti-lizan una versión documentada y aprobada del proceso de la organización para el desarrollo y mantenimientodel software. En este nivel se incluyen todas las carac-terísticas definidas para el nivel 2.

Nivel 4: Gestionado. Se recopilan medidas deta-lladas del proceso del software y de la calidad del pro-ducto. Mediante la utilización de medidas detalladas, se comprenden y se controlan cuantitativamente tan-to los productos como el proceso del software. En estenivel se incluyen todas las características definidas para el nivel 3.

Nivel 5: Optimización. Mediante una retroalimen-tación cuantitativadel proceso, ideas y tecnologías

se posibilita una mejora del proceso. En este nivel se incluyen todas las características definidas para el nivel 4.

El ofrece un amplio conjunto de información relacionada con el proceso en www.sei.cmu.edu

Merece la pena destacar que cada nivel superior esla suma de los niveles anteriores, por ejemplo, un desa-rrolladorde softwareen el nivel 3 tiene que haber alcan-zado el estado nivel 2 para poder disponer de susprocesos en el nivel 3.

El nivel 1 representa una situación sin ningún esfuer-zo en la garantía de calidad y gestión del proyecto, don-de cada equipo del proyecto puede desarrollar software de cualquier forma eligiendo los métodos, estándares yprocedimientos a utilizar que podrán variar desde lomejor hasta lo peor.

El nivel 2 representa el hecho de que un desarrolla-dor de software ha definido ciertas actividades tales como el informe del esfuerzo y del tiempo empleado, yel informe de las tareas realizadas.

El nivel 3 representa el hecho de que un desarrolla-dor de softwareha definido tanto procesos técnicos comode gestión, por ejemplo un para la programa-

ción ha sido detallado y se hace cumplir por medio de procedimientos tales como auditorías. Este nivel es aquelen el que la mayoría de los desarrolladores de softwa-re, pretenden conseguir con estándares como el ISO9001,y existen pocos casos de desarrolladores de soft-ware que superan este nivel.

El nivel 4 comprende el concepto de medición y eluso de métricas. El capítulo4 describe este tema con másdetalle. Sin embargo, cabe destacar el concepto de métri-ca para comprenderla importancia que tiene que el desa-rrollador del software alcance el nivel 4 o el nivel 5.

Una métrica es una cantidad insignificante que puede extraerse de algún documentoo código dentro de un pro-yecto de software. Un ejemplo de métrica es el número de ramas condicionales en una sección de código de unprograma. Esta métrica es significativa en el sentido deque proporciona alguna indicación del esfuerzo necesa-rio para probar el código: está directamente relacionado con el número de caminos de prueba dentro del código.

Una organización del nivel 4 maneja numerosasmétricas. Estas métricas se utilizan entonces para super-visar y controlar un proyecto de software, por ejemplo:

Una métrica de prueba puede usarse para determinarcuándo finalizar la prueba de un elemento del código. Una métrica de legilibilidad puede usarse para juz-gar la legilibilidad de algún documento en lenguaje natural.Una métrica de comprensióndel programa puede uti-lizarsepara proporcionar algún umbral numérico que los programadores no pueden cruzar. Para que estas métricas alcancen este nivel es nece-

sario que todos los componentes del nivel 3 CMM, encastellano MCM (Modelo de Capacidad de Madurez),estén conseguidos, por ejemplo notaciones bien defini-das para actividades como la especificación del diseñode requisitos, por lo que estas métricas pueden ser fácil-mente extraídas de modo automático.

El nivel 5 es el nivel más alto a alcanzar. Hasta aho-ra, muy pocos desarrolladores de software han alcan-zado esta fase. Representa la analogía del software con los mecanismos de control de calidad que existen enotras industrias de mayor madurez. Por ejemplo el fabri-cante de un producto industrial como un cojinete debolas (rodamiento) puede supervisar y controlar la cali-dad de los rodamientos producidosy puede predecir esta calidad basándose en los procesos y máquinas utiliza-dos para desarrollar los rodamientos. Del mismo modo que el desarrollador del sofware en el nivel 5 puede pre-decir resultados como el número de errores latentes enun producto basado en la medición tomada durante laejecución de un proyecto. Además, dicho desarrollador puede cuantificar el efecto que un proceso nuevo o herra-mienta de manufacturación ha tenido en un proyectoexaminando métricas para ese proyecto y comparándo-las con proyectos anteriores que no utilizaron ese pro-ceso o herramienta.

17

DEL SOFTWARE. U N E N F O Q U E

En este orden debe destacarse que para que unrrollador de software alcance el nivel 5 tiene que tenercada proceso definido rigurosamente y seguirlo al piede la letra; esto es una consecuencia de estar en elnivel 3. Si el desarrollador del software no tiene defi-nidos rigurosamente los procesos pueden ocurrir unagran cantidad de cambios en el proceso de desarrolloy no se podrán utilizar las estadísticas para estas acti-vidades.

Los cinco niveles definidos por el se obtienen como consecuencia de evaluar las respuestas del cues-tionario de evaluación basado en el MCM (Modelo decapacidad de madurez). Los resultados del cuestiona-rio se refinan en un único grado numérico que propor-ciona una indicación de la madurez del proceso de unaorganización.

El ha asociado áreas claves del proceso(ACPs) a cada uno de los niveles de madurez. LasACPs describen esas funciones de la ingeniería delsoftware (por ejemplo: planificación del proyecto desoftware, gestión de requisitos) que se deben pre-sentar para satisfacer una buena práctica a un nivelen particular. Cada ACP se describe identificando las características siguientes:

lodo organización esforzarse porolo profundidad del del Sinlo de cualquier aspecto del modelo puede eliminarse en su situación.

Objetivos- los objetivos globales que debe alcan-zar la ACPCompromisos-requisitos (impuestos en la organi-zación) que se deben cumplir para lograr los objeti-vos y que proporcionan una prueba del intento por ajustarse a los objetivos. Capacidades-aquellos elementos que deben encon-trarse (organizacional y técnicamente) para permitir que la organización cumpla los objetivos. Actividades- las tareas específicas que se requieren para lograr la función ACP.Métodos para supervisar la implementación-lamanera en que las actividades son supervisadas con-forme se aplican. Métodos para verificar la implementución-la formaen que se puede verificar la práctica adecuada para la ACP.Se definen dieciocho ACPs (descritas mediante la

estructura destacada anteriormente) en el modelo de

Referencia ’-Una tabular del MCM completo del incluyendotodos objetivos, comentarios, habilidades yactividades disponible en

madurez y se distribuyen en niveles diferentes de madu-rez del proceso. Las ACPs se deberían lograr en cadanivel de madurez de proceso4:

Nivel 2 de Madurez del ProcesoGestión de configuración del software Garantía de calidad del softwareGestión de subcontratación del softwareSeguimiento y supervisión del proyecto del software Planificación del proyecto del software Gestión de requisitos

Nivel 3 de Madurez del Proceso Revisiones periódicas Coordinación entre gruposIngeniería de productos de softwareGestión de integración del softwarePrograma de formaciónDefinición del proceso de la organización Enfoque del proceso de la organización

Nivel 4 de Madurez del ProcesoGestión de calidad del softwareGestión cuantitativa del proceso

Nivel 5 de Madurez del Proceso Gestión de cambios del procesoGestión de cambios de tecnologíaPrevención de defectos

Cada una de las ACPs se definen con un conjuntodeprácticas clave que contribuyen a cumplir estos obje-tivos. Las prácticas clave son normas, procedimientos y actividades que deben ocurrir antes de que se hayainstituido completamente un área clave de proceso. El

define a los clave como prác-ticas clave o componentes de prácticas clave que ofre-cen una visión mejor para lograr los objetivos de unárea clave de proceso». Las cuestiones de valoraciónse diseñan para averiguar la existencia (o falta) de unindicador clave.

Téngase en cuenta que las ACPs son acumulativas. Por ejemplo, elnivel 3 de madurez del proceso contiene todas las ACPs del nivel 2más las destacadas para el nivel

18

2 EL PROCESO

Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros debeincorporar una estrategia de desarrollo que acompañeal proceso, métodos y capas de herramientas descritos en la Sección 2.1.1 y las fases genéricas discutidas en la Sección 2.1.2. Esta estrategia a menudo se llama modelo de proceso oparadigma de ingeniería del soft-ware. Se selecciona un modelo de proceso para la inge-niería del software según la naturaleza del proyecto yde la aplicación, los métodos y las herramientas a utili-zarse, y los controles y entregas que se requieren. Enun documento intrigante sobre la naturaleza del proce-so del software, L.B.S. Raccoon utilizatales como base de estudio de la verdadera naturaleza del proceso del software.

Todo el desarrollo del software se puede caracteri-zar como bucle de resolución de problemas (Fig. en el que se encuentran cuatro etapas distintas: «status

definición de problemas, desarrollo técnico e inte-gración de soluciones. Status quo «representa el estadoactual de la definición de proble-mas identifica el problema específico a resolverse; el desarrollo técnico resuelve el problema a través de laaplicaciónde alguna tecnología y la integración de solu-ciones ofrece los resultados (por ejemplo: documentos, programas, datos, nueva función comercial, nuevo pro-ducto) a los que solicitan la solución en primer lugar. Las fases y los pasos genéricos de ingeniería del soft-ware definidos en la Sección 2.1.2 se divide fácilmen-te en estas etapas.

En realidad, es difícil compartimentar actividades de manera tan nítida como la Figura 2.3.b da a entender, porque existen interferencias entre las etapas. Aunque esta visión simplificada lleva a una idea muy impor-tante: con independencia del modelo de proceso que seseleccionepara un proyecto de software, todas las eta-pas-status quo, definición de problemas, desarrollo técnico e integración de soluciones-coexisten simul-táneamente en algún nivel de detalle. Dada la naturale-za recursiva de la Figura las cuatro etapas tratadas anteriormente se aplican igualmente al análisis de unaaplicación completa y a la generación de un pequeñosegmento de código.

Raccoon sugiere un «Modelo del Caos»que describe el «desarrollodel softwarecomo una exten-sión desde el usuario hasta el desarrollador y la tecno-logía». Conforme progresa el trabajo hacia un sistema

completo, las etapas descritas anteriormente se aplican recursivamente a las necesidades del usuario y a la espe-cificación técnica del desarrollador del software.

c VETodas etapas de un proceso del - e s t a d oactual, definición del problema, desarrollo técnico e integración de solución-coexisten simultáneamente en algún nivel de detalle.

En las secciones siguientes, se tratan diferentes mode-los de procesos para la ingeniería del software. Cadauna representa un intento de ordenar una actividad rentemente caótica. Es importante recordar que cadauno de los modelos se han caracterizado de forma que ayuden (con esperanza) al control y a la coordinaciónde un proyecto de software real. Y a pesar de eso, en elfondo, todos los modelos exhiben características del«Modelo del Caos».

Definiciónde problemas

Integraciónde soluciones

Desarrollotécnico

Estadoactual

FIGURA2.3.a) Las fases de un bucle de resolución de pro-blemas [RAC 951. Fasesdentro de las fasesdel bucle de resolución de problemas

19


2.4

Llamado algunas veces «ciclo de vida básico» olo en cascada», el modelo lineal secuencial sugiere unenfoque5 sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y pro-gresa con el análisis, diseño, codificación, pruebas y man-tenimiento. La Figura 2.4 muestra el modelo lineal secuencial para la ingeniería del software. Modelado según el ciclo de ingeniería convencional, el modelolineal secuencial comprende las siguientes actividades:

Ingeniería y modelado de Como el software siempre forma parte de un sistemamás grande (o empresa), el trabajo comienza estable-ciendo requisitos de todos los elementos del sistema yasignando al software algún de estos requisi-tos. Esta visión del sistema es esencial cuando el soft-ware se debe interconectar con otros elementos comohardware, personas y bases de datos. La ingeniería y elanálisis de sistemas comprende los requisitos que se recogen en el nivel del sistema con una pequeña parte de análisis y de diseño. La ingeniería de informaciónabarca los requisitos que se recogen en el nivel deempresa estratégico y en el nivel del área de negocio.

FIGURA 2.4. El modelo lineal secuencial.

Análisis de los requisitos del software. El procesode reunión de requisitos se intensifica y se centra espe-cialmente en el software. Para comprender la naturalezadel (los) a construirse, el ingeniero lista») del software debe comprender el dominio de información del software (descrito en el Capítulo 1 asícomo la función requerida, comportamiento, rendimien-to e interconexión.

Diseño. El diseño del software es realmente un pro-ceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectu-ra de software, representaciones de interfaz y detalleprocedimental (algoritmo). El proceso del diseño tra-duce requisitos en una representación del software donde

se pueda evaluar su calidad antes de que comience lacodificación.

Generación de código. El diseño se debe traduciren una forma legible por la máquina. El paso de gene-ración de código lleva a cabo esta tarea. Si se lleva acabo el diseño de una forma detallada, la generación decódigo se realiza mecánicamente.

Aunque el modelo lineal es a menudotradicional», resulto un enfoque razonable

cuando los requisitosse han entendido correctomente.

Pruebas. Una vez que se ha generado el código,comienzan las pruebas del programa. El proceso de prue-bas se centra en los procesos lógicos internos del soft-ware, asegurando que todas las sentencias se hancomprobado, y en los procesos externos funcionales; esdecir, realizar las pruebas para la detección de erroresy asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos.

Mantenimiento.El software indudablemente sufrirá cambios después de ser entregado al cliente (una excep-ción posible es el software empotrado). Se produciráncambios porque se han encontrado errores, porque el soft-ware debe adaptarse para acoplarse a los cambios de suentorno externo (por ejemplo: se requiere un cambio debi-do a un sistema operativo o dispositivo periférico nue-vo), o porque el cliente requiere mejoras funcionales ode rendimiento. El soporte y mantenimientodel softwa-re vuelve a aplicar cada una de las fases precedentes a unprograma ya existente y no a uno nuevo.

El modelo lineal secuencial es el paradigma más anti-guo y más extensamente utilizado en la ingeniería delsoftware. Sin embargo, la crítica del paradigma ha pues-to en duda su eficacia Entre los problemas que se encuentran algunas veces en el modelo lineal secuencial se incluyen:

1.

qué falla algunas vecesel modelo lineal?

Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo. Aunque el modelolineal puede acoplar interacción, lo hace indirecta-mente. Como resultado, los cambios pueden causar confusión cuando el equipo del proyecto comienza.

Aunque el modelo original en cascada propuesto por Winston Roycehacía provisiones para de la gran

mayoría de las organizaciones que aplican este modelo de procesolo hacen como si fuera estrictamente lineal.

20

2 EL PROCESO

A menudo es difícil que el cliente exponga explíci-tamente todos los requisitos. El modelo linealcial lo requiere y tiene dificultades a la hora deacomodar la incertidumbre natural al comienzo de muchos proyectos.El cliente debe tener paciencia. Una versión de tra-bajo del (los) no estará disponible hasta que el proyecto esté muy avanzado. Un grave errorpuede ser desastroso si no se detecta hasta que se revisa el programa.

Cada uno de estos errores es real. Sin embargo, elparadigma del ciclo de vida clásico tiene un lugar defi-nido e importante en el trabajo de la ingeniería del soft-ware. Proporciona una plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebas ymantenimiento. El ciclo de vida clásico sigue siendo elmodelo de proceso más extensamente utilizado por laingeniería del software. Pese a tener debilidades, esnificativamente mejor que un enfoque hecho al azar parael desarrollo del software.

Un cliente, a menudo, define un conjunto de objetivosgeneralespara el software, pero no identifica los requi-sitos detallados de entrada, proceso o salida. En otros casos,el responsable del desarrollo del software puede no estar seguro de la eficaciade un algoritmo, de la capa-cidad de adaptación de un sistema operativo, o de la for-ma en que debería tomarse la interacciónmáquina. En estas y en otras muchas situaciones, unparadigma de construcción de prototipos puede ofre-cer el mejor enfoque.

El paradigma de construcción de prototipos (Fig. 2.5) comienza con la recolección de requisitos. Elrrollador y el cliente encuentran y definen los objeti-vos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obli-gatoria más definición. Entonces aparece un «diseñorápido».El diseño rápido se centra en una representa-ción de esos aspectos del software que serán visibles para el (por ejemplo: enfoques de entra-da y de salida). El diseño rápido lleva a laconstrucción de un prototipo. El prototipo lo evalúa el

y se utiliza para refinar los requisitosdel software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las nece-sidades del cliente, permitiendo al mismo tiempo queel desarrollador comprenda mejor lo que se necesitahacer.

el tiene uno necesidadpero sobre losel poso es un

Lo ideal sería que el prototipo sirviera como un meca-nismo para identificar los requisitos del software. Si seconstruyeun prototipo de trabajo, el desarrolladorinten-ta hacer uso de los fragmentos del programa ya exis-tentes o aplica herramientas (por ejemplo: generadores de informes, gestores de ventanas, etc.) que permitengenerar rápidamente programas de trabajo.

Escucharal cliente

El clienteprueba

la maqueta

FIGURA 2.5. El paradigma de construcción de prototipos.

Pero hacemos con el prototipo una vez que haservidopara el propósito descrito anteriormente? Brooks

proporciona una respuesta:

En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar. Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez. No hay otra alterna-tiva que comenzar de nuevo, aunque nos duela pero es más inte-ligente, y construiruna versión rediseñada en la que se resuelvanestos problemas ...Cuando se utiliza un concepto nuevo de siste-ma o una tecnología nueva, se tiene que construir un sistema queno sirva y se tenga que tirar, porque incluso la mejor planificaciónno es omnisciente como para que esté perfecta la primera vez. Porlo tanto la preguntade la gestión no es si construir un sistema pilo-to y tirarlo. Tendremos que hacerlo. La Única pregunta es si pla-nificar de antemano construir un desechable, o prometerentregárselo a los clientes...

El prototipo puede servir como «primer sistema».El que Brooks recomienda tirar. Aunque esta puede seruna visión idealizada. Es verdad que a los clientes y alos que desarrollan les gusta el paradigma de cons-trucción de prototipos. A los usuarios les gusta el sis-tema real y a los que desarrollan les gusta construir algo inmediatamente. Sin embargo, la construcción de pro-totipos también puede ser problemática por las siguien-tes razones:

21

DEL SOFTWARE. U N E N F O Q U E

El cliente ve lo que parece ser una versión de trabajodel software, sin tener conocimiento de que el pro-totipo también está junto con chicle y el cable deembalar», sin saber que con la prisa de hacer quefuncioneno se ha tenido en cuenta la calidad del soft-ware global o la facilidad de mantenimiento a largo plazo. Cuando se informa de que el producto se debe construir otra vez para que se puedan mantener losniveles altos de calidad, el cliente no lo entiende ypide que se apliquen pequeños paraque se pueda hacer del prototipo un producto final. De forma demasiado frecuente la gestión de desa-rrollo del software es muy lenta.

2. El desarrollador, a menudo, hace compromisos deimplementación para hacer que el prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible y porque es conocido; un algo-ritmo eficiente se puede implementar simplemente

para demostrar la capacidad. Después de algúntiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora es una parte integral del sistema.

Resisto lo presión de ofrecer un prototipo en elproducto Corno lo colidod se resientesiempre.

Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma efectivo para la inge-niería del software. La clave es definir las reglas del jue-go al comienzo; es decir, el cliente y el desarrollador sedeben poner de acuerdo en que el prototipo se constru-ya para servir como un mecanismo de definición derequisitos.

El DesarrolloRápido de Aplicaciones (DRA)es un mode-lo de proceso del desarrollodel software lineal secuencial que un ciclo de desarrollo extremadamente cor-to. El modelo DRA es una adaptación a «alta velocidad»del modelo lineal secuencial en el que se logra el desa-rrollo rápido utilizando una construcción basada en com-ponentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equi-po de desarrollo crear un completamente fun-cional» dentro de períodos cortos de tiempo (por ejemplo: de a 90 días) Cuando se utiliza principal-mente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases

Modelado de Gestión. El flujo de información entrelas funciones de gestión se modela de forma que res-ponda a las siguientes preguntas: información con-duce el proceso de gestión? información se genera?

la genera? dónde va la información? la procesa? El modelado de gestión se describe con más detalle en el Capítulo 10.

Modelado de datos. El flujo de información defini-do como parte de la fase de modelado de gestión se refi-na como un conjunto de objetos de datos necesarios paraapoyar la empresa. Se definen las características (lla-madas atributos) de cada uno de los objetos y las rela-ciones entre estos objetos. El modelado de datos se trata en el Capítulo 12.

Modelado del proceso. Los objetos de datos defi-nidos en la fase de modelado de datos quedan transfor-mados para lograr el flujo de información necesarioparaimplementar una función de gestión. Las descripcionesdel proceso se crean para añadir, modificar, suprimir, orecuperar un objeto de datos.

En ingles: (Rapid Application Deveiopment)

Generación de aplicaciones. El DRA asume la uti-lización de técnicas de cuarta generación (Sección 2.10).En lugar de crear software con lenguajes de programa-ción de tercera generación, el proceso DRA trabaja paravolver a utilizar componentes de programas ya exis-tentes (cuando es posible) o a crear componentes lizables (cuando sea necesario). En todos los casos seutilizan herramientas para facilitar la construcción delsoftware.

Equipo 3

Modeladode datos

Modeladodegestión

Modeladode gestión

Modeladode procesosModelado

de datosGeneración

aplicacionesde

Modeladode procesos

Generación

Pruebasy entrega

FIGURA2.6.El modelo DRA.

22

2 EL PROCESO

Pruebas y entrega. Como el proceso DRAza la reutilización, ya se han comprobado muchos delos componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los com-ponentes nuevos y se deben ejercitar todas las ces a fondo.

ElDRA un fuerte deParo sobre el

de véase el 27.

El modelo de proceso DRA se ilustra en la Figura2.6. Obviamente, las limitaciones de tiempo impuestas en un proyecto DRA demandan «ámbito en escalas»

Si una aplicación de gestión puede se de forma que permita completarse cada una de lasfuncionesprincipales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipoDRA separado y ser integradas en un soloconjunto.

Al igual que todos los modelos de proceso, el enfo-que DRA tiene inconvenientes

Para proyectos grandes aunque por escalas, el DRArequiere recursos humanos suficientes como paracrear el número correcto de equipos DRA.DRA requiere clientes y desarrolladores compro-metidos en las rápidas actividades necesarias paracompletar un sistema en un marco de tiempo abre-viado. Si no hay compromiso por ninguna de las par-tes constituyentes, los proyectos DRA fracasarán.No todos los tipos de aplicaciones son apropiadospara DRA.Si un sistema no se puede modularizaradecuadamente, la construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el ren-dimiento convirtiendo interfaces en componentes desistemas, el enfoque DRA puede que no funcione.DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el softwarenuevo requiere un alto grado de interoperatividadcon programas de computadora ya existentes.

Se reconoce que el software, al igual que todos los sis-temas complejos, evoluciona con el tiempoLos requisitos de gestión y de productos a menudo cam-bian conforme a que el desarrollo proceda haciendo que el camino que lleva al producto final no sea real; lasestrictas fechas tope del mercado hacen que sea impo-sible finalizar un producto completo, por lo que se debeintroducir una versión limitada para cumplir la presión competitiva y de gestión; se comprende perfectamente el conjunto de requisitos de productos centrales o delsistema, pero todavía se tienen que definir los detalles de extensiones del producto o sistema. En estas y enotras situaciones similares, los ingenieros del software necesitan un modelo de proceso que se ha diseñadoexplícitamentepara acomodarse a un producto que evo-lucione con el tiempo.

El modelo lineal secuencial (Sección 2.4) se diseña para el desarrollo en línea recta. En esencia, este enfo-que en cascada asume que se va entregar un sistemacompletouna vez que la secuencia lineal se haya fina-lizado. El modelo de construcción de prototipos (Sec-ción 2.5) se diseña para ayudar al cliente (o al quedesarrolla) a comprender los requisitos. En general, no se diseña para entregar un sistema de producción. Enninguno de los paradigmas de ingeniería del software se tiene en cuenta la naturaleza evolutiva del software.

Los modelos evolutivos son iterativos. Se caracteri-zan por la forma en que permiten a los ingenieros delsoftwaredesarrollar versiones cada vez más completas del software.

2.7.1. El modelo incrementalEl modelo incrernental combina elementos del modelolineal secuencial (aplicados repetidamente) con la filo-sofía interactiva de construcción de prototipos. Comomuestra la Figura 2.7, el modelo incremental aplicasecuencias lineales de forma escalonada mientras pro-gresa el tiempo en el calendario. Cada secuencia lineal produce un «incremento» del software Porejemplo, el software de tratamiento de textos desarro-llado con el paradigma incremental podría extraer fun-ciones de gestión de archivos básicos y de producciónde documentos en el primer incremento; funciones deedición más sofisticadas y de producción de documen-tos en el segundo incremento; corrección ortográfica ygramatical en el tercero; y una función avanzada deesquema de página en el cuarto. Se debería tener en cuen-ta que el flujo del proceso de cualquier incremento pue-de incorporarel paradigma de construcciónde prototipos.

Elmodelo entrega el software en partespero utilizables, llamadas ((incrementos).

En general, cado incrementose construye sobre aquélque ya ho sido entregado.

Cuando se utiliza un modelo incremental, el primerincremento a menudo es un producto esencial. Es decir,se afrontan requisitos básicos, pero muchas funciones

23


Diseño

suplementarias (algunas conocidas, otras no) quedan sinextraer. El cliente utiliza el producto central (o sufre la revisión detallada). Como un resultado de utilizaciónde evaluación, se desarrolla un plan para el incrementosiguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del clien-te y la entrega de funciones, y características adiciona-les. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.

Código

Cuando tenga una fecha de entrega imposible de cambiar, el modela incremental es un buen

a considerar.

El modelo de proceso incremental, como la cons-trucción de prototipos (Sección 2.5) y otros enfoques evolutivos, es iterativo por naturaleza. Pero a dife-rencia de la construcción de prototipos, el modeloincremental se centra en la entrega de un productooperacional con cada incremento. Los primeros incre-mentos son versiones del producto final, pero proporcionan al usuario la funcionalidadque precisa y también una plataforma para la eva-luación.

El desarrollo incremental es particularmente útilcuando la dotación de personal no está disponible parauna implementación completa en la fecha límite que sehaya establecido para el proyecto. Los primeros incre-mentos se pueden implementar con menos personas.

incremento 1

Prueba incremento

,Código Prueba

2." incremento

incremento Análisis Pruebaincremento

Tiempo de calendario

FIGURA 2.7. El modelo incremental.

2.7.2. El modelo espiral

El modelo en espiral, propuesto originalmente por Boehm es un modelo de proceso de soft-ware evolutivo que conjuga la naturaleza iterativa deconstrucción de prototipos con los aspectos controla-dos y sistemáticos del modelo lineal secuencial. Pro-porciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo

nieria

del cliente

espiral, el software se desarrolla en una serie de ver-siones incrementales. Durante las primerasnes, la version incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas deltema diseñado.

Proyectode mantenimiento de productos.Proyectode mejora de productos.Proyecto de desarrollo de nuevos productos. Proyecto de desarrollo de conceptos.

FIGURA 2.8. Un modelo espiral típico.

24

2 EL PROCESO

El modelo en espiral se divide en un número de acti-de marco de trabajo, también llamadas regio-

de Generalmente, existen entre tres y seisregiones de tareas. La Figura 2.8 representa un modeloen espiral que contiene seis regiones de tareas:

más sofisticadas del software. Cada paso por la región de planificación produce ajustes en el plan del proyec-to. El coste y la planificación se ajustan con lamentacion ante la evaluación del cliente. Además, elgestor del proyecto ajusta el número planificado de

comunicación con el cliente-las tareas requeridas para establecer comunicación entre el desarrolladory el cliente.planificación- las tareas requeridas para definirrecursos, el tiempo y otra información relacionadas con el proyecto.análisis de riesgos-las tareas requeridas para eva-luar riesgos técnicos y de gestión.ingeniería-las tareas requeridas para construir unao más representaciones de la aplicación. construccióny acción-las tareas requeridas para construir, probar, instalar y proporcionar soporte alusuario (por ejemplo: documentación y práctica)evaluación del cliente- las tareas requeridas para obtener la reacción del cliente según la evaluaciónde las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

actividades del marco de trabajo se aplicana cualquier proyecto de que realice,sin tener en cuenta el ni complejidad.

Cada una de las regiones están compuestas por un con-junto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que vaa emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su formalidades bajo. Para proyectosmayores y más críticos cada región de tareas contiene tareas de trabajo que se definen para lograr un nivel más alto de formalidad. los casos, se aplican las acti-vidades de protección (por ejemplo: gestión de configu-ración del software y garantía de calidad del software) mencionadas en la Sección 2.2.

es un conjunto detareas?

Cuando empieza este proceso evolutivo, el equipode ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede produ-cir el desarrollo de una especificaciónde productos; lospasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones

raciones requeridas para completar el software.

Modelo de proceso adaptable.

A diferencia del modelo de proceso clásico que ter-mina cuando se entrega el software, el modelo en espi-ral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Una visión alternativa del modelo en espiral puede ser considerada examinando el eje de punto de entrada en el proyecto también refle-jado en la Figura 2.8. Cada uno de los cubos situados alo largo del eje pueden usarse para representar el pun-to de arranque para diferentes tipos de proyectos. Un

de desarrollo de comienza en elcentro de la espiral y continuará (aparecen múltiples raciones a lo largo de la espiral que limita la región

central) hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro deun producto real, el proceso continúa a través del cubosiguiente (punto de entrada del proyecto de desarrollodel producto nuevo) y se inicia un proyecto dedesarrollo”. El producto nuevo evolucionará a través deiteraciones alrededor de la espiral siguiendo el camino que limita la región algo más brillante que elesencia, la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. Hayveces en que el proceso está inactivo, pero siempre quese inicie un cambio, el proceso arranca en el punto deentrada adecuado (por ejemplo: mejora del producto).

El modelo en espiral es un enfoque realista del desa-rrollo de sistemas y de software a gran escala. Como elsoftware evoluciona, a medida que progresa el procesoel desarrollador y el cliente comprenden y reaccionanmejor ante riesgos en cada uno de los niveles evoluti-vos. El modelo en espiral utiliza la construcción de pro-totipos como mecanismo de reducción de riesgos, pero, lo que es más importante, permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cual-quier etapa de evolucióndel producto. Mantiene el enfo-que sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco de trabajorativo que refleja de forma más realista el mundo real.El modelo en espiral demanda una consideración

El modelo en espiral de esta sección esuna variante sobre el modelopropuesto por Boehm. Para más información sobre el modelo en espi-ral original, consulte Un tratado reciente del modeloen espiral puede encontrarse en

25


ta de los riesgos técnicos en todas las etapas del pro-yecto, y, si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos.

la Parte

Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar difícil conven-cer a grandes clientes (particularmente en situacionesbajo contrato) de que el enfoque evolutivo es controla-ble. Requiere una considerable habilidad para la eva-luación del riesgo, y cuenta con esta habilidad para el éxito. Si un riesgo importante no es descubierto y ges-tionado, indudablemente surgirán problemas. Final-mente, el modelo no se ha utilizado tanto como losparadigmas lineales secuenciales o de construcción deprototipos. Todavía tendrán que pasar muchos años antesde que se determine con absoluta certeza la eficacia deeste nuevo e importante paradigma.

2.7.3. El modelo espiral WINWIN

El modelo en espiral tratado en la Seccion 2.7.2 sugie-re una actividad del marco de trabajo que aborda la comunicación con el cliente. El objetivo de esta activi-dad es mostrar los requisitos del cliente. En un contex-to ideal, el desarrollador simplemente pregunta clientelo que se necesita y el cliente proporciona detalles sufi-cientes para continuar. Desgraciadamente, esto rara-mente ocurre. En realidad el cliente y el desarrolladorentran en un proceso de negociación, donde el clientepuede ser preguntado para sopesar la funcionalidad, ren-dimiento, y otros productos o características del siste-ma frente al coste y al tiempo de comercialización.

l a obtención de requisitos software requiere una negociación. Tiene éxito cuando ambas partes

Las mejores negociaciones se esfuerzan en obtener'«victoria-victoria». Esto es, el cliente gana obteniendo el producto o sistema que satisface la mayor parte desus el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entregarealista.

Hay docenas de libros escritos sobre habilidades en la negocia-ción ej., una de las cosas mas importantes que un ingeniero o gestor joven (oviejo) puede apren-der. Lea uno.

El modelo en espiral WINWIN de Boehmdefine un conjuntode actividades de negociación al prin-cipio de cada paso alrededor de la espiral. Más que unasimpleactividad de comunicación con el cliente, se defi-nen las siguientes actividades:

Identificación del sistema o subsistemas clave de los

2. Determinación de las «condiciones de victoria» delos directivos.

3. Negociación de las condiciones de «victoria» de losdirectivos para reunirlas en un conjunto de condi-ciones «victoria-victoria» para todos los afectados (incluyendo el equipo del proyecto de software).

Habilidadesde negociación

Conseguidos completamente estos pasos iniciales selogra un resultado «victoria-victoria», que será el crite-rio clave para continuar con la definición del sistema ydel software. El modelo en espiral WINWIN se ilustraen la Figura 2.9.

2. Identificar lascondiciones 3a. Reunir las condicionesde victoria de victoria.

y comentarios. 5. Definir el siguiente niveldel producto y del proceso,6. Validar las

definiciones incluyendo particiones.del productoy del proceso.

FIGURA 2.9. El modelo en espiral WINWIN

Además del énfasis realizado en la negociación ini-cial, el modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos deque ayudan a establecer la completitud de un ciclo alre-dedor de la espiral y proporcionan hitos de decisiónantes de continuar el proyecto de software.

En esencia, los puntos de fijación representan tres visiones diferentes del progreso mientras que el

Un directivo es alguien en la organización que tiene un interésdirecto, por el negocio, en el sistema o producto a construir y puedeser premiado por un resultado con éxito o criticado si el esfuerzofalla.

26

2 EL PROCESO

yecto recorre la espiral. El primer punto de fijación, llamado objetivos del ciclo de vida (OCV), define unconjunto de objetivos para cada actividad principal de ingeniería del software. Como ejemplo, de una par-te de OCV, un conjunto de objetivos asociados a ladefinición de los requisitos del delnivel más alto. El segundo punto de fijación, llama-do arquitectura del ciclo de vida (ACV), establece losobjetivos que se deben conocer mientras que se defi-ne la arquitectura del software y el sistema. Comoejemplo, de una parte de la ACV, el equipo del pro-yecto de software debe demostrar que ha evaluado lafuncionalidad de los componentes del software lizables y que ha considerado su impacto en las deci-siones de arquitectura. La capacidad operativa inicial (COI) es el tercer punto de fijación y representa unconjunto de objetivos asociados a la preparación del softwarepara la preparacióndel lugar previamente a la instalación, y la asistenciaprecisada de todas las partes que utilizará o manten-drá el software.

2.7.4. El modelo de desarrollo concurrente Davis y Sitaram han descrito el modelo dedesarrollo concurrente, llamado algunas veces inge-niería concurrente, de la forma siguiente:

Los gestores de proyectos que siguen los pasos del estadodel proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tienen idea del estado de sus proyec-tos. Estos son ejemplos de un intento por seguir los pasos extre-madamente complejos de actividades mediante modelos demasiado simples. Tenga en cuenta que aunque un proyecto[grande]esté en la fase de codificación, hay personal de ese pro-yecto implicado en actividades asociadas generalmente a muchasfases de desarrollo simultáneamente. Por ejemplo, ... El perso-nal está escribiendo requisitos, diseñando, codificando, hacien-do pruebas y probando la integración [todo al mismo tiempo].Los modelos de procesos de ingeniería del software derey y Kellner han mostrado la concurrenciaque existe para actividades que ocurren durante cualquier fase. El trabajo más reciente de Kellner utiliza diagramasde estado [una notación que representa los estados de un pro-ceso] para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento específico (por ejem-plo: un cambio de requisitos durante el último desarrollo), perofalla en capturar la riqueza de la concurrencia que existe en todas las actividades de desarrollo y de gestión del software en unproyecto...La mayoría de los modelos de procesos de desarro-llo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. [Unmodelo de proceso concurrente] está dirigido por las necesida-

des del usuario, las decisiones de la gestión y los resultados delas revisiones.

El modelo de proceso concurrente se puede repre-sentar en forma de esquema como una serie de acti-vidades técnicas importantes, tareas y estadosasociados a ellas. Por ejemplo, la actividad de inge-niería definida para el modelo en espiral (Sección

se lleva a cabo invocando las tareas siguien-tes: modelado de construcción de prototipos aná-lisis, especificación de requisitos y diseño'.

La Figura 2.10 proporciona una representación esque-mática de una actividad dentro del modelo de procesoconcurrente. La actividad -análisis-se puede encon-trar en uno de los estados'" destacados anteriormente en cualquier momento dado. De forma similar, otras acti-vidades (por ejemplo: diseño o comunicación con elcliente) se puede representar de una forma análoga.Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo, al principio del proyecto la actividad de comunicación con el clien-te (no mostrada en la figura) ha finalizado su primeraiteración y está en el estado de cambios,en espera. Laactividad de análisis (que estaba en el estado ningunomientras que se iniciaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desa-rrollo. Sin embargo, si el cliente indica que se debenhacer cambios en requisitos, la actividad análisis cam-bia del estado bajo desarrollo al estado cambios enespera.

El modelo de proceso concurrente define una seriede acontecimientos que dispararán transiciones deestado a estado para cada una de las actividades de laingeniería del software. Por ejemplo, durante las pri-meras etapas del diseño, no se contempla una incon-sistencia del modelo de análisis. Esto genera lacorrección del modelo de análisis de sucesos, que dis-parará la actividad de análisis del estado hecho alestado cambios en espera.

El modelo de proceso concurrente se utiliza a menu-do comoel paradigma de desarrollode aplicaciones

(Capítulo 28). Un sistemase compone de un conjunto de componentes funciona-les. Cuando se aplica a el modelo de pro-ceso concurrente define actividadesen dos dimensiones

una dimensión de sistemas y una dimensióndecomponentes. Los aspectos del nivel de sistemas se afron-tan mediante tres actividades: diseño, ensamblaje y uso.

9jas que requieren un estudio sustancial. y del libroconsideran estos temas con más detalle.

Un estado es algún modo externamente observable del compor-tamiento.

En funcionalidad del se

tadora más potente) que generalmente mantiene una base de datos centralizada.

27


La dimensión de componentes se afronta con dos activi-dades: diseño y realización. La concurrencia se logra dedos formas: (1) las actividades de sistemasy de compo-nentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente;(2)una aplicación típica se implementa con muchos componentes, cada uno de los cuales se puedendiseñary realizar concurrentemente. En realidad, el mode-lo de proceso concurrentees aplicablea todo tipo de desa-rrollo de software y proporciona una imagen exacta delestado actual de un proyecto.

OReperesenia un estado deuna actividad de del software.

FIGURA 2.10. Un elemento del modelo de proceso concurrente.

Las tecnologías de objetos Parte de este libro) pro-porcionan el marco de trabajo técnico para un modelo de proceso basado en componentes para la ingenieríadel software. El paradigma orientado a objetos za la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar losdatos. Si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basa-dos en computadora.

FIGURA 2.1 Desarrollo basado en componentes.

El modelo de desarrollo basado en componentes (Fig. 2.11) incorpora muchas de las características del mode-lo en espiral. Es evolutivo por naturaleza y exi-ge un enfoque iterativo para la creación del software.Sin embargo, el modelo de desarrollo basado en com-ponentes configura aplicaciones desde componentes pre-parados de software (llamados en la Fig. 2.11).

en lo

un estudio

La actividad de la ingeniería comienza con la iden-tificación de clases candidatas. Esto se lleva a cabo exa-minando los datos que se van a manejar por parte de laaplicación y el algoritmo que se va a aplicar para con-seguir el Los datos y los algoritmos corres-pondientes se empaquetan en una clase.

Las clases creadas en los proyectos de ingeniería delsoftware anteriores, se almacenan en una biblioteca de clases o diccionario de datos (repository) (Capítulo 3Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si estas clases yaexisten. En caso de que así fuera, se extraen de la biblio-teca y se vuelven a utilizar. Si una clase candidata no resi-de en la biblioteca, se aplican los orientadosobjetos (Capítulos 21-23).Se compone así la primera ite-ración de la aplicación a construirse, mediante las clases extraídas de la biblioteca y las clases nuevas construidaspara cumplir necesidades Únicas de la aplicación. Elflujo del proceso vuelve a la espiral y volverá a introdu-cir por último la iteración ensambladora de componen-tes a través de la actividad de ingeniería.

El modelo de desarrollo basado en componentes con-duce a la reutilización del software, y la reutilización pro-porciona beneficios a los ingenieros de software. Según estudios de reutilización, QSM Associates, Inc. informa que el ensamblaje de componentes lleva a una reduccióndel 70 por 100de tiempo de ciclo de desarrollo, un 84por 100del coste del proyecto y un índice de producti-vidad del 26.2, comparado con la norma de industriadel16.9 Aunque estos resultados están en funciónde la robustez de la biblioteca de componentes, no hayduda de que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros de software.

El proceso unificado de desarrollo de softwarerepresenta un número de modelos de desarro-

llo basados en componentes que han sido propuestos en

Esta es una descripción simplificada de definición de clase. Paraun estudio más detallado, consulte el Capítulo 20.

28

2 EL PROCESO

la industria. Utilizando el Lenguaje de Modelado Uni-(UML), el proceso unificado define los

nentes que se utilizarán para construir el sistema y lasinterfacesque conectarán los componentes. Utilizando una combinacion del desarrollo incremental e iterativo,el proceso unificado define la función del sistema apli-cando un enfoque basado en escenarios (desde el

to de vista usuario). Entonces acopla la función con un marco de trabajo arquitectónico que identifica la for-ma que tomará el software.

En los Capítulos 21 y 22 se trata con más detalle.

El modelo de métodos formales comprende un conjun-to de actividades que conducen a la especificación mate-mática del software de computadora. Los métodosformales permiten que un ingeniero de software espe-cifique,desarrolle y verifiqueun sistema basado en com-putadora aplicando una notación rigurosa y matemática.Algunas organizaciones de desarrollo del softwareactualmenteaplican una variación de este enfoque, lla-mado ingeniería del software de sala limpia

l o s métodos formales se tratan en los Capítulos 25 y 26.

Cuando se utilizan métodos formales (Capítulos 25y 26) durante el desarrollo, proporcionan un mecanis-mo para eliminar muchos de los problemas que son difí-ciles de superar con paradigmas de la ingeniería del software. La ambigüedad, lo incompleto y la inconsis-tencia se descubren y se corrigen más fácilmente -nomediante un revisión a propósito para el caso, sino mediante la aplicacióndel análisis matemático-. Cuan-do se utilizan métodos formales durante el diseño, sir-ven como base'para la verificación de programas y por

consiguientepermiten que el ingeniero del software des-cubra y corrija errores que no se pudieron detectar deotra manera.

Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la promesa de unsoftware libre de defectos. Sin embargo, se ha hablado de una gran preocupación sobre su aplicabilidad en unentorno de gestión:

El desarrollo de modelos formales actualmente esbastante caro y lleva mucho tiempo.

2. Se requiere un estudio detallado porque pocos res-ponsables del desarrollo de software tienen los ante-cedentes necesarios para aplicar métodos formales.

3. Es difícil utilizar los modelos como un mecanismode comunicación con clientes que no tienen muchos conocimientos técnicos. No obstante es posible que el enfoque a través de

métodos formales tenga más partidarios entre los desa-rrolladores del software que deben construir softwarede mucha seguridad (por ejemplo: los desarrolladores de aviónica y dispositivos médicos), y entre los desa-rrolladores que pasan grandes penurias económicas al aparecer errores de software.

El término técnicas de cuarta generación abarcaun amplio espectro de herramientas de software que tie-nen algo en común: todas facilitan al ingeniero del soft-ware la especificación de algunas características del softwarea alto nivel. Luego, la herramienta generamáticamente el código fuente basándose en la especifi-cación del técnico. Cada vez parece más evidente quecuanto mayor sea el nivel en el que se especifique elsoftware,más rápido se podrá construir el programa. El paradigma T4G para la ingeniería del software se orien-ta hacia la posibilidad de especificar el software usan-do formas de lenguaje especializado o notacionesgráficas que describa el problema que hay que resolver en términos que los entienda el cliente. Actualmente, un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las

siguientes herramientas: lenguajes no procedimentales de consulta a bases de datos, generación de informes,manejo de datos, interacción y definición de pantallas,generación de códigos, capacidades gráficas de alto nively capacidades de hoja de cálculo, y generación auto-matizada de HTML y lenguajes similaresutilizados para la creación de sitios web usando herramientas de soft-ware avanzado. Inicialmente, muchas de estas herra-mientas estaban disponibles, pero sólo para ámbitos deaplicación muy específicos, pero actualmente los nos T4G se han extendido a todas las categorías de apli-caciones del software.

Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuación, tradu-cidos directamente a un prototipo operativo. Sin

29

DEL SOFTWARE. U N ENFOQUE

go, en la práctica no se puede hacer eso. El cliente pue-de que no esté seguro de lo que necesita; puede ser ambi-guo en la especificaciónde hechos que le son conocidos, y puede que no sea capaz o no esté dispuesto a especi-ficar la información en la forma en que puede aceptar una herramienta Por esta razón, el diálogo clien-te-desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque

utilice tiene quedel

el diseño y /os

Para aplicaciones pequeñas, se puede ir directamen-te desde el paso de recolección de requisitos al paso deimplementación, usando un lenguaje de cuarta genera-ción no procedimental o un modelo comprimi-do de red de iconos gráficos. Sin embargo, es necesarioun mayor esfuerzo para desarrollar una estrategia dediseño para el sistema, incluso si se utiliza un Eluso de T4G sin diseño (para grandes proyectos) causa-rá las mismas dificultades (poca calidad, mantenimien-to pobre, mala aceptación por el cliente) que seencuentran cuando se desarrolla software mediante los enfoques convencionales.

La implementación mediante L4G permite, al quedesarrolla el software, centrarse en la representación delos resultados deseados, que es lo que se traduce máticamente en un código fuente que produce dichosresultados. Obviamente, debe existir una estructura dedatos con información relevante y a la que el L4G pue-da acceder rápidamente.

Para transformar una implementación T4G en unproducto, el que lo desarrolla debe dirigir una prueba completa, desarrollar con sentido una documentacióny ejecutar el resto de las actividades de integración queson también requeridas requeridas por otros mas de ingeniería del software. Además, el softwaredesarrollado con T4G debe ser construido de forma

que facilite la realización del mantenimiento de forma expeditiva.

Al igual que todos los paradigmas del software, elmodelo T4G tiene ventajas e inconvenientes. Los defen-sores aducen reducciones drásticas en el tiempo de desa-rrollo del software y una mejora significativa en laproductividad de la gente que construye el software.Los detractores aducen que las herramientas actualesde T4G no son más fáciles de utilizar que los lenguajes de programación, que el código fuente producido portales herramientas es y que el manteni-miento de grandes sistemas de software desarrollados mediante T4G es cuestionable.

Hay algún mérito en lo que se refiere a indicacionesde ambos lados y es posible resumir el estado actual delos enfoques de

El uso de T4G es un enfoque viable para muchas delas diferentes áreas de aplicación. Junto con las herra-mientas de ingeniería de software asistida por com-putadora (CASE) y los generadores de código, T4Gofrece una solución fiable a muchos problemas delsoftware.

2. Los datos recogidos en compañías que usan T4Gparecen indicar que el tiempo requerido para produ-cir software se reduce mucho para aplicacionespequeñas y de tamaño medio, y que la cantidad deanálisis y diseño para las aplicaciones pequeñas tam-bién se reduce.

3. Sin embargo, el uso de T4G para grandes trabajos dedesarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba (actividades de ingenie-ría del software), para lograr un ahorro sustancial detiempo que puede conseguirse mediante la elimina-ción de la codificación. Resumiendo, las técnicas de cuarta generación ya se

han convertido en una parte importante del desarrollo de software. Cuando se combinan con enfoques deensamblaje de componentes (Sección el paradig-ma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software.

O

Los modelos de procesos tratados en las secciones ante-riores se deben adaptar para utilizarse por el equipo delproyecto del software. Para conseguirlo, se han desarro-llado herramientas de tecnología de procesos para ayudar a organizacionesde softwarea analizar los procesos actua-les, organizar tareas de trabajo, controlar y supervisar el progreso y gestionar la calidad técnica

Las herramientas de tecnología de procesos permi-ten que una organización de software construya unmodelo automatizado del marco de trabajo común deproceso, conjuntos de tareas y actividades de protec-

ción tratadas en la Sección 2.3. El modelo, presentado normalmente como una red, se puede analizar para deter-minar el flujo de trabajo típico y para examinar estruc-turas alternativas de procesos que pudieran llevar a untiempo o coste de desarrollo reducidos.

Una vez que se ha creado un proceso aceptable, se pueden utilizar otras herramientas de tecnología de pro-cesos para asignar, supervisar e incluso controlar todas las tareas de ingeniería del software definidas como par-te del modelo de proceso. Cada uno de los miembros de un equipode proyecto de softwarepuede utilizar tales

30

EL PROCESO

herramientas para desarrollar una lista de control detareas de trabajo a realizarse, productos de trabajo a pro-ducirse, y actividades de garantía de calidad a condu-cirse. La herramienta de tecnología de proceso también

se puede utilizar para coordinar el uso de otras herra-mientas de ingeniería del software asistida por compu-tadora (Capítulo 3 1) adecuadas para una tarea de trabajoen particular.

Y

Si el proceso es débil, el producto final va a sufrir indu-dablemente.Aunque una dependencia obsesiva en elproceso también es peligrosa. En un breve ensayo, garet Davis comenta la dualidad producto yproceso:

Cadadiez años o cinco aproximadamente, la comunidad del soft-warevuelve a definir «el problema» cambiando el foco de los aspec-tos de producto a los aspectos de proceso. Por consiguiente, se han abarcado lenguajes de programación estructurados (producto) segui-dos por métodos de análisis estructurados (proceso) seguidos a suvez por encapsulaciónde datos (producto) y después por el énfasisactual en el Modelo Madurez de Capacidad de Desarrollo del soft-ware del Instituto de ingeniería de software (proceso).

Mientras que la tendencia natural de un péndulo es parar en mediode dos extremos, el enfoque de la comunidad del software cambia constantementeporque se aplica una fuerza nueva cuando falla el

movimiento.Estos movimientos son perjudiciales por sí mis-mos y en sí mismos porque confunden al desarrollador del softwa-re medio cambiando radicalmentelo que significa realizar el trabajo, que por sí mismo lo realiza bien. Los cambios tampoco resuelven «el problema», porque están condenados al fracaso siempre que elproducto y el proceso se traten como si formasen una dicotomía en lugar de una dualidad.

se aplicapuede convertirse] en

En la comunidad científica hay un precedente que se adelanta alas nociones de dualidad cuando contradicciones en observaciones no se pueden explicar completamente con una teoría competitiva uotra. La naturaleza de la luz, que parece ser una partícula y unaonda al mismo tiempo, se ha aceptado desde los años veinte cuan-do Louis de lo propuso. Creo que las observaciones que se hacen sobre los mecanismos del software y su desarrollo demues-tran una dualidad fundamental entre producto y proceso. Nunca se puede comprender el mecanismo completo, su contexto, uso, signi-ficado y valor si se observa sólo como un proceso o sólo como unproducto...

Toda actividad humana puede ser un proceso, pero uno denosotros obtiene el sentido de autoestima ante esas actividades queproducen una representación o ejemplo que más de una persona puede utilizar o apreciar, una u otra vez, o en algún otro contexto no tenido en cuenta. Es decir, los sentimientos de satisfacción seobtienen por volver a utilizar nuestros productos por nosotros mis-mos o por otros.

Así pues, mientras que la asimilación rápida de los objetivosde reutilización en el desarrollo del software aumenta potencial-mente la satisfacción que los desarrolladores obtienen de su tra-bajo, esto incrementa la urgencia de aceptar la dualidad productoy proceso. Pensar en un mecanismo reutilizable como el único producto o el único proceso, bien oscurece el contexto y la formade utilizarlo, o bien el hecho de que cada utilización elabora elproducto que a su vez se utilizará como entrada en alguna otra actividad de desarrollo del software. Elegir un método sobre otro reduce enormemente las oportunidades de reutilización y de aquíque se pierda la oportunidad de aumentar la satisfacción ante eltrabajo.

Las personas obtienen tanta satisfacción (omás) del proceso creativo que del producto final. Un artista dis-fruta con las pinceladas de la misma forma que disfru-ta del resultado enmarcado. Un escritor disfruta con labúsqueda de la metáfora adecuada al igual que con ellibro final. Un profesional creativo del software debe-ría también obtener tanta satisfacción de la programa-ción como del producto final.

El trabajo de los profesionales del software cambia-rá en los próximos años. La dualidad de producto y pro-ceso es un elemento importante para mantener ocupada a la gente hasta que se finalice la transición dela programación a la ingeniería del software.

La ingeniería del software es una disciplina que inte-gra procesos, métodos y herramientas para el desa-rrollo del software de computadora. Se han propuestovarios modelos de procesos para la ingeniería del soft-ware diferentes, cada uno exhibiendo ventajas e incon-

venientes, pero todos tienen una serie de fases gené-ricas en común. En el resto de este libro se consideranlos principios, conceptos y métodos que permiten lle-var a cabo el proceso que se llama ingeniería del soft-ware.

31

DEL SOFTWARE. U N ENFOQUE PRÁCTICO

Baetjer, H., Jr., Software as Capital,IEEEter Society Press, 1998, 85.

Bandinelli, et al, and Improving anIndustrial Software IEEE Software Engi-neering, vol. 2 5 , Mayo 1995, pp. 440-454.

Bradac, M., y Votta, aIEEE Trans. Software Engi-

neering, vol. 20, 10, Octubre 1994, pp. 774-784.Boehm, Spiral Model for Software

pement and Enhancement",Computer,vol. 21, 5 , Mayo

Boehm, the Software IEEESoftware, vol. 13, 4, Julio 1996, pp.73-82.

Boehm, the WINWIN Spiral Model: ACase Computer,vol. 31, 7, Julio 1998, pp. 44.

Brooks, The Man-Month,ley, 1975.

Butler, Aplication Developement Managing Developement, Applied

puter Research, vol. 14, 5 , Mayo 1995, pp. 6-8.Davis, A., y Sitaram, «A Concurrent Process

Model for Software Softwarering Notes, ACM Press, vol. 19, 2, Abril 1994, pp. 51.

Davis, M.J., and Product: Dichotomy or Software Engineering Notes, ACM Press, vol.

20, 2, Abril 1995, pp. 17-18.Donaldson,M.C., y M. Donaldson,Negotiatingfor

IDB Books Worldwide, 1996. Dyer, M., The Cleanroom to

ware Developement, 1992.Farber, Sense Negotiation: The Art

of Winning Gracefully,Bay Press, 1997. Fisher, W. Ury y Bruce Patton, Getting to Yes:

Negotiating Without Giving 2." ed., Penguin USA, 1991.

Gilb, T., of Software Engineering gement, Addison-Wesley, 1988.

Hanna, M., to SoftwareMagazine, Mayo 1995, pp.38-46.

Humphrey, W., y M. Kellner, «Software Process Modeling: Principles of Entity Process Proc.

1988, 61-72.

Intl. Conference on Software Engineering, IEEEputer Society Press, pp. 331-342.

IEEE Standards Collection: Engineering,IEEE Standard 610.12-1990, IEEE, 1993.

Jacobson, I., G. Booch y Rumbaugh, TheSoftware Developement Addison-Wesley, 1999.

Kellner, M., Software Process Modeling: andExperience, Technical Review-1989,SEI, Pittsburgh,PA, 1989.

Kellner, M., «Software Process Modeling Support for Management Planning and Control», Proc. Intl.

On the Process, IEEE Computer Society Press, 1991, pp. 8-28.

Kerr, y Hunter, 1994.Martin, Rapid Aplication Developement,

tice-Hall, 1991. y Rook, «Software Developement

Process en Book,CRC Press, 1993, pp.

H.D., M. Dyer y Soft-ware IEEE Software, Septiembre 1987, pp.

Naur, y (eds.), Engineering:A Report on a Conference the NATOce NATO, 1969.

Nierstrasz, Software Deve-CACM, vol. 35, 9, Septiembre 1992, pp.

Paulk, M., et al., Maturity Model forSoftware», Software Engineering Institute, Carnegie

University, Pittsburgh, PA, 1993.Raccoon, Chaos Model and the Chaos

Life ACM Software Engineering Notes, vol. 20, 1, Enero 1995, pp. 55-66.

Royce,W.W., the Developement of LargeSoftware Systems: Concepts and Proc.CON,Agosto 1970.

Sheleg, W., Engineering: A Newdign for C/S Application Developement Trends, vol. 1, 6, Junio 1994, pp. 28-33.

Yourdon, E., «Software Application Deve-Strategies, vol. VI, 12, Diciembre 1994, pp.

19-25.

160-165.

1-16.

2.1. La Figura 2.1 sitúa las tres capas de ingeniería del soft-ware encima de la capa titulada «enfoque de calidad». Esto implica un programa de calidad tal como Gestión de Cali-dad Total. Investigue y desarrolle un esquema de los prin-

clave de un programa de Gestión de Calidad Total.

2.2. algún caso en que no se apliquen fases genéricasdel proceso de ingeniería del software? Si es así, descríbalo. 2.3. El Modelo Avanzado de Capacidad del es un docu-mento en evolución. Investigue y determine si se han aña-dido algunas ACP nuevas desde la publicación de este libro.

32

2 EL PROCESO

2.4. El modelo del caos sugiere que un bucle de resolución deproblemas se pueda aplicar en cualquier grado de resolución.Estudie la forma en que se aplicaría el bucle para com-prender los requisitos de un producto de tratamiento de texto;(2) para desarrollarun componente de corrección ortográfica y gramática avanzado para el procesador de texto; (3) para generar el código para un módulo de programa que determi-ne el sujeto, predicado y objeto de una oración en inglés.2.5. paradigmasde ingeniería del software de los presen-tados en estecapítulopiensa que sería el más eficaz? qué?2.6. Proporcione cinco ejemplos de proyectos de desarrollodel software que sean adecuados para construir prototipos. Nombre dos o tres aplicaciones que fueran más difíciles paraconstruirprototipos.2.7. El modelo DRA a menudo se une a herramientas CASE. Investiguela literatura y proporcione un resumen de una herra-mienta típica CASE que soporte DRA.

2.8. Proponga un proyecto específico de software que sea ade-cuado para el modelo incremental. Presente un escenario para aplicar el modelo al software.2.9. A medida que vaya hacia afuera por el modelo en espiral,

puede decir del software que se está desarrollando o man-teniendo?2.10. Muchas personas creen que la Única forma en la que sevan a lograr mejoras de magnitud en la calidad del software yen su productividad es a través del desarrollo basado en com-ponentes. Encuentre tres o cuatro artículos recientes sobre elasunto y resúmalos para la clase. 2.11. Describa el modelo de desarrollo concurrente con sus propias palabras. 2.12. Proporcione tres ejemplos de técnicas de cuarta genera-ción.2.13. es más importante, el producto o el proceso?

El estadoactual del arte en la ingeniería del software se puede mejora partir de publicaciones mensuales tales como

IEEE Software, Computer e IEEE Transactions on SoftwareEngineering.Periódicos sobre la industria tales como tionDevelopement Trends,CutterIT Journal y Softwarelopement a menudo contienen artículos sobre temas de ingenieríadel software.La disciplina se «resume» cada año en eleding the International Conference on Software Engineering,promocionadopor el IEEE y ACM y tratado en profundidad en periódicos como ACM Transactions Software Engineeringand Methodology,ACM Software Engineering Notes y

Software Engineering.Se han publicado muchos libros de ingeniería del softwa-

re en los últimos años. Algunos presentan una visión general del proceso entero mientras que otros se dedican a unos pocos temas importantes para la exclusión de otros. Las siguientesson tres antologías que abarcan algunos temas importantes de ingeniería del software:

Keyes, (ed.), Engineering Productivitybook, 1993.

(ed.), Software Reference Book,CRC Press, 1993.

Marchiniak, J.J. (ed.), Encyclopedia Softwareering,Wiley, 1994.

Gautier (Distributed Engineering Software,Hall, 1996)proporciona sugerencias y directrices para orga-nizaciones que deban desarrollar software en lugaresgeográficamentedistantes.

En la parte más brillante del libro de Robert Glass (Soft-ware Yourdon Press, 1991) se presentan ensayos

controvertidos y amenos sobre el software y el proceso de laingeniería del software. Pressman y Herron (SoftwareShock,Dorset House, 1991) consideran el software y su impactosobre particulares, empresas y el gobierno.

El Instituto de ingeniería del software localizado enla Universidad de Carnegie-Mellon) ha sido creado con la responsabilidad de promocionar series monográficas sobre la ingeniería del software. Los profesionales académicos,en la industria y el gobierno están contribuyendo con nue-vos trabajos importantes. El Consorcio de Productividad delSoftware dirige una investigación adicional de ingenieríade software.

En la última década se ha publicado una gran variedad deestándares y procedimientos de ingenieríadel software.El IEEESoftware Engineering Standards contiene muchos estándares diferentes que abarcan casi todos los aspectos importantes dela tecnología. Las directrices ISO 9000-3 proporcionan una guía para las organizaciones de software que requieren un regis-tro en el de calidad ISO 9001. Otros estándares deingeniería del software se pueden obtener desde el MOD, laAutoridad Civil de Aviación y otras agencias del gobierno ysin ánimo de lucro. Fairclough (SoftwareEngineering Guides,Prentice-Hall, 1996) proporciona una referencia detallada delos estándares de ingeniería del software producidos por pean Space Agency (ESA).

En internet se dispone de una gran variedad de fuentes deinformación sobre la ingeniería del software y del proceso desoftware. Se puede encontrar una lista actualizada con refe-rencias a sitios (páginas) web que son relevantes para el pro-ceso del software en http://www.pressman5.com.

33

PARTE

I I DE PROYECTOS

DE SOFTWARE

U n enfoque Práctico, estudiamosorganizar, supervisar

vienen a

ema durante unde software?

y cómo pueden emplearse paranar un proyecto

costes y duración del proyecto?

e y el proceso del software?genera e software estimaciones fiablesdel esfuerzo,

35

CONCEPTOS SOBRE GESTIONDE PROYECTOS

N el prefacio de su libro sobre gestión de proyectos de software, Meiler Page-Jonesdice una frase que pueden corroborar muchos asesores de ingeniería del soft-

ware:He visitado docenas de empresas, buenas y malas, y he observado a muchos administradores de

so de datos, también buenos y malos. Frecuentemente, he visto con horror cómo estos administradores lucha-ban inútilmente contra proyectos de pesadilla, sufriendo por fechas límite imposibles de cumplir, o queentregaban sistemas que decepcionaban a sus usuarios y que devoraban ingentes cantidades de horas demantenimiento.

ELo que describe Page-Jones son síntomas que resultan de una serie de problemas técnicos y

de gestión. Sin embargo, si se hiciera una autopsia de cada proyecto, es muy probable que seencontrara un denominador común constante: una débil gestión.

En este capítulo y en los seis que siguen consideraremos los conceptos clave que llevan auna gestión efectiva de proyectos de software. Este capítulo trata conceptos y principios bási-cos sobre gestión de proyectos de software. El Capítulo 4 presenta las métricas del proyecto ydel proceso, la base para una toma de decisiones de gestión efectivas. Las técnicas que se emple-an para estimar los costes y requisitos de recursos y poder establecer un plan efectivo del pro-yecto se estudian en el Capítulo 5. Las actividades de gestión que llevan a una correctasupervisión, reducción y gestión del riesgo se presentan en el Capítulo 6. El Capítulo 7 estudialas actividades necesarias para definir las tareas de un proyecto y establecer una programación del proyecto realista. Finalmente, los Capítulos 8 y 9 consideran técnicas para asegurar la cali-dad a medida que se dirige un proyecto y el control de los cambios a lo largo de la vida de unaaplicación.

tomamos la visión defalta una

necesaria cuando sesoftware de com

plan define el proceso y las tareas arealizar el personal que el

y losmecanismos para evaluar losy control del perso de los eventos que

puedo seguro de quehecho

estás completamente segurode que

Ytécnicas. Losgestores d

el alcance del producto y los requisi-tos. Debe seleccionarse el procesoadecuado para el personal, y el pro-

El proyecto debe planificarse

para cumplir las tareas; definiendolos productos del trabajo, estable-

alta calidad dentro del tiempo y delpresupuesto. Sin embargo, un gestorde proyectos hace lo correcto cuandoestimulaa l personal para trabajar

do su atención en las necesidades delcliente y en la calidad del producto.

Y estimando el esfuerzo y el tiempo tos como un equipo efectivo, centran-

37


La gestión eficaz de un proyecto de software se cen-tra en las cuatro P’s: personal, producto, proceso yproyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software esun esfuerzo humano intenso nunca tendrá éxito en lagestión de proyectos. Un gestor que no fomenta unaminuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construiruna elegante solución para un problema equivocado. El administrador que presta poca atención al proce-so corre el riesgo de arrojar métodos técnicos y herra-mientas eficaces al vacío. El gestor que emprende unproyecto sin un plan sólido arriesga el éxito del pro-ducto.

3.1.1. PersonalLa necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60 (por ejemplo,

De hecho, el humano» es tanimportante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad

gestión de personal (MMCGP) aumentar lapreparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayu-dando a atraer, aumentar, motivar, desplegar y retenerel talento necesario para mejorar su capacidad de desa-rrollo de software»

El modelo de madurez de gestión de personal defi-ne las siguientes áreas clave prácticas para el personalque desarrolla software: reclutamiento, selección, ges-tión de rendimiento, entrenamiento, retribución, desa-rrollo de la carrera, diseño de la organización y deltrabajo y desarrollo cultural y de espíritu de equipo.

El MMCGP es compañero del modelo de madurezde la capacidad software (Capítulo 2), que guía a lasorganizaciones en la creación de un proceso de softwaremaduro. Más adelante en este capítulo se consideranaspectos asociados a la gestión de personal y estructu-ras para proyectos de software.

3.1.2. ProductoAntes de poder planificar un proyecto, se deberían esta-blecer los objetivos y el ámbito del producto‘, se debe-rían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información,es imposible definir unas estimaciones razonables (yexactas) del coste; una valoración efectiva del riesgo,una subdivisión realista de las tareas del proyecto o unaplanificación del proyecto asequible que proporcioneuna indicación fiable del progreso.

En 1 se una taxonomía de lasde producen los de software.

El desarrollador de softwarey el cliente deben reunir-se para definir los objetivos del producto y su ámbito.Enmuchos casos, esta actividad empieza comoparte del pro-ceso de ingenieríadel sistema o del negocio (Capítulo y continúacomo el primer paso en el análisis de los requi-sitos del software (Capítulo 11).Los objetivos identifican las metas generales del proyecto sin considerar cómo seconseguirán (desde el punto de vista del cliente).

El ámbito identifica los datos primarios, funciones ycomportamientos que caracterizan al producto, y, másimportante, intenta abordar estas características de unamanera cuantitativa.

Una vez que se han entendidolos objetivosy el ámbi-to del producto, se consideran soluciones alternativas.

3.1.3. ProcesoUn proceso de software (Capítulo 2) proporciona laestructura desde la que se puede establecer un detalla-do plan para el desarrollo del software. Un pequeñonúmero de actividades estructurales se puede aplicar atodos los proyectos de software, sin tener en cuenta sutamaño o complejidad. Diferentes conjuntos de tareas-tareas,hitos, productos del trabajo y puntos de garan-tía de calidad-permiten a las actividades estructura-les adaptarse a las características del proyecto desoftwarey a los requisitos del equipodel proyecto. Final-mente, las actividades protectoras -talescomo garan-tía de calidad del software, gestión de la configuración del software y medición-cubren el modelo de proce-so. Las actividades protectoras son independientes delas estructurales y tienen lugar a lo largo del proceso.

En este contexto, el termino es usado para abarcar cual-quier software que será construido a petición de otros. Esto incluye no sólo productos de software, también sistemas basados encomputadora, software empotrado y software de resolución de pro-blemas (por ejemplo, programas para la resolución de problemas

ingeniería).

38

3 C O N C E P T O S S O B R E D E P R O Y E C T O S

c VElas actividades estructurales se componende tareas, hitos,productos de y puntos de de calidad.

3.1.4. ProyectoDirigimos los proyectos de software planificados y con-trolados por una razón principal -es la Única maneraconocida de gestionar la complejidad-. Y todavíaseguimosesforzándonos. En 1998,los datos de la indus-tria del software indicaron que el 26 por 100 de pro-yectos de software fallaron completamente y que el 46

por 100 experimentaron un desbordamiento en la pla-nificación y en el coste Aunque la proporción de éxito para los proyectos de software ha mejorado unpoco, nuestra proporción de fracaso de proyecto per-manece más alto del que debería

Para evitar el fracaso del proyecto, un gestor de pro-yectos de software y los ingenieros de software queconstruyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factoresdel éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto. Cada uno de estos aspectos se trata en la Sección 3.5 y en loscapítulos siguientes.

En un estudio publicado por el IEEE se lespreguntó a los vicepresidentes ingenieros de tres gran-des compañías tecnológicas sobre el factor más impor-tante que contribuye al éxito de un proyecto de software.Respondieron de la siguiente manera:

VP 1: Supongo que si tuviera que elegir lo más importante de nuestro entorno de trabajo, diría que no son lasherramientas que empleamos, es la gente.

VP 2: El ingrediente más importante que contribuyó éxi-to de este proyecto fue tener gente lista ...pocas cosasmás importan en mi opinión ...Lo más importante que se puede hacer por un proyecto es seleccionar el personal ...El éxito de la organización de desarrollodel software está muy, muy asociado con la habili-dad de reclutar buenos profesionales.

VP 3: La única regla que tengo en cuanto a la gestiónes asegurarme de que tengo buenos profesionales -genterealmente buena-, de que preparo bue-na gente y de que proporciono el entorno en el que los buenos profesionales puedan producir.

Ciertamente, éste es un testimonio convincente sobre la importanciadel personal en el proceso de ingenieríadel software.Y, sin embargo, todos nosotros, desde los veteranos vicepresidentes al más modesto profesional

del software, damos este aspecto por descontado. Losgestores argumentan (como el grupo anterior) que el personal es algo primario, pero los hechos desmienten a veces sus palabras.

En esta sección examinamoslos participantes quecola-boran en el proceso del software y la manera en que seorganizan para realizar una ingeniería del Softwareeficaz.

3.2.1. Los participantesEl proceso del software (y todos los proyectos de soft-ware) lo componen participantes que pueden clasificarseen una de estas cinco categorías: 1.

2.

3.

4.

5.

Gestores superiores, que definen los aspectos denegocios que a menudo tienen una significativainfluencia en el proyecto.Gestores (técnicos)del proyecto, que deben planifi-car, motivar, organizar y controlar a los profesiona-les que realizan el trabajo de software.Profesionales, que proporcionan las capacidades téc-nicas necesarias para la ingeniería de un producto oaplicación.Clientes,que especifican los requisitos para la inge-niería del software y otros elementos que tienenmenor influencia en el resultado. Usuarios que interaccionan con el software una vez que se ha entregado para la producción.Para ser eficaz,el equipo del proyecto debe organizarse

de manera que maximice las y capacidadesde cada persona. Y este es el trabajo del jefe del equipo.

Dadas estas estadísticas, es razonable preguntarse cómo el impactode las computadorascontinúa creciendo exponencialmente y la indus-tria del software continúa anunciando el crecimiento de ventas al doble.Parte de respuesta, pienso, es que un importante número de estosproyectos están mal concebidos desde el primer momento.Los clientes pierden el interés rápidamente (puesto que lo que ellos pidieron realmente no era tan importante comoellos habían pensado),y los proyectos son cancelados.

39


3.2.2. Los jefes de equipoLa gestión de un proyectoes una actividad intensamentehumana, y por esta razón, los profesionales competen-tes del software a menudo no son buenos jefes de equi-po. Simplemente no tienen la mezcla adecuada decapacidades del personal. Y sin embargo, como diceEdgemon: «Desafortunadamente y con demasiada fre-cuencia, hay individuos que terminan en la gestión deproyectos y se convierten en gestores de proyecto acci-dentales»

qué nos fijamos cuandoseleccionamos a alguien para

conducir un proyecto de software?

En un excelente libro sobre gestión técnica, Jerry Weinberg sugiere el modelo de gestión MOI:

Motivación.La habilidad para motivar (con un y aflo-ja») personal técnico para queproduzca a sus mejo-res capacidades.

Organización. La habilidad para amoldar procesos exis-tentes (oinventar unos nuevos) que permita al concepto inicialtransformarse en un producto

Ideas o innovación.La habilidad para motivar al personalpara crear y sentirse creativos incluso cuando deban de traba-jar dentro de los límites establecidos para un producto o apli-cación de software particular.

Weinberg sugiere que el éxito de los gestores de pro-yecto se basa en aplicar un estilo de gestión en la reso-lución de problemas. Es decir, un gestor de proyectos desoftware debería concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, almismo tiempo, haciendo saber a todos los miembros delequipo (mediante palabras y, mucho más importante,con hechos) que la calidad es importante y que no debeverse comprometida.

Otro punto de vista de las características que definen a un gestor de proyectos eficiente resalta cuatro apartados clave:

Resolución del problema. Un gestor eficiente de un pro-yecto de software puede diagnosticar los aspectos técnicos y de organización más relevantes, estructurar una soluciónmáticamente o motivar apropiadamente a otros profesionales para que desarrollen la solución, aplicar las lecciones aprendi-das de anteriores proyectos a las nuevas situaciones, mante-nerse lo suficientemente flexible para cambiar la gestión si los intentos iniciales de resolver el problema no dan resultado.

Dotes de gestión.Un buen gestor de proyectos debe tomar las riendas. Debe tener confianza para asumir el control cuan-do sea necesario y garantía para permitir que los buenos téc-nicos sigan sus instintos.

Incentivospor logros. Para optimizar la productividad deun equipo de proyecto, un gestor debe recompensar la inicia-tiva y los logros, y demostrar a través de sus propias acciones que no se penalizará si se corren riesgos controlados.

Influencia y construcciónde espíritude equipo. Un ges-tor de proyecto eficiente debe ser capaz de a la gente;debe ser capaz de entender señales verbales y no verbales yreaccionar ante las necesidades de las personas que mandanesas señales. El gestor debe mantener el control en situacionesde gran estrés.

Un experto de puede no tenerdeseo de ser jefe de equipo. fuerce experto poro seruno de ellos.

3.2.3. El equipo de softwareExisten casi tantas estructuras de organizaciónde perso-nal para el desarrollo de software como organizacionesque se dedican a ello. Para bien o para mal, el organi-grama no puede cambiarse fácilmente. Las consecuen-cias prácticas y políticas de un cambio de organizaciónno están dentro del alcance de las responsabilidades delgestor de un proyecto de software. Sin embargo, la orga-nización del personal directamente involucrado en unnuevo proyecto de software está dentro del ámbito delgestor del proyecto.

Las siguientes opciones pueden aplicarse a los recur-sos humanos de un proyecto que requiere n personastrabajando durante k años:1.

2.

3.

n individuos son asignados a m diferentes tareas fun-cionales, tiene lugar relativamente poco trabajo con-junto; la coordinación es responsabilidad del gestordel software que puede que tenga otros seis proyec-tos de los que preocuparse.

individuos son asignados a m diferentes tareas fun-cionales de manera que se establecen «equi-p o s ~informales; se puede nombrar un líder al efecto; la coordinación entre los equipos es responsabilidadde un gestor del software. n individuos se organizan en t equipos; a cada equipose le asignan una o más tareas funcionales; cadaequipo tiene una estructura específica que se definepara todos los equipos que trabajan en el proyecto; la coordinación es controlada por el equipo y por elgestor del proyecto de software.Aunque es posible encontrar argumentos en pro y en

contra para cada uno de los enfoques anteriores, existe

40

3 CONCEPTOS SOBRE DE PROYECTOS

una gran evidencia que indica que una organización deequipo formal (opción 3) es la más productiva.

La «mejor» estructura de equipo depende del esti-lo de gestión de una organización, el número de per-sonas que compondrá el equipo, sus niveles depreparación y la dificultad general del problema. Man-tei sugiere tres organigramas de equipogenéricos:

Descentralizado democrático Este equipo deingeniería del software no tiene un jefe permanente. Másbien, nombran coordinadores de tareas a corto plazo yse sustituyen por otros para diferentes Las

sobre problemas y los enfoques se hacen por con-senso del grupo. La comunicación entre los miembros delequipo es horizontal.

debería estar organizadoun equipo

de software?

Descentralizado controlado (DC). Este equipo de inge-niería del software tiene un jefe definido que coordina tare-as específicas y jefes secundarios que tienen responsabilidadessobre subtareas. La resolución de problemas sigue siendo una actividad del grupo, pero la implementación de solu-ciones se reparte entre subgrupos por el jefe de equipo. Lacomunicación entre subgrupos e individuos es horizontal.También hay comunicación vertical a lo largo de la jerarquía de control.

Centralizado controlado (CC). El jefe del equipo seencarga de la resolución de problemas a alto nivel y la coor-dinación interna del equipo. La comunicación entre el jefe ylos miembros del equipo es vertical.

Mantei describe siete factores de un pro-yecto que deberían considerarse cuando se planifica elorganigrama de equipos de ingeniería del software:

la dificultad del problema que hay que resolverel tamaño del líneas decódigo o puntos de función (Capítulo 4)el tiempo que el equipo estará junto (tiempo de vidadel equipo)el grado en que el problema puede ser zado

factoresdeberíamos considerar

cuando estructuramosun equipo de software?

la calidad requerida y fiabilidad del sistema que seva a construirla rigidez de la fecha de entregael grado de sociabilidad (comunicación) requeridopara el proyectoDebido a que una estructura centralizada realiza las

tareas más rápidamente, es la más adecuada para mane-

jar problemas sencillos. Los equipos descentralizados generan más y mejores soluciones que los individua-les. Por tanto, estos equipos tienen más probabilidades de éxito en la resolución de problemas complejos. Pues-to que el equipo DC es centralizado para la resoluciónde problemas, tanto el organigrama de equipo DC comoel de CC pueden aplicarse con éxito para problemassencillos. La estructura DD es la mejor para problemas difíciles.

Como el rendimiento de un equipo es inversamenteproporcional a la cantidad de comunicación que se debeentablar, los proyectos muy grandes son mejor dirigi-dos por equipos con estructura CC o DC, donde se pue-den formar fácilmente subgrupos.

El tiempo que los miembros del equipo vayan a juntos» afecta a la moral del equipo. Se ha des-

cubierto que los organigramas de equipo tipo DD pro-ducen una moral más alta y más satisfacción por el trabajo y son, por tanto, buenos para equipos que per-manecerán juntos durante mucho tiempo.

El organigrama de equipo DD se aplica mejor a pro-blemas con modularidad relativamente baja, debido a la gran cantidad de comunicación que se necesita. Los organigramas CC o DC funcionan bien cuando es posi-ble una modularidad alta (y la gente puede hacer cadauno lo suyo).

Frecuentementees mejor tener pocos equipos pequeños,bien centrados que un gran equipo solamente.

Los equipos CC y DC producen menos defectos quelos equipos DD, pero estos datos tienen mucho que vercon las actividades específicas de garantía de calidadque aplica el equipo. Los equipos descentralizados requieren generalmente más tiempo para completar unproyecto que un organigrama centralizado y al mismotiempo son mejores cuando se precisa una gran canti-dad de comunicación.

Constantine sugiere cuatro de organización» para equipos de ingeniería del soft-ware:1. Un paradigma cerrado estructura a un equipo con

una jerarquía tradicional de autoridad (similar al equipo CC). Estos equipos trabajan bien cuando pro-ducen software similar a otros anteriores, pero pro-bablemente sean menos innovadores cuando trabajen dentro de un paradigma cerrado.

2. El paradigma aleatorio estructura al equipo libre-mente y depende de la iniciativa individual de losmiembros del equipo. Cuando se requiere innova-ción o avances tecnológicos, los equipos de para-digma aleatorio son excelentes. Pero estos equipospueden chocar cuando se requiere un «rendimientoordenado».

41

DEL SOFTWARE. U N ENFOQUE

3. El paradigma abierto intenta estructurar a un equipode manera que consiga algunos de los controles aso-ciados con el paradigma cerrado, pero también mucha de la innovación que tiene lugar cuando seutiliza el paradigma aleatorio. El trabajo se desa-rrolla en colaboración, con mucha comunicación ytoma de decisiones consensuadas y con el sello delos equipos de paradigma abierto. Los organigra-mas de equipo de paradigma abierto son adecuadospara la resolución de problemas complejos, pero pueden no tener un rendimiento tan eficiente comootros equipos.

4.El paradigma se basa en lamentación natural de un problema y organiza losmiembros del equipo para trabajar en partes del pro-blema con poca comunicación activa entre ellos. Constantine propone una variación en el

equipo descentralizado democrático defendiendo a losequipos con independencia cuyo enfoque de trabajo podría ser mejor llamado «anarquía innova-dora». Aunque se haya apelado al enfoque de libreespíritu para el desarrollo del software, el objetivoprincipal de una organización de Ingeniería del Soft-ware debe ser «convertir el caos en un equipo de alto rendimiento» Para conseguir un equipo de alto rendimiento.

Los miembros del equipo deben confiar unos enotros.La distribución de habilidades debe adecuarse al pro-blema.Para mantener la unión del equipo, los tas tienen que ser excluidos del mismoCualquiera que sea la organización del equipo, el

objetivo para todos los gestores de proyecto es colabo-rar a crear un equipo que presente cohesión. En su libro,Peopfeware,DeMarco y Lister estudian este aspecto:

Elpapel del existesin tener en cuentolo estructura del equipo. Poro más detallesel 9.

Tendemos a usar la palabra equipo demasiado libre-mente en el mundo de los negocios, denominando «equi-po» a cualquier grupo de gente asignado para trabajar junta.Pero muchos de estos grupos no parecen equipos. No tie-

nen una definición común de éxito o un espíritu de equi-po identificable. Lo que falta es un fenómeno que deno-minamos cuajar.

Un equipo cuajado es un grupo de gente tejido tan fuer-temente que el todo es mayor que la suma de las partes ...

Una vez que el equipo empieza a cuajar, la probabilidadde éxito empieza a subir. El equipo puede convertirse enimparable, un monstruo de éxito ... No necesitan ser dirigi-dos de una manera tradicional y no necesitan que se les moti-ve. Están en su gran momento.

DeMarco y Lister mantienen que los miembros de equipos cuajados son significativamente más pro-ductivos y están más motivados que la media. Com-parten una meta común, una cultura común y, enmuchos casos, un «sentimiento que les haceúnicos.

Pero no todos los equipos cuajan. De hecho, muchos equipos sufren lo que Jackman llama «toxicidadde equi-po» define cinco factores que «fomentan unentorno de equipo tóxico potencial»:

1.

2.

3.

4.

5.

una atmósfera de trabajo frenética en la que losmiembros del equipo gastan energía y se descentran de los objetivos del trabajo a desarrollar;alta frustración causada por factores tecnológicos,del negocio, o personalesque provocan fricción entrelos miembros del equipo; «procedimientos coordinados pobremente o frag-mentados» o una definición pobre o impropiamenteelegida del modelo de procesos que se convierte enun obstáculo a saltar;definición confusa de los papeles a desempeñar pro-duciendo una falta de responsabilidad y la acusacióncorrespondiente, y«continua y repetida exposición al fallo» que con-duce a una pérdida de confianza y a una caída de lamoral.Jackman sugiere varios antitóxicos que tratan los

problemas destacadosPara evitar un entorno de trabajo frenético, el

gestor de proyectos debería estar seguro de que elequipo tiene acceso a toda la información requerida para hacer el trabajo y que los objetivos y metas prin-cipales, una vez definidos, no deberían modificarse a menos que fuese absolutamente necesario. Además, las malas noticias no deberían guardarse en secreto, sino entregarse al equipo tan pronto como fuese posi-ble (mientras haya tiempo para reaccionar de un modoracional y controlado).

42


los equipos son lo pero no esconseguirlos.Como mínimo, esté seguro de un

Aunque la frustración tiene muchas causas, los desa-rrolladoresde software a menudo la sienten cuando pier-den la autoridad para controlar la situación. Un equipode software puede evitar la frustración si recibe tanta responsabilidad para la toma de decisiones como sea posible. Cuanto más control se le de al equipopara tomardecisiones técnicas y del proceso, menos frustración sentiran los miembros del equipo.

Una elección inapropiada del proceso del software(p.ej., tareas innecesarias o pesadas, pobre elección delos productos del trabajo) puede ser evitada de dos for-mas: (1) estando seguros de que las características del softwarea construir se ajustan al rigor del proceso ele-gido, y (2) permitiendo al equipo seleccionar el proce-so (con el reconocimiento completo de que, una vez elegido, el equipo tiene la responsabilidad de entregar un producto de alta calidad).

El gestor de proyectos de software, trabajando junto con el equipo, debería refinar claramente los roles y las responsabilidades antes del comienzo del proyec-to. El equipo debería establecer su propios mecanismos para la responsabilidad (las revisiones técnicas

son una forma para realizar esto) y definir una seriede enfoques correctivos cuando un miembro del equi-po falla en el desarrollo.

Todoequipo de software experimentapequeños fallos. La clave para eliminar una atmósfera de fallos será esta-blecer técnicas basadas en el equipo para retroalimentar y solucionar el problema. Además, cualquier fallo de unmiembro del equipo debe ser considerado como un fallodel equipo. Esto lleva a un acercamiento del equipo a laacción correctiva, en lugar de culpar y desconfiar, queocurre con rapidez en equipos tóxicos.

debemos evitar«toxinas» que con frecuencia

infectan un equipo de software?

Además de las cinco toxinas descritas por Jackman, un equipo de software a menudo se enfrenta con los ras-gos humanos diferentes de sus miembros. Algunosmiembros del equipo son extrovertidos, otros son vertidos.Algunas personas recogen información tivamente, separando amplios conceptos de hechosdispares. Otros procesan la información linealmente, reuniendo y organizando detalles minuciosos de losdatos proporcionados. Algunos miembros del equipo toman las decisiones apropiadas solamente cuando se

Las revisiones técnicas formales se tratan con detalle en el Capi-tulo 8.

presenta un argumento lógico, de un modo ordenado.Otros son intuitivos, pudiendo tomar una decisión basán-dose en sus «sensaciones». Algunos desarrolladorespre-fieren una planificación detallada compuesta por tareas organizadas que les permita lograr el cierre para algún elemento de un proyecto. Otros prefieren un entornomás espontáneo donde aspectos abiertos son correctos. Algunos trabajan duro para tener las cosas hechas muchoantes de la fecha de un hito, de ese modo eliminan lapresión cuando se aproximan a las fechas, mientras queotros están apurados por las prisas para hacer la entre-ga en el Último minuto. Un estudio detallado de la psi-cología de estos rasgos y de las formas en las que unjefe de equipo cualificado puede ayudar a la gente conrasgos opuestos para trabajar juntos está fuera del ámbi-to de éste libro4. Sin embargo, es importante destacar que el reconocimiento de las diferencias humanas es elprimer paso hacia la creación de equipos que cuajan.

3.2.4. Aspectos sobre la coordinación

Hay muchos motivos por los que los proyectos de soft-ware pueden tener problemas. La escala (tamaño) de muchos esfuerzos de desarrollo es grande, conduciendo a complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo. La incerti-dumbre es corriente, dando como resultado un continuoflujo de cambios que impactan al equipo del proyecto.La interoperatividad se ha convertido en una caracterís-tica clave de muchos sistemas. El software nuevo debe comunicarse con el anterior y ajustarse a restriccionespredefinidas impuestas por el sistema o el producto.

y la comunicación

Estas características del software moderno la, incertidumbre e interoperatividad-son aspectos dela vida. Para enfrentarse a ellos eficazmente, un equi-po de ingeniería del software debe establecer métodos efectivos para coordinar a la gente que realiza el tra-bajo. Para lograr esto se deben establecer mecanismos de comunicación formales e informales entre los miem-bros del equipo y entre múltiples equipos. La comuni-cación formal se lleva a cabo «por escrito, con reuniones organizadas y otros canales de comunicación relativa-mente no interactivos e impersonales» Lacomunicación informal es más personal. Los miembros de un equipo de software comparten ideas de por sí,piden ayuda a medida que surgen los problemas eactúan los unos con los otros diariamente.

Se puede encontrar una excelente introducción a estos temas rela-cionados con los equipos de proyectos de software en

43


discusión entre

hitos del proyectorevisiones de de seguimiento

de errores

correo electrónicoinspeccionesde código

oboletines del proyecto

herramientasde control del proyecto

3 4 5 6empleo de la técnica de coordinación

Enfoque impersonal, formalProcedimiento formal

o Procedimiento informalo Comunicación electrónicaA Red

FIGURA 3.1. Valor y empleo de técnicas de coordinacióny comunicación.

Kraul y Streeter examinan una colección de técnicas de coordinación de proyectos que segorizan de la siguiente manera:

Formal, enfoque impersonal. Incluyen documentos deingeniería del software y entregas (incluyendo el código fuen-te), memorandos técnicos, hitos del proyecto, planificacio-nes del programa y herramientas de control del proyecto (Capítulo 7), peticiones de cambios y documentación relati-va (Capítulo 9), informes de seguimiento de errores e infor-mación almacenada (Capítulo 3 1).

Formal, procedimientos interpersonales. Se centra en las actividades de garantía de calidad (Capítulo 8) aplicada

a productos de ingeniería del software. Estos incluyen reu-niones de revisión de estado e inspecciones de diseño y decódigo.

coordinarlas acciones de los miembros

del equipo?

procedimientos interpersonales.Incluyen reu-niones de para la divulgación de información y resolu-ción de problemas así como «definición de requisitos y delpersonal de desarrollo».

Comunicación electrónica. Comprende correo electróni-co, boletinesde noticias electrónicos y, por extensión, sistemas de videoconferencia.

Red interpersonal.Discusiones informales con los miem-bros del equipo y con personas que no están en el proyecto peroque pueden tener o una profunda visión que pue-de ayudar a los miembros del equipo.

Para valorar la eficacia de estas técnicas para la coor-dinación de proyectos, Kraul y Streeter estudiaron 65proyectos de software con cientos de personas implica-das. La Figura 3.1 (adaptada de expresa elvalor y empleo de las técnicas de coordinación apunta-das anteriormente. En la figura, el valor percibido (cla-sificadoen una escala de siete puntos) de varias técnicas de comunicación y coordinación es contrastado con sufrecuenciade empleo en un proyecto. Las técnicas situa-das por encima de la línea de regresión fueron «juzga-das como relativamente valiosas, dado la cantidad deveces que se Las técnicas situa-das por debajo de la línea se consideraronde menor valor.Es interesante resaltar que las redes interpersonales fue-ron catalogadas como las técnicas de mayor valor de coordinación y de comunicación. Es también importan-te hacer notar que los primeros mecanismos de garantíade calidad del software (requisitos y revisiones de dise-ño) parecieron tener más valor que evaluaciones poste-riores de código fuente (inspecciones de código).

El gestor de un proyectode software se enfrenta a un dile-ma al inicio de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan orga-nizado, pero no se dispone de información sólida. Unanálisis detallado de los requisitos del software pro-porcionaría la información necesaria para las estima-ciones,pero el análisis a menudo lleva semanas o meses.Aún peor, los requisitos pueden ser fluidos, cambiando regularmente a medida que progresa el proyecto. Y, aúnasí, se necesita un plan

3.3.1. Ámbito del softwareLa primera actividad de gestión de un proyecto de soft-ware es determinar el ámbito del software. El ámbito sedefine respondiendo a las siguientes 'cuestiones:

Sino puede de/que intento considere característica comoun riesgo de/ proyecto.

Por tanto, debemos examinar el producto y elblema a resolver justo al inicio del proyecto. Por lomenos se debe establecer el ámbito del producto ydelimitarlo. do del contexto?

Contexto. encaja el software a construir en un sistema, producto o contexto de negociosmayor y qué limitaciones se imponen como resulta-

44


Objetivosde información. objetos de datosvisibles al cliente (Capítulo 11)se obtienen del softwa-re? objetos de datos son requeridosde entrada?

Función y rendimiento. función realiza el software para transformar la información de entra-da en una salida? característicasde rendimientoespeciales que abordar? El ámbito de un proyecto de software debe ser uní-

y entendible a niveles de gestión y técnico. Losenunciados del ámbito del software deben estar deli-mitados.

Es decir, los datos cuantitativos (por ejemplo: núme-ro de usuarios simultáneos, tamaño de la lista de correo,máximo tiempo de respuesta permitido) se establecen explícitamente;se anotan las limitaciones (por ejemplo: el coste del producto limita el tamaño de la memoria) yse los factores de reducción de riesgos (por ejemplo: los algoritmos deseados se entienden muy bien si están disponibles en

3.3.2. Descomposición del problemaLa descomposición del problema, denominado a veces

particionado o elaboración delproblema, es una activi-dad que se asienta en el núcleo del análisis de requisitosdel software(Capítulo 11).Durante la actividad de expo-sición del ámbito no se intenta descomponer el proble-ma totalmente. Más bien, la descomposición se aplica endosáreasprincipales: (1) la funcionalidad que debe entre-garse y (2) el proceso que se empleará para entregarlo.

Para desarrollar un plan de proyecto razonable, tieneque descomponer funcionalmente el problema a resolver

Los sereshumanos tienden a aplicar la estrategia dedivide y vencerás cuando se enfrentan a problemas com-plejos. Dicho de manera sencilla,un problema complejo se parte en problemas más pequeños que resultan más manejables. Ésta es la estrategia que se aplica al inicio de la planificación del proyecto.

Las funciones del software, descritas en la exposi-ción del ámbito, se evalúan y refinan para proporcionar más detalle antes del comienzo de la estimación (Capí-tulo 5) . Puesto que ambos, el coste y las estimacionesde la planificación temporal, están orientadosnalmente, un pequeño grado de descomposición sueleser útil.

Por ejemplo, considere un proyecto que construiráun nuevo procesador de textos. Entre las características peculiares del producto están: la introducción de infor-mación a través de la voz así como del teclado; carac-terísticas extremadamente sofisticadas de «ediciónautomática de copia»; capacidad de diseño de página;indexación automática y tabla de contenido, y otras. Elgestor del proyecto debe establecer primero la exposi-ción del ámbito que delimita estas características (asícomo otras funciones más normales, como edición, administración de archivos, generación de documen-tos). Por ejemplo, ¿requerirá la introducción de infor-mación mediante voz «entrenamiento» por parte delusuario? capacidades específicas proporcionarála característica de editar copias? cómoserá de sofisticado la capacidad de diseño de página?

Enel 12 se presento parodescomponer el problema,

A medida que evoluciona la exposición del ámbito,un primer nivel de partición ocurre de forma natural. El equipo del proyecto sabe que el departamento de mar-keting ha hablado con clientes potenciales y ha averi-guado que las siguientes funciones deberían ser parte de la edición automática de copia: comprobaciónortográfica; (2) comprobación gramatical; ( 3 )compro-bación de referencias para documentos grandes ej.:

puede encontrar una referencia a una entrada biblio-gráfica en la lista de entradas de la bibliografía?), y (4)validación de referencias de sección y capítulo para documentos grandes. Cada una de estas características representa una subfunción para implernentar en soft-ware. Cada una puede ser aún más refinada si la des-composición hace más fácil la planificación.

fasesgenéricasque el proceso de soft-ware definición, desarrollo y soporte-son aplicables a todo software.El problema es seleccionarel modelo deproceso apropiado para la ingeniería del software quedebeaplicarel equipo del proyecto.En el Capítulo2 se estudióuna gran gama de paradigmas de ingenieríadel software:

el modelo secuencia1linealel modelo de prototipoel modelo DRA .

.

.

45

el modelo incremental el modelo en espiralel modelo en espiral WINWINel modelo de desarrollo basado (ensamblaje) en com-ponentesel modelo de desarrollo concurrente el modelo de métodos formalesel modelo de técnicas de cuarta generación


Uno vez eleyido el modelo de proceso, ocompóñelo conel mínimo conjunto de de y productos que desembocaronen un producto de - e v i t e la

de destruccióndel p r o c e s e .

El gestor del proyecto debe decidir qué modelo deproceso es el más adecuado para (1) los clientes que han solicitado el producto y la gente que realizará el traba-jo; (2 )las característicasdel producto en sí, y ( 3 )el entor-no del proyecto en el que trabaja el equipo de software.Cuando se selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar basado en un conjunto de actividades estructurales. Una vezestablecido el plan preliminar, empieza la descomposi-ción del proceso. Es decir, se debe crear un plan com-pleto reflejando las tareas requeridas a las personas para cubrir las actividades estructurales. Exploramos estas actividades brevemente en las secciones que siguen ypresentamos una visión más detallada en el Capítulo 7.

Maduración del productoy del procesoLa planificación de un proyecto empieza con la madu-ración del producto y del proceso. Todas las funciones que se deben tratar dentro de un proceso de ingenieríapor el equipo de software deben pasar por el conjunto de actividades estructurales que se han definido parauna organización de software. Asuma que la organiza-ción ha adoptado el siguiente conjunto de actividadesestructurales (Capítulo 2):

Comunicación con el cliente-tareas requeridas paraestablecer la obtención de requisitos eficiente entre el desarrollador y el cliente.Planificación- tareas requeridas para definir losrecursos, la planificación temporal del proyecto ycualquier información relativa a él.

Recuerde.... seen todos los proyectos- no hoy excepciones.

Análisis del riesgo-tareas requeridas para valorar los riesgos técnicos y de gestión.

tareas requeridas para construir una omás representaciones de la aplicación. Construccióny entrega-tareas requeridas para cons-truir, probar, instalar y proporcionar asistencia al usua-rio (por ejemplo: documentación y formación). Evaluación del cliente-tareas requeridas para obte-ner información de la opinión del cliente basadas enla evaluación de las representaciones de softwarecreadas durante la fase de ingeniería e das durante la fase de instalación.Los miembros del equipo que trabajanen cada función

aplicarán todas las actividades estructurales. En esencia,se crea una matriz similar a la que se muestra en la Figu-ra 3.2. Cada función principal del problema (la figura con-tiene las funciones para el software procesador de textoscomentado anteriormente) se lista en la columna de laizquierda. Las actividades estructurales se en la fila

FIGURA 3.2.Maduración del problema y del proceso.

46

CAPITULO 3 CONCEPTOS SOBRE DE PROYECTOS

de arriba.Las tareas de trabajo de ingeniería del software (paracada actividad estructural) se introducirían en la filasiguiente5.El trabajo del gestor del proyecto (y de otrosmiembros del equipo) es estimar los requisitos de recur-sos para cada celda de la matriz, poner fechas de inicio yfinalización para las tareas asociadas con cada celda y losproductos a fabricar como consecuencia de cada celda. Estas actividades se consideran en los Capítulos y 7.

descomposición del producto y del proceso se producesimultóneamente con evolución del plan de proyecto.

3.4.2. Descomposicióndel procesoUn equipo de software debería tener un grado significa-tivo de flexibilidad en la elección del paradigma de inge-niería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido. Un proyecto relati-vamentepequeño similara otros que se hayan hecho ante-riormente se debería realizar con el enfoque secuencia1lineal. Si hay límites de tiempo muy severos y el proble-ma sepuede compartimentar mucho, el modelo apropia-do es el DRA (en inglés RAD). Si la fecha límite está tanpróxima que no va a ser posible entregar toda la nalidad, una estrategia incremental puede ser lo mejor.Similarmente,proyectos con otras características ej.:requisitos inciertos, nuevas tecnologías, clientes difíci-les,potencialidad de reutilización) llevarán a la selección de otros modelos de proceso6.

Aplique siempre la (Estructura Común desin tener en cuenta el tamaño, o tipo del proyecto. tareas pueden variar pero la no.

Una vez que se ha elegido el modelo de proceso, la estructuracomún de proceso (ECP)se adaptaa él.En todos los casos,el ECP estudiado anteriormente en este capítu-lo -comunicación con el cliente, planificación, análisis de riesgo, ingeniería, construcción, entrega y evaluacióndel cliente-puede adaptarse al paradigma. Funcionará para modelos lineales, para modelos iterativos e incre-mentales,para modelosde evolución e para mode-losconcurrenteso de ensamblaje de componentes. El ECPes invariable y sirve como base para todo el trabajo desoftwarerealizado por una organización.

Pero las tareas de trabajo reales sí La descom-posición del proceso comienza cuando el gestor del pro-yecto pregunta: vamos a realizar esta actividad

Se hace notar que las tareas se deben adaptar a las necesidadesespecíficasde un proyecto. Las actividades estructuralessiempre per-manecen igual, pero las tareas se seleccionarán basándose en unoscriterios de adaptación. Este tema es discutido más adelante en elCapitulo 7 y en la página SEPA

Por ejemplo, un pequeño proyecto, relativamen-te simple, requiere las siguientes tareas para la actividad de comunicacióncon el cliente:

1.Desarrollar una lista de aspectos que se han de cla-rificar.

2. Reunirse con el cliente para resolver los aspectosque se han de clarificar.

3 . Desarrollar conjuntamente una exposición delámbito del proyecto.

4. Revisar el alcance del proyecto con todos los impli-cados.Modificar el alcance del proyecto cuando se requiera.Estos acontecimientos pueden ocurrir en un periodo de

menos de 48 horas. Representan una descomposición delproblema apropiado para proyectos pequeños relativa-mente sencillos.

Ahora, consideremos un proyecto más complejo que tenga un ámbito más amplio y un mayor impacto comer-cial. Un proyecto como ése podría requerir las siguientes tareas para la actividad de comunicación con el cliente:

1.Revisar la petición del cliente.2. Planificar y programar una reunión formal con el

cliente.3. Realizar una investigación para definir solucionespro-

puestas y enfoques existentes. 4. Preparar un «documentode trabajo» y una agendapara

la reunión formal.Realizar la reunión.

6. Desarrollar conjuntamente mini-especificacionesquereflejen la información, función y características decomportamientodel software.

Modelo de proceso adaptable.

7. Revisar todas las mini-especificaciones para compro-bar su corrección,su consistencia, la ausencia de ambi-güedades.

8. Ensamblar las mini-especificacionesen un documentode alcance del proyecto.

9. Revisar ese documento general con todo lo que puedaafectar.

10.Modificar el documento de alcance del proyectocuando se requiera.Ambos proyectos realizan la actividad estructural que

denominamoscomunicacióncon el cliente,pero el equipo del primer proyecto lleva a cabo la mitad de tareas deingeniería del software que el segundo.

Recuerde que las características del proyecto tienen también unafuerte influencia en la estructura del equipo que va a realizar el tra-bajo. Vea la Sección

47


3.5

Para gestionar un proyecto de software con éxito,debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien. En un excelentedocumento sobre proyectos de software, John

define diez señales que indican que un pro-yecto de sistemas de información está en peligro:

1.La gente del software no comprende las necesi-

2. El ámbito del producto está definido pobremente. 3 . Los cambios están mal realizados.4. La tecnología elegida cambia.5. Las necesidades del negocio cambian [o están mal

6. Las fechas de entrega no son realistas. 7. Los usuarios se resisten.8. Se pierden los patrocinadores [o nunca se obtu-

vieron adecuadamente]. 9. El equipo del proyecto carece del personal con las

habilidades apropiadas. 10.Los gestores [y los desarrolladores] evitan buenas

prácticas y sabias lecciones. Los profesionales veteranos de la industria hacen

referencia frecuentemente a la regla 90-90 cuando estudian proyectos de software particularmente difí-ciles: el primer 90 por 100 de un sistema absorbe el90 por 100del tiempo y del esfuerzo asignado. El últi-mo 10 por 100 se lleva el otro 90 por 100del esfuer-zo y del tiempo asignado Los factores queconducen a la regla 90-90 están contenidos en las diez señales destacadas en la lista anterior.

negatividad! actúa un gestor para evitar los problemas señalados anteriormente?

sugiere una aproximación de sentido común a los proyectos de software dividida en cinco partes:

Empezar con el pie derecho. Esto se realiza tra-bajando duro (muy duro) para comprender el pro-blema a solucionar y estableciendo entonces objetivosy expectativasrealistas para cualquiera que

dades de los clientes.

definidas].

vaya a estar involucrado en el proyecto. Seza construyendo el equipo adecuado (Sección 3.2.3)y dando al equipo la autonomía, autoridad y tecno-logía necesaria para realizar el trabajo.

Mantenerse. Muchos proyectos no realizan unbuen comienzo y entonces se desintegran lentamente. Para mantenerse, el gestor del proyecto debe pro-porcionar incentivos para conseguir una rotación delpersonal mínima, el equipo debería destacar la cali-dad en todas las tareas que desarrolle y los gestores veteranos deberían hacer todo lo posible por per-manecer fuera de la forma de trabajo del equipo7.

Seguimiento del Progreso. Para un proyecto desoftware, el progreso se siguemientras se realizan losproductos del trabajo (por ejemplo, especificaciones,código fuente, conjuntos de casos de prueba) y seaprueban (utilizando revisiones técnicas formales) como parte de una actividad de garantía de calidad.Además, el proceso del software y las medidas delproyecto (capítulo 4) pueden ser reunidas y utilizadaspara evaluar el progreso frente a promedios desarro-llados por la organización de desarrollo de software.

Tomar Decisiones Inteligentes. En esencia, lasdecisiones del gestor del proyecto y del equipo desoftware deberían «seguir siendo Siem-pre que sea posible, utilice software del mismocomercial o componentes de software existentes;evite personalizar interfaces cuando estén dispo-nibles aproximaciones estándar; identifique y eli-mine entonces riesgos obvios; asigne más tiempodel que pensaba necesitar para tareas arriesgadaso complejas (necesitará cada minuto).

Se puede un gran conjunto de recursos que pueden ayudar tanto a gestores de proyectoexperimentodos como principiantes en:www.pmi.org, www.4pm.com ywww.projectmanagement.com

Realizar un Análisis (despuéslizar el proyecto}. Establecer un mecanismo consis-tente para extraer sabias lecciones de cada proyecto.Evaluar la planificación real y la prevista,reunir y ana-lizar métricas del proyecto de software ycon datos de los miembros del equipo y de los clien-tes, y guardar los datos obtenidos en formato escrito.

Esta frase implica la reducción al mínimo de la burocracia, y la eli-minación tanto de reuniones extrañas como de la adherencia dog-mática a las reglas del proceso y del proyecto. El equipo debena estarcapacitado para realizar esto.

48


En un excelente documento sobre proyectos y proce-so del software, Boehm afirma: senecesita un principio de organización que haga unasimplificación con el fin de proporcionar planes [deproyectos] sencillos para proyectos pequeños». Boehm sugiere un enfoque que trate los objetivos, hitos y pla-nificación, responsabilidades, enfoque técnico y degestión, y los recursos requeridos del proyecto. Bohem lo llama el principio después deuna serie de preguntas (7 cuestiones) que conducen ala definición de las características clave del proyecto y el plan del proyecto resultante:

qué se desarrolla el sistema? La respuesta aestapreguntapermite a todas las partes evaluar la vali-dez de las razonesdel negocio para el trabajo del soft-ware. Dicho de otra forma, el propósito delnegocio el gasto en personal, tiempo, y dinero?

se realizaráy cuándo? La respuesta a estaspreguntas ayuda al equipo a establecer la planifi-cación del proyecto identificando las tareas clavedel proyecto y los hitos requeridos por el cliente.

preguntas necesitan ser respondidas para

desarrollar un Plan de Proyecto?

es el responsable de unafunción? Antesen este capítulo, señalamos que el papel y la res-

ponsabilidad de cada miembro del equipo de soft-ware debe estar definida. La respuesta a la pre-gunta ayuda a cumplir esto.

Dónde están situados organizacionalmente? No todos los roles y responsabilidades residen enel equipo de software. El cliente, los usuarios, yotros directivos también tienen responsabilidades.

de Proyecto de Software

estará realizado el trabajo desde to de vista técnico y de gestión? Una vez estable-cido el ámbito del producto, se debe definir unaestrategia técnica y de gestión para el proyecto.

cantidad de cada recurso se necesita? Larespuesta a esta pregunta se deriva de las estima-ciones realizadas (Capítulo 5 ) basadas en res-puestas a las preguntas anteriores. El principio de Boehm es aplicable sin tener

en cuenta el tamaño o la complejidad del proyecto desoftware. Las preguntas señaladas proporcionan unperfil de planificación al gestor del proyecto y al equi-po de software.

El Concilio8 Airlie ha desarrollado una lista de«prácticascríticas de software para la gestión basada en el rendimiento». Estas prácticas son «utilizadas deun modo consistente por, y consideradas críticas por, organizaciones y proyectos de software de mucho éxi-to cuyo rendimiento “final” es más consistente quelos promedios de la En un esfuer-zo por permitir a una organización de software deter-minar si un proyecto específico ha implementadoprácticas críticas, el Concilio Airlie ha desarrollado un conjunto de preguntas de «Visión Rápida» para un proyecto’:

Gestiónformal del riesgo. son los diez riesgos principales para este proyecto? Para cada

uno de los riesgos es la oportunidad de que el riesgo se convierta en un problema y cuál es elimpacto si lo hace?

Coste empíricoy estimación de la planificación.es el tamaño actual estimado de la aplicación

de software (sin incluir el software del sistema) queserá entregada en la operación? se obtuvo?

rápida del ProyectoAirlie

Concilio Airlie es un equipo de expertos en ingeniería del promocionado por el Departamento de Defensa U.S.ayudando en eldesarrollode directrices para prácticas importantes en la gestión deproyectosde software y en la ingeniería del Software.

Solo se destacan aquí aquellas practicas críticas relacionadas con la del proyecto)). Otras practicas mejores se trataran encapítulos posteriores.

49


Gestión de proyectos basada en métricas.pone de un programa de métricas para dar una prime-ra indicación de los problemas del desarrollo? Si es así,

es la volatilidad de los requisitos actualmente? Seguimiento del valor ganado. men-

sualmente de las métricas del valor ganado...? Sies así, calculadas estas métricas desde unared de actividades de tareas para el esfuerzo totala próxima entrega?

Seguimientode defectos frente aobjetivos de cali-dad. el seguimientoe informa periódicamente del númerode defectos encontrados en cada prueba deinspección [revisión técnica formal] y ejecución des-

de el principio del programa y del número de defectosque se corrigen y se producen en la actualidad?

Gestión del programa del personal. esla media de rotación de la plantilla en los tres Últi-mos meses por cada uno de losrrolladores involucrados en el desarrollo delsoftware para este sistema?Si un equipo de proyectos de software no puede

responder a estas preguntas, o las responde cuadamente, se debe realizar una revisión completa de las prácticas del proyecto. Cada una de las prácti-cas críticas señaladas anteriormente se tratan con deta-lle a lo largo de la Parte de este libro.

La gestión de proyectos de software es una actividadprotectora dentro de la ingeniería del software. Empie-za antes de iniciar cualquier actividad técnica y con-tinúa a lo largo de la definición, del desarrollo y delmantenimiento del software.

Hay cuatro P’s que tienen una influencia sustan-cial en la gestión de proyectos de software-personal,producto, proceso y proyecto-. El personal debe orga-nizarse en equipos eficaces, motivados para hacer unsoftware de alta calidad y coordinadospara alcanzar unacomunicación efectiva. Los requisitos del productodeben comunicarse desde el cliente al desarrollador,dividirse (descomponerse) en las partes que lo consti-tuyen y distribuirse para que trabaje el equipo de soft-ware. El proceso debe adaptarse al personal y alproblema. Se selecciona una estructura común de pro-ceso, se aplica un paradigma apropiado de ingenieríadel software y se elige un conjunto de tareas para com-

pletar el trabajo. Finalmente, el proyecto debe organi-zarse de una manera que permita al equipo de softwaretener éxito.

El elemento fundamental en todos los proyectos desoftware es el personal. Los ingenieros del softwarepueden organizarseen diferentes organigramas de equi-po que van desde las jerarquías de control tradiciona-les a los equipos de abierto». Se puedenaplicar varias técnicas de coordinación y comunica-ción para apoyar el trabajo del equipo. En general, lasrevisiones formales y las comunicaciones informalespersona a persona son las más valiosas para los pro-fesionales.

La actividad de gestión del proyecto comprendemedición y métricas, estimación, análisis de riesgos,planificación del programa, seguimiento y control.Cada uno de estos aspectos se trata en los siguientescapítulos.

Airlie Based Management: ware Engineering, vol. 3 1 Noviembre de 1988,The Program Manager’s Guide Based on the 16-Point 1268-1287.Plan and Related Draft Report, 8 de Marzo, 1999.

Baker, F.T., Programmer Teamment of Production IBM

vol. 11, 1, 1972, pp. 56-73.Boehm, the Software

IEEE vol. 13, 4, Julio de 1996, pp. 73-82.Constantine, L., Organization: Paradigms

for Project Management and CACM,vol.36, 10,Octubre de 1993, 34-43.

Cougar, y Zawacky, Managing andComputer Personnel, Wiley, 1980.

Curtis, et al., Managementlity Maturity Model , Software Engineering Institute,Pittsburgh, PA, 1994.

T., y Peopleware, edi-ción, Dorset House, 1998.

Edgemon, Stuff How to RecognizeIt When a Project Manager», ApplicationDevelopment Trends, vol. 2, 5, Mayo de 1995,

Ferdinandi, L.,

37-42.

IEEE Software, Septiembre de 1998, pp. 92-96.

Curtis, et al, Field Study of the SoftwareDesign Process for Large IEEE Trans.

Jackman, M., Remedies for TeamIEEE Software, Julio de 1998, pp. 43-45.

50


Kraul, y Streeter, SoftwareCACM,vol. 38, 3, Marzo de pp.

Mantei, M., Effect of Programming TeamStructureson Programming CACM,vol. 24, 3,Marzo de 1981, pp. 106-113.

Page-Jones, M., Practica1 Project Management,Dorset House, 1985, VII.

69-8

Factors SoftwareIEEE Software, Mayo de 1999, 18-23.

Weinberg, G., On Becoming aDorset House, 1986.

Whitaker, K., Software Maniacs, Wiley,1994.

Zahniser, for Top Team Perfor-mance», Development, Marzo de 1994,pp. 35-38.

3.1. Basándose en la información contenida en este capítu-lo y en su propia experiencia, desarrolle «diez mandamien-tos» para potenciar a los ingenieros del software. Es decir,haga una lista con las diez líneas maestras que lleven al per-sonal que construye software a su máximo potencial.3.2. El Modelo de Madurez de Capacidad de Gestión de Per- sonal (MMCGP) del Instituto de Ingeniería del Software haceun estudio organizado de las «áreas clave prácticasque cultivan los buenos profesionales del software. Su profe-sor le asignará una ACP para analizar y resumir.3.3. Describa tres situaciones de la vida real en las que elcliente y el usuario final son el mismo. Describa tres situaciones en que son diferentes. 3.4. Las decisiones tomadas por una gestión experimentadapueden tener un impacto significativo en la eficacia de un equi-po de ingeniería del software. Proporcione cinco ejemplos para ilustrarque es cierto. 3.5. Repase el libro de Weinberg y escriba un resu-men de dos o tres páginas de los aspectos que deberían tener- se en cuenta al aplicar el modelo MOI. 3.6. Se le ha nombrado gestor de proyecto dentro de unaorganización de sistemas de información. Su trabajo es

una aplicaciónque es bastante similar a otras que ha construido su equipo, aunque ésta es mayor y más compleja. Losrequisitos han sido detalladamente documentados por el clien-te. estructurade equipo elegiría y por qué? mode-lo(~)de proceso de software elegiría y por qué?3.7. Se le ha nombrado gestor de proyecto de una pequeña compañía de productos software. Su trabajo consiste en cons-truir un producto innovador que combine hardware de reali-dad con software innovador. que la competencia

por el mercado de entretenimiento casero es intensa, hay cier- ta presión para terminar el trabajo rápidamente. estruc-tura de equipo elegiría y por qué? de procesode software elegiría y por qué?3.8. Se le ha nombrado gestor de proyecto de una gran com-pañía de productos software. Su trabajo consiste en dirigir la versión de la siguiente generación de su famoso procesadorde textos. Como la competencia es intensa, se han estableci-do y anunciado fechas límite rígidas. estructura de equi-po elegiría y por qué? de proceso de softwareelegiría y por qué?3.9. Se le ha nombrado gestor de proyecto de software de unacompañía que en el mundo de la ingeniería Su trabajo es dirigir el desarrollo de un nuevo producto de soft-ware que acelere el ritmo de impresión de El trabajo esorientado a pero la meta es fabricar el producto dentro del siguiente año. estructura de equipo elegiría y por qué?

de proceso de software elegiría y por qué?3.10. Como muestra la Figura 3.1, basándose en los resulta-dos de dicho estudio, los documentos parecen tener más usoque valor. qué cree que pasó esto y qué se puede hacerpara mover el punto documentos por encima de la línea deregresión en el gráfico? Es decir, se puede hacer paramejorar el valor percibido de los documentos?3.11. Se le ha pedido que desarrolle una pequeña aplicaciónque analice todos los cursos ofrecidos por la universidad e informe de las notas medias obtenidas en los cursos (para un periodo determinado). Escriba una exposición del alcance queabarca este problema.3.12. Haga una descomposición funcional de primer nivel de la función diseño de página tratado brevemente en laSección 3.3.2.

Una excelente serie de cuatro volúmenes escrito porberg (Quality Software Management, Dorset House, 1992,1993,1994,1996)introduce los conceptos básicos sobre sis-temas y conceptos de gestión, explica cómo usar medicio-nes eficazmente y menciona la «acción congruente», lahabilidad de «encajar» las necesidades del gestor, del per-sonal técnico y las del negocio. Proporciona información Útil tanto a los gestores noveles como a los experimentados.Brooks (The Mythical Man-Month, Aniversary Edition, Addison-Wesley, 1995) ha actualizado su clásico libro para

proporcionar una nueva visión profunda de los aspectos delproyecto de software y de su gestión. Purba y Shah (How toManage a Software Project, Wiley, 1995)presen-tan un número de estudios de casos de proyectos que indicanpor qué unos fracasaron y otros fueron un éxito. Bennatan (Software Management in a

Wiley, 1995) estudia aspectos específicos de gestiónasociados con el desarrollo de sistemas

Se puede argumentar que el aspecto más importante de lagestión del proyecto de software es la gestión de personal. El

51


libro definitivo sobre este tema lo escribieron yter pero se han publicado en los Últimos años lossiguientes libros donde se examina su importancia:

Beaudouin-Lafon, M., Computer SupportedWork, 1999.

Carmel, E., Global Software Teams: CollaboratingAcross Borders and Time Zones, Prentice Hall, 1999.

Humphrey, W. Managing Technical People:vation, Teamwork, and the Software Process,ley 1997.

Humphrey, W. Introduction to the Team of SoftwareProcess, Addison-Wesley, 1999.

Jones, H., Handbook of Team Design: AGuide to Team Development,

1997.Karolak, Global Software Development:

ging Virtual Teams and Environments, IEEE Computer Society, 1998.

Mayer, M., The Virtual Edge: Embracing Technology for Distributed Project Team Success, Project ManagementInstitute Publications, 1999.

Otro excelente libro de Weinberg es lecturaobligada para todo gestor de proyecto y jefe de equipo. Ledará una visión interna y directrices para realizar su traba-

jo más eficazmente. House (The Human of ProjectManagement, Addison-Wesley, 1988) y Crossby (RunningThings: The art of Making Things Happen,1989)proporcionan directrices prácticas para gestores quedeban tratar con problemas humanos y técnicos.

Aunque no están relacionados específicamente con elmundo del software, y algunas veces sufren demasiadassimplificaciones y amplias generalizaciones, los libros degran éxito de Drucker (Management theCentury, Harperbusines, Buckingham y Coffman (First, Break the Rules: What the World’sManagers Do Simon Schuster, 1999) ytensen (The Business SchoolPress, 1997) enfatizan «nuevas reglas» definidas por unaeconomía que cambia con rapidez. Viejos títulos como

Minute Manager e Search of continúanproporcionando enfoques valiosos que pueden ayudarle agestionar los temas relacionados con el personal de un modo más eficiente.

En Internet están disponibles una gran variedad de fuen-tes de información relacionadas con temas de gestión de pro-yectos de software. Se puede encontrar una lista actualizada con referencias a sitios (páginas) web que son relevantes paralos proyectos de software en

52

Enfoque producto y proceso Ing. de Soft

Education

Transcript of Enfoque producto y proceso Ing. de Soft