Your SlideShare is downloading. ×
Enfoque  producto y proceso Ing. de Soft
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Enfoque producto y proceso Ing. de Soft

3,238
views

Published on

Enfoque producto y proceso Ing. de Soft

Enfoque producto y proceso Ing. de Soft

Published in: Education, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,238
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
54
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. L AS alarmas comenzaron más de una década antes del acontecimiento. Con menos de dos años a la fecha señalada, los medios de comunicación recogieron la historia. Los oficiales del gobierno expresaron su preocupación, los directores de la industria y de los comprometieron grandes cantidades de dinero, y por Último, las advertencias bles de 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 en sistemas 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 es qué e s importante? Porque obtenido?Des-el producto que y construyen afecta muy de cerca a cualquier de el punto de vista de un ingeniero de a y está muy software, e l producto obtenidoson losca programas que se ejecutan omercio, cuí- programas, documentos y los datos coti- que configuran el software d e de el punto de vista de los usuarios el producto obte impresos y datos que combinan información resultantenúmeros y texto y incluyen algún modo mundrepresentaciones d e información de queaudio, vídeo e imágenes. conduce a un resultado de alta calidad puedo estar de que lo hace? Los ingenierosde soft- que satisface las necesidades de l a lo he hecho Leeware construyen, y virtualmente gente que usará el producto. Debes el resto libro, selecciona aque-cualquier persona en el mundo indus- aplicar un enfoque d e ingeniería d e llas ideas que al soft-trialiiado lo utiliza bien directa o software. ware que construyes y aplícalas a tu trabajo. 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 un paradigma 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 un dó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. Al mismo tiempo que crece su importancia, la comunidad del software trata continuamente de desarrollar 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 construyen software -aquellos que lo deben hacer bien- La tecnología que comprende un . proceso, un juego de métodos y un conjunto de herramientas se llama ingeniería del software. 3
  • 2. DEL SOFTWARE. UN ENFOQUE PRACTICOHoy 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 porhardware local. Si reside dentro de un teléfono celularu opera dentro de una computadora central, el softwa-re es un transformador de información, produciendo,gestionando, adquiriendo, modificando, mostrando o las computadoras y el software nos llevaran a latransmitiendo información que puede ser tan simple cratización del conocimiento». A Yourdon lecomo un solo bit, o tan complejo como una presenta- preocupaba que las compañías en Estados Unidos pudie-ción en multimedia. Como vehículo utilizado para hacer ran perder su competitividad en empresas relativas alentrega del producto, el software actúa como la base de software y predijo «el declive y la caída del programa-control de la computadora (sistemas operativos), la dor americano». Hammer y Champy argu-comunicación de información (redes) y la creación y mentaron que las tecnologías de información iban acontrol de otros programas (herramientas de software desempeñar el papel principal en la de lay entomos). compañía».A mediados de los años 90, la persistencia de las computadoras y del una erupción de libros por (por ejemplo: Resisting the Vir- tual editadopor James Brook y Ian y The re not Compute de Stephen Talbot). Estos autores El es tonto un producto, critican enormemente la computadora, haciendo énfasis como el vehículo poro su entrego en preocupaciones legítimas pero ignorando los profun- dos beneficios que se han llevado a cabo El papel del software ha sufrido un cam-bio significativo durante un periodo de tiempo superiora 50 años. Enormes mejoras en rendimiento del más fáciles,ware, profundos cambios de arquitecturas informáticas, que facilitan nograndes aumentos de memoria y capacidad de almace-namiento y una gran variedad de opciones de entrada ysalida han conducido a sistemas más sofisticados y máscomplejos basados en computadora. La sofisticación y Al final de los años 90, Yourdon volvió ala complejidad pueden producir resultados deslum- evaluar las perspectivas del software profesional y sugi-brantes cuando un sistema tiene éxito, pero también pue- rió la y elevación» del programador ame-den suponer grandes problemas para aquellos que deben ricano. A medida que internet creció en importancia, suconstruir sistemas complejos. cambio de pensamiento demostró ser correcto. Al final Libros populares publicados durante los años 70 y 80 del siglo veinte, el enfoque cambió una vez más. Aquíproporcionan una visión histórica útil dentro de la per- tuvo lugar el impacto de la «bomba de relojería» Y2Kcepción cambiante de las computadoras y del software, (por ejemplo: Aunquey de su impacto en nuestra cultura. muchos vieron las predicciones de los críticos del Y2Khablaba de una «nueva revolución Toffler como reacciones, sus populares lecturas devolvieron la llamó a la llegada de componentes difusión del software a sus vidas. Hoy en día, com-trónicos la «tercera ola del cambio» en la historia de la putación omnipresente» ha producido una gene-humanidad, y Naisbitt predijo la transformación ración de aplicaciones de información que tienende la sociedad industrial a una «sociedad de informa- conexión en banda ancha a la Web para proporcionarción».Feigenbaum y sugirieronque capa de conexión sobre nuestras casas, oficinas, yla información y el conocimiento (controlados por com- autopistas» El papel del software continúa suputadora) serían el foco de poder del siglo veintiuno, y expansión. argumentó que la «comunidad electróni- El programador solitario de antaño ha sido reempla-ca» creada mediante redes y software es la clave para el zado por un equipo de especialistasdel software, cada unointercambio de conocimiento alrededor del mundo. centradoen una parte de la tecnología requerida para entre- Al comienzo de los años 90, Toffler descri- gar una aplicación concreta. Y de este modo, las cuestio-bió un «cambio de poder» en el que las viejas estructu- nes que se preguntaba el programador solitario son lasras de poder (gubernamentales, educativas, industriales, mismas cuestiones que nos preguntamos cuando cons-económicas y militares) se desintegrarían a medida que truimos sistemas basados en computadoras: 4
  • 3. CAPITULO 1 EL PRODUCTO Y EL PROCESO 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- Estadísticas de software forme se desarrolla el software?En 1970, menos del uno por ciento de las personas Los costes del software se encuentran en la ingeniería.podría haber descrito inteligentemente lo que significa- Esto significaque proyectos de software no se puedenba «softwarede computadora». Hoy, la mayoría de los gestionar como si fueran proyectos de fabricación.profesionales y muchas personas en general piensan ensu mayoría que comprenden el software. lo entien- 2. El software no se «estropea».den realmente? La Figura 1.1 describe, para el hardware, la proporción de falloscomo una función del tiempo. Esa relación, deno- minada frecuentemente «curva de bañera», indica que el1.2.1. Características del software hardware exhibe relativamente muchos fallos alPara poder comprender lo que es el software (y con- pio de su vida (estos fallos son atribuibles normalmentesecuentemente la ingeniería del software), es impor- a defectos del diseño o de la fabricación);una vez corre-tante examinar las características del software que lo gidos los defectos, la tasa de fallos cae hasta un nivel esta-diferencian de otras cosas que los hombres pueden cionario (bastante bajo, con un poco de optimismo) dondeconstruir. Cuando se construye hardware, el proceso permanece durante un cierto periodo de tiempo. Sincreativo humano (análisis, diseño, construcción, prue- embargo, conforme pasa el tiempo, el hardware empie-ba) se traduce finalmente en una forma física. Si cons- za a desgastarse y la tasa de fallos se incrementa.truimos una nueva computadora, nuestro boceto El software no es susceptible a los males del entor-inicial, diagramas formales de diseño y prototipo de no que hacen que el hardware se estropee. Por tanto, enprueba, evolucionan hacia un producto físico (chips, teoría, la curva de fallos para el software tendría la for-tarjetas de circuitos impresos, fuentes de potencia, ma que muestra la Figura 1.2. Los defectos no detecta-etc.). dos haran que falle el programa durante las primeras El software es un elemento del sistema que es etapas de su vida. Sin embargo, una vez que se corri-lógico, en lugar de físico. Por tanto el software tie- gen (suponiendo que no se introducen nuevos errores)ne unas características considerablemente distintas la curva se aplana, como se muestra. La curva ideali-a las del hardware: zada es una gran simplificación de los modelos reales de fallos del software más información en el Capítulo 8). Sin embargo la implicación es clara, el soft- c VE ware no se estropea. se deteriora! El software se desarrolla, no se fabrica. CLAVE El software se desarrolla, El software no se estropea, pero se deteriora. no se fabrica en un sentido clásico.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 un Mortalidad Se estropeabuen diseño, pero la fase de construcción del alware puede problemas de calidad que no alexisten (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 requieren Tiempola construcción de un «producto» pero los enfoquesson diferentes. FIGURA 1.1. Curva de fallos del hardware. 5
  • 4. DEL SOFTWARE. UN ENFOQUE PR A CTICO Esto que parece una contradicción, puede compren- A medida que la disciplina del software evoluciona, sederse mejor considerando curva mostrada en crea un grupo de componentes de diseño estándar. Torni-la Figura 1.2. Durante su vida, el software sufre cambios llos estándar y circuitos integradospreparados para la ven-(mantenimiento). Conforme se hacen los cambios, es ta son solamente los dos mil coinponentes estándar quebastante probable que se introduzcan nuevos defectos, utilizan ingenieros mecánicos y eléctricos cuando dise-haciendo que la curva de fallos tenga picos como se ve ñan nuevos sistemas. Los componentes reutilizables seen la Figura 1.2. Antes de que la curva pueda volver al han creado para que el ingeniero pueda concentrarse enestado estacionario original, se solicita otro cambio, elementos verdaderamente innovadores de un diseño, porhaciendo que de nuevo se cree otro pico. Lentamente, el ejemplo, las partes del diseño que representan algo nue-nivel mínimo de fallos comienza a crecer software vo. En el mundo del hardware, la reutilización de com-se va deteriorando debido a los cambios-. ponentes es una parte natural del proceso de ingeniería. Otro aspecto de ese deterioro ilustra la diferencia entre En el mundo del software es algo que sólo ha comenza-el hardware y el software. Cuando un componente de do a en una escala amplia.hardware se estropea se sustituye por una pieza de repues- El componente de software debería diseñarse eto. No hay piezas de repuesto para el software. Cada fallo implementarse para que pueda volver a seren el software indica un error en el diseño o en el proce- do en muchos programas diferentes. En los años 60,so mediante el que se tradujo el diseño a código máqui- se construyeron bibliotecas de subrutinas científicasna ejecutable. Por tanto, el mantenimiento del software reutilizables en una amplia serie de aplicaciones cien-tiene una complejidad considerablemente mayor que la tíficas y de ingeniería. Esas bibliotecas de subrutinasdel mantenimiento del hardware. reutilizaban de forma efectiva algoritmos bien defi- nidos, pero tenían un dominio de aplicación limita-3. Aunque la industria tiende a ensamblar componen- do. Hoy en día, hemos extendido nuestra visión de tes, la mayoría del software se construye a medida. reutilización para abarcar no sólo los algorítmos, sino Consideremos la forma en la que se diseña y se cons- también estructuras de datos. Los componentestruye el hardware de control para un producto basa- tilizables modernos encapsulan tanto datos como pro-do en computadora. El ingeniero de diseño construye cesos que se aplican a los datos, permitiendo alun sencillo esquema de la circuitería digital, hace ingeniero del software crear nuevas aplicaciones aalgún análisis fundamental para asegurar que se con- partir de las partes reutilizables. Por ejemplo, lassigue la función adecuada y va al armario donde se interfaces gráficas de usuario de hoy en día se cons-encuentran los catálogos de componentes digitales. truyen frecuentemente a partir de componentesDespués de seleccionar cada componente, puede tilizables que permiten la creación de ventanascitarse la compra. gráficas, de menús despleglables y de una amplia variedad de mecanismos de interacción. Incremento del índice de fallos c VE mayoría del sigue construyéndose a medida. 1.2.2. Aplicaciones del software El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto especí- fico de pasos procedimentales (es decir, un algoritmo) (excepciones notables a esta regla son el software de los sistemas expertos y de redes neuronales). El conte- idealizada nido y el determinismo de la información son factores Tiempo importantes a considerar para determinar la naturaleza de una aplicación de software. El contenido se refiereFIGURA 1.2. Curvas de fallos real e idealizada del software. 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áquina CLAVE automática (por ejemplo: un control numérico) acepta los métodos de ingeniería de software se esfuerzan elementos de datos discretos con una estructura limita- para reducir magnitud de los picos y inclinación da y produce órdenes concretas para la máquina en rápi- de curva 1.2). da sucesión. 6
  • 5. 1 EL PRODUCTO Y EL PROCESO Software de gestión. El proceso de la información l a revolución del se foto en 13. comercial constituye la mayor de las áreas de aplica- Lo ingenieríade software basada en ción del software. Los discretos (por ejem- se presento en el Capítulo 27. plo: nóminas, cuentas de etc.) han evolucionado hacia el software de sistemas de información de gestión (SIG) que accede a una o más El determinismo de la información se refiere a la bases de datos que contienen información comercial.decibilidad del orden y del tiempo de llegada de los Las aplicaciones en esta área reestructuran los datosdatos. Un programa de análisis de ingeniería acepta datos existentes para facilitar las operaciones comerciales oque están en un orden predefinido, ejecuta el gestionar la toma de decisiones. Además de las tareas de análisis sin interrupción y produce los datos convencionales de procesamientos de datos, las aplica-resultantes en un informe o formato gráfico. Se dice que ciones de software de gestión también realizan cálculotales aplicaciones son determinadas. Un sistema opera- interactivo (por ejemplo: el procesamiento de transac-tivo multiusuario, por otra parte, acepta entradas que ciones en puntos de ventas).tienen un contenido variado y que se producen en ins-tantes arbitrarios, ejecuta algoritmos que pueden ser Software de ingeniería y científíco. El softwareinterrumpidos por condiciones externas y produce una de ingeniería y científico está caracterizado por lossalida que depende de una función del entorno y del algoritmos de «manejo de números». Las aplicacio-tiempo. Las aplicaciones con estas características se dice nes van desde la astronomía a la vulcanología, desdeque son indeterminadas. el análisis de la presión de los automotores a la diná- mica orbital de las lanzaderas espaciales y desde la Algunas veces es difícil establecer categorías gené- biología molecular a la fabricación automática. Sinricas para las aplicaciones del software que sean sig- embargo, las nuevas aplicaciones del área denificativas. Conforme aumenta la complejidad del se han alejado de los algoritmos con-software, es más difícil establecer compartimentos vencionales numéricos. El diseño asistido pornítidamente separados. Las siguientes áreas del soft- computadora (del inglés CAD), la simulación de sis-ware indican la amplitud de las aplicaciones poten- temas y otras aplicaciones interactivas, han comen-ciales: zado a coger características del software de tiempo Software de sistemas. El software de sistemas es real e incluso del software de sistemas.un conjunto de programas que han sido escritos para Software empotrado. Los productos inteligentes seservir a otros programas. Algunos programas de siste- han convertido en algo común en casi todos los merca-mas (por ejemplo: compiladores, editores y utilidades dos de consumo e industriales. El software empotradode gestión de archivos) procesan estructuras de infor- reside en memoria de sólo lectura y se utiliza para con-mación complejas pero determinadas. Otras aplicacio- trolar productos y sistemas de los mercados industria-nes de sistemas (por ejemplo: ciertos componentes del les y de consumo. El software empotrado puede ejecutarsistema operativo, utilidades de manejo de funciones muy limitadas y curiosas (por ejemplo: el con-procesadores de telecomunicaciones) procesan datos en trol de las teclas de un horno de microondas) o sumi-gran medida indeterminados. En cualquier caso, el área nistrar una función significativa y con capacidad dedel software de sistemas se caracteriza por una fuerte control (por ejemplo: funciones digitales en un auto-interacción con el hardware de la computadora; una gran móvil, tales como control de la gasolina, indicadores enutilización por múltiples usuarios; una operación con- el salpicadero, sistemas de frenado, etc.).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 que sucesos del mundo real conforme Se puede encontrar una de mayores bibliotecasocurren, se denomina de tiempo real. Entre los elemen- de entos del software de tiempo real se incluyen: un compo-nente de adquisición de datos que recolecta y da formatoa la información recibida del entorno externo, un com- Software de computadoras personales. El mercadoponente de análisis que transforma la información según del software de computadoras personales ha germinadolo requiera la aplicación,un componentede en las pasadas dos décadas. El procesamiento de tex-que responda al entorno externo, y un componente de tos, las hojas de cálculo, los gráficos por computadora,monitorización que coordina todos los demás compo- multimedia, entretenimientos,gestión de bases de datos,nentes, de forma que pueda mantenerse la repuesta en aplicaciones financieras, de negocios y personales ytiempo real (típicamente en el rango de un milisegundo redes o acceso a bases de datos externas son algunas dea un segundo). los cientos de aplicaciones.
  • 6. DEL SOFTWARE. UN ENFOQUE Software basado en Las páginas Web busca- Softwarede inteligencia artificial.El software de inte-das por un explorador son software que incorpora ins- ligencia artificial (IA) hace uso de algoritmos no numéri-trucciones ejecutables (por ejemplo, CGI, HTML, Perl, cos para resolver problemas complejospara los que no sono Java), y datos (por ejemplo, hipertexto y una varie- adecuadosel cálculo o el análisis directo. Los sistemasexper-dad de de audio y visuales). En esencia, la red tos, también llamados sistemas basados en el conocimiento,viene a ser una gran computadora que proporciona un reconocimiento de patrones (imágenes y voz), redesrecurso software casi ilimitado que puede ser accedido artificiales, prueba de teoremas, y los juegos sonpor cualquiera con un modem. representativos de las aplicaciones de esta categoría.Muchos observadores de la industria (incluyendo este computadoras, no ha habido ningún «punto nin-autor) han caracterizado los problemas asociados con el gún decisivo»,solamente un lento cambio evo-desarrollo del software como una «crisis». Más de unos lutivo, puntualizado por cambios tecnológicos explosivoscuantos libros (por ejemplo: en las disciplinas relacionadas con el software. han recogido el impacto de algunos de los Cualquiera que busque la palabra crisis en el dic-fallos mas importantes que ocurrieron durante la déca- cionario encontrará otra definición: punto decisivoda pasada. No obstante, los mayores éxitos conseguidos en el curso de una enfermedad, cuando se ve más claropor la industria del software han llevado a preguntarse si el paciente vivirá o morirá». Esta definición puedesi el término (crisis del software) es aún apropiado. darnos una pista sobre la verdadera naturaleza de losRobert autor de varios libros sobre fallos del soft- problemas que han acosado el desarrollo del software.ware, representa a aquellos que han sufrido un cambio Lo que realmente tenemos es una aflicción crónica.de pensamiento. Expone ver en mis La palabra se define como «algo que causa penaensayos históricos de fallos y en mis informes de excep- o desastre». Pero la clave de nuestro argumento es la defi-ción, fallos importantes en medio de muchos éxitos, una nición del adjetivo crónica: «muy duradero o que reapa-copa que está [ahora] prácticamente rece con frecuencia continuando indefinidamente». Es bastante más preciso describir los problemas que hemos estado aguantando en el negocio del software como una aflicció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ómo mantener el volumen cada vez mayor de software exis- tente y cómo poder esperar mantenemos al corriente de La palabra crisis se define en el diccionario Webster la demanda creciente de software.como punto decisivo en el curso de algo, momento, Vivimos con esta aflicción desde este día hecho,etapa o evento decisivo o Sin embargo, en térmi- la industria prospera a pesar de Y así, las cosasnos de calidad del software total y de velocidad con la cual podrán ser mejores si podemos encontrar y aplicar unson desarrollados los productos y los sistemas basados en remedio.Muchas de las causas de la crisis del software se pue- confusión. Los mitos del software tienen varios atribu-den encontrar en una mitología que surge durante los tos que los hacen insidiosos: por ejemplo, aparecieronprimeros años del desarrollo del software. A diferencia como declaraciones razonables de hechos (algunas vecesde los mitos antiguos, que a menudo proporcionaban a conteniendo elementos verdaderos), tuvieron un senti-los hombres lecciones dignas de tener en cuenta, los do intuitivo y frecuentemente fueron promulgados pormitos del software propagaron información errónea y expertos que «estaban al día». Esta terminología fue sugerida por el profesor Daniel Tiechrow de la Universidad de en una conferencia impartida en Ginebra, Suiza, Abril, 1989. 8
  • 7. 1 EL PRODUCTO Y EL PROCESO Mitos de gestión. Los gestores con responsabilidad Mitos del Cliente. Un cliente que solicita una apli-sobre el software, como los gestores en la mayoría de cación de software puede ser una persona del despacholas disciplinas, están normalmente bajo la presión de de al lado, un grupo técnico de la sala de abajo, el depar-cumplir los presupuestos, hacer que no se retrase el pro- tamento de ventas o una compañía exterior que solicitayecto y mejorar la calidad. Igual que se agarra al vacío un software bajo contrato. En muchos casos, el clienteuna persona que se ahoga, un gestor de software se aga- cree en los mitos que existen sobre el software, debido arra frecuentemente a un mito del software, aunque tal que los gestores y desarrolladores del software hacen muycreencia sólo disminuya la presión temporalmente. poco para corregir la mala información. Los mitos con- Mito. Tenemos ya un libro que está lleno de ducen a que el cliente se cree una expectativay, final-res y procedimientos para construir software, le pro- mente, quede insatisfecho con el que desarrolla el software.porciona ya a mi gente todo lo que necesita saber? Mito. Una declaración general de los objetivos es sufi- Realidad. Está muy bien que el libro exista, pero ciente para comenzar a escribir los programas -pode-jse los trabajadores su existencia?, mos dar los detalles más adelante-.jrefleja las prácticas modernas de desarrollo de soft- Realidad. Una mala definición inicial es la principalware?, completo?, diseñado para mejorar el causa del trabajo baldío en software. Es esencial una des-tiempo de entrega mientras mantiene un enfoque de cripción formal y detallada del ámbito de la información,calidad? En muchos casos, la respuesta a todas estas funciones, comportamiento, rendimiento, interfaces, liga-preguntas es duras del diseño y criterios de validación. Estas caracte- rísticas pueden determinarse sólo después de una exhaustiva 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. Mito. Mi gente dispone de las herramientas de desa- l a gestión y control cambiorrollo de software más avanzadas, después de todo, les con detalle en el 9compramos las computadoras más modernas. Realidad. Se necesita mucho más que el últimomodelo 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 las utilicen eficazmente. Mito. Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido (el lla- mado algunas veces «conceptode la horda Definición Desarrollo Después Realidad. El desarrollo de software no es un proce- de la entrega so mecánico como la fabricación. En palabras de Bro- FIGURA 1.3. El impacto del cambio. oks «...añadir gente a un proyecto de software retrasado lo retrasa aún Al principio, esta declara- Realidad. Es verdad que los requisitos del softwa- ción puede parecer un contrasentido. Sin embargo, cuan- re cambian, pero el impacto del cambio varía según el do se añaden nuevas personas, la necesidad de aprender y momento en que se introduzca. La Figura 1.3 ilustra el comunicarsecon el equipo puede y hace que se reduzca la impacto de los cambios. Si se pone cuidado al dar la cantidad de tiempo gastado en el desarrollo productivo. definición inicial, los cambios solicitados al principio añadirse gente, pero sólo de una manera planifica- pueden acomodarse fácilmente. El cliente puede revi- da y bien coordinada. sar los requisitos y recomendar las modificaciones con relativamente 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- la red de gestión de proyectos de software bajo del diseño. Los cambios pueden producir trastor- en puede ayudarle nos que requieran recursos adicionales e importantes a estos y otros mitos. modificaciones del diseño; es decir, coste adicional. Los 9
  • 8. DEL SOFTWARE. UN ENFOQUE PRÁCTICOcambios en la función, rendimiento, interfaces u otras Mito. Hasta que no tengo el programa «ejecutándo-características, durante la implementación(codificación se», realmente no tengo forma de comprobar su calidad.y prueba) pueden tener un impacto importante sobre el Realidad. Desde el principio del proyecto se puedecoste. Cuando se solicitan al final de un proyecto, los aplicar uno de los mecanismos más efectivos para garan-cambios pueden producir un orden de magnitud más tizar la calidad del software: la revisión técnica formal.caro que el mismo cambio pedido al principio. La revisión del software (descrito en el Capítulo 8) es Mitos de los desarrolladores. Los mitos en los que un «filtro de calidad» que se ha comprobado que es másaún creen muchos desarrolladores se han ido fomen- efectivo que la prueba, para encontrar ciertas clases detando durante 50 años de cultura informática. Durante defectos en el software.los primeros días del desarrollo del software, la pro- Mito. Lo único que se entrega al terminar el pro-gramación se veía como un arte. Las viejas formas y yecto es el programa funcionando.actitudes tardan en morir. Mito. Una vez que escribimos el programa y hace- Un programa que funciona es sólo una par-mos que funcione, nuestro trabajo ha terminado. te de una configuración del software que incluye muchos elementos. La documentación proporciona el funda- Realidad. Alguien dijo una vez: «cuanto más pronto mento para un buen desarrollo y, lo que es más impor-se comience a escribir código, más se tardará en termi- tante, proporciona guías para la tarea de mantenimientonarlo». Los datos industriales del software.indican que entre el 60 y el 80 por ciento de todo elesfuerzo dedicado a un programa se realizará después Muchos profesionales del software reconocen lade que se le haya entregado al cliente por primera vez. 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. El muy duro poro entender lo que tienes que reconocimiento de las realidades del software es el de empezar. No serías copoz de codo primer paso hacia la formulación de soluciones prác- detalle; por más que tomo el menor riesgo. ticas para su desarrollo.El software se ha convertido en el elemento clave de ponen una configuración que se crea como parte della evolución de los sistemas y productos informáticos. proceso de la ingeniería del software. El intento de laEn los pasados 50 años, el software ha pasado de ser ingeniería del software es proporcionar un marco deuna resolución de problemas especializada y una herra- trabajo para construir software con mayor calidad.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 te pones o no tiempoporoinformáticos. El software se compone de programas, disciplino de lo ingeniería del y te preguntas:datos y documentos. Cada uno de estos elementos com- tiempo poder Brooks, The Mytical Addison-Wes- Glass, L., Software Prentice Hall, ley, 1975. 1997. De Jager, et al, Countdown Business Sur- Glass, there a Software Crisis?», for the Year 2000, Wiley, 1998. IEEE vol. 15, 1, Enero 1998, pp. 104-105. De Marco, T., Software Cost So Much?, Hammer, M., y Champy, Reengineering Dorset House, 1995, 9. poration, Publisher, 1993. Feigenbaum, E. A., y Gene- Jones, Software Measurement, ration, Addison-Wesley, 1983. 1991. Flowers, Software Failure, Management Karlson, E., y Kolber, A Basic to lure-Amaicing Stories and Wiley, How the Year 2000 Computer Crisis You?, 1997 Next Era Publications, Inc., 1999. 10
  • 9. 1 EL PRODUCTO Y EL PROCESO Levy, Luddites Are Newsweek, 12de Stoll, Egg, Doubleday, 1989. Julio de 1995, 55. Toffler, A., The Third Wave, Morrow Publishers, Levy, New Digital Newsweek, 1980. 31 de Mayo de 1999, . Toffler, A., Bantam Publishers, 1990. Lientz, y E. Swanson, Software Maintenance Yourdon, E., The Decline and the Addison Wesley, 1980. Programmer, Yourdon Press, 1992. Naisbitt, Megatoends, Warner Books, 1982. Yourdon, E., The Rise and Resurrection the Ame- Norman, TheInvisible Press, 1998. rican Programmer, Yourdon Press, 1996. Running Wild-The Next Industrial Yourdon, E., Death March Projects, Prentice-Hall, Revolution, 1979. 1998. Putnam, L., y Myers, Industrial Strength Soft- Yourdon, E., y Yourdon, Time 2000, ware, IEEE Computer Society Press, 1997. tice-Hall, 1998.1.1. El software es la característica que diferencia a muchos 1.5. A medida que el software se difunde más, los riesgos paraproductos y sistemas Dé ejemplos de dos o tres el público (debido a programas defectuosos) se convierten en unaproductos y de, al menos, un sistema en el que el software, no preocupación cada vez más significativa. Desarrolle un escena-el hardware, sea el elemento diferenciador. rio realista del juicio final (distinto a en donde el fallo de computadorapodría hacer un gran daño (económico o humano).1.2. En los cincuenta y sesenta la programación de com-putadoras era un arte aprendido en un entorno básicamente 1.6. Lea detenidamente el grupo de noticias de Internetexperimental. ha afectado esto a las prácticas de desa- y prepare un resumen de riesgos para las personasrrollo del software hoy? con las que se hayan tratado Últimamente. Código alternati-1.3. Muchos autores han tratado el impacto de la de la vo: Software Engineering Notes publicado por la ACM.información».Dé varios ejemplos (positivos y negativos) que 1.7. Escriba un papel que resuma las ventajas recientes enindiquen el impacto del software en nuestra sociedad. Repa- una de las áreas de aplicaciones de software principales. Entrese algunas referencias de la Sección 1.1 previas a 1990 e indi- las selecciones potenciales se incluyen: aplicaciones avanza-que dónde las predicciones del autor fueron correctas y dónde das basadas en Web, realidad virtual, redes neuronales artifi-no lo fueron. ciales, interfaces humanas avanzadas y agentes inteligentes.1.4. Seleccione una aplicación específica e indique: (a) la 1.8. Los mitos destacados en la Sección 1.4 se están vinien-categoría de la aplicación de software (Sección 1.2.2) en la do abajo lentamente a medida que pasan los años. Pero otrosque encaje; (b) el contenido de los datos asociados con la apli- se están haciendo un lugar. Intente añadir un mito o dos mitoscación; (c) la información determinada de la aplicación. «nuevos» a cada categoría.Literalmente existen miles de libros escritos sobre software do industrializado y casi todas las aplicaciones a la nuevade computadora. La gran mayoría tratan los lenguajes de pro- infraestructura de Internet.gramación o aplicaciones de software, y sólo unos pocos tra- (The Software Conspiracy: Why Softwaretan el software en sí. Pressman y Herron (Software Sock, panies Put Out Faulty Products, How They Can Hurt You,Dorset House, 1991) presentaron una discusión (dirigida a no and What You Can Do, 2000) argumentó queprofesionales) acerca del software y del modo en que lo cons- el «azote moderno» de los errores del software puede elimi-truyen los profesionales. narse y sugiere formas para hacerlo. El libro, éxito de ventas, de Negroponte (Being Digital, Software Cost So Much?, Dorset House, 1995) ha producidoAlfred A. Knopf, Inc., 1995) proporciona una visión de las una colección de ensayos divertidos e interesantes sobre elcomputadoras y de su impacto global en el siglo Los software y el proceso a través del cual se desarrolla.libros de Norman y Bergman (Information En Intemet están disponibles una gran variedad de fuen-Appliances Beyond, Academic Kauffman, tes de información relacionadas con temas de gestión y de2000) sugieren que el impacto extendido del PC declinará software. Se puede encontrar una lista actualizada con refe-al mismo tiempo que las aplicaciones de información y rencias a sitios (páginas) web relevantes enla difusión de la programación conecten a todos en el mun- man5.com. 11
  • 10. H OWARD Baetjer, Jr. en un libro fascinante que proporciona un punto d e vista economicista del software y de la ingeniería del software, comenta sobre el proceso: 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 un proceso 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 los diseñ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 como medio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento de las personas involucradas. Realmente, construir software de computadora es un proceso de aprendizaje iterativo, y el resultado, algo que Baetjer podría llamar del software», es el conjunto del software reunido. denurado v mientras se desarrolla el es? Cuando trabaja para construir qué es importante? Porque pro- software, los productos obtenidos sonun producto o un sistema, es impor- porciona estabilidad, control y organi- programas, documentos y datos setante seguir una serie d e pasos zación a una actividad que puede, si producen como consecuencia d e l a sdecibles -un mapa de carreteras que no se controla, volverse caótica. actividades de ingeniería del softwarele ayude a obtener el resultado opor- son los pasos? A un nivel deta- definidas por el proceso.tuno de calidad-. El mapa de carre- llado, el proceso que adoptemos puedo estar seguro de queteras a seguir es llamado del depende del software que estamos lo he hecho correctamente?Haysoftware.. construyendo. Un proceso puede ser una cantidad de mecanismos d e lo hace? Los ingenieros de soft- apropiado para crear software de un luacion del proceso del software queware y sus gestores adaptan el proce- sistema de aviación, mientras un permiten a las organizaciones deter-so a sus necesidades y entonces lo proceso diferente por completo puede minar la de su proceso delsiguen. Además las personas que han ser adecuado para la creación d e un software. Sin embargo, la calidad, opor-solicitado el software tienen un papel sitio web. tunidad y viabilidad a largo plazo dela desempeñar en el proceso del soft- es el producto obtenido? Des- producto que está construyendo son losware. de el punto de vista de un ingeniero d e mejores indicadores de la eficiencia del proceso que estamos utilizando. Pero, es exactamente el proceso del software desde 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ías que 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 demandas de su mercado. La intención de este capítulo es proporcionar un estudio del estado actual del proceso del software y puntualizar sobre el estudio detallado de los temas de gestión y técnicos presentados en este libro. 13
  • 11. DEL SOFTWARE. U N E N F O Q U E PR A C TI COAunque 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: FIGURA 2.1. Capas de la ingeniería del software. El fundamento de la ingeniería del software es la capa 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 oportuno de la ingeniería del software. El proceso define un mar- [La ingeniería del software] es el establecimiento y uso de prin- co de trabajo para un conjunto de Úreas clave de pro-cipios robustos de la ingeniería a fin de obtener económicamente ceso que se deben establecer para lasoftware que sea fiable y que funcione eficientemente sobre máqui-nas reales. entrega efectiva de la tecnología de la ingeniería del software. Las áreas claves del proceso forman la base Casi todos los lectores tendrán la tentación de del control de gestión de proyectos del software y esta-seguir esta definición. No dice mucho sobre los aspec- blecen el contexto en el que se aplican los métodos téc-tos técnicos de la calidad del software; no se enfren- nicos, se obtienen productos del trabajo (modelos,ta directamente con la necesidad de la satisfacción del documentos, datos, informes, formularios, etc.), se esta-cliente o de la entrega oportuna del producto; omite blecen hitos, se asegura la calidad y el cambio se ges-la mención de la importancia de mediciones y métri- tiona adecuadamente.cas; tampoco expresa la importancia de un proceso Los métodos de la ingeniería del software indicanavanzado. Y sin embargo, la definición de Bauer nos «cómo» construir técnicamente el software. Los méto-proporciona una línea base. son los «princi- dos abarcan una gran gama de tareas que incluyen aná-pios robustos de la ingeniería» aplicables al desarro- lisis de requisitos, diseño, construcción de programas,llo de software de computadora? construimos pruebas y mantenimiento. Los métodos de la ingenieríael software «económicamente» para que sea «fiable»? del software dependen de un conjuntode principios bási- se necesita para crear programas de computa- cos que gobiernan cada área de la tecnología e incluyendora que funcionen no en una máqui- actividades de modelado y otras técnicas descriptivas.na si no en diferentes «máquinas reales»? Éstas soncuestiones que siguen siendo un reto para los inge-nieros del software. CLAVE l a Ingeniería de comprende un proceso, definimos métodos técnicosy de gestión, y herramientas. Ingeniería del software? Las herramientas de la Ingeniería del software pro- El IEEE ha desarrollado una definición más porcionan un enfoque automático o semi-automáticoparacompleta: el proceso y para los métodos. Cuando se integran herra- Ingeniería del software: La aplicación de un enfoque sis- mientas para que la información creada por una herra-temático, disciplinado y cuantificable hacia el desarrollo, opera- mienta la pueda utilizar otra, se establece un sistema deción y mantenimiento del software; es decir, la aplicación de soporte para el desarrollo del software llamado ingenie-ingeniería al software. (2) El estudio de enfoques como en ría del software asistida por computadora (CASE).2.1.1. Proceso, métodos y herramientas 2.1.2. Una visión general de la ingeniería del softwareLa Ingeniería del software es un tecnologíapa. Como muestra la Figura 2.1, cualquier enfoque de La ingeniería es el análisis, diseño, construcción, veri-ingeniería (incluida ingeniería del software) debe apo- ficación y gestión de entidades técnicas (o sociales).yarse sobre un compromiso de organización de cali- Con independencia de la entidad a la que se va a apli-dad. car ingeniería, se deben cuestionar y responder las siguientes preguntas: 14
  • 12. 2 EL PROCESO es el problema a resolver? La fase de desarrollo se centra en el cómo. Es decir, son las características de la entidad que se durante el desarrollo un ingeniero del software intenta utiliza para resolver el problema? definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro de una se realizará la entidad (y la solución)? arquitectura de software, cómo han de implementarse se construirá la entidad? los detalles procedimentales, cómo han de caracteri- zarse interfaces, cómo ha de traducirse el diseño en un enfoque se va a utilizar para no contemplar los lenguaje de programación (o lenguaje no errores que se cometieron en el diseño y en la cons- tal) y cómo ha de realizarse la prueba. Los métodos apli- trucción de la entidad? cados durante la fase de desarrollo variarán, aunque las se apoyará la entidad cuando usuarios soli- tres tareas específicas técnicas deberían ocurrir siem- citen correcciones, adaptaciones y mejoras de la enti- pre: diseño del software (Capítulos 14, 15 y gene- dad? ración de código y prueba del software (Capítulos 16, 17 y 22). Referencia Web es un periódico que proporciona y comentarios prócticos de ingeniería del software. Estón disponibles temas directamente en: www.stc.hill.af.mil A lo largo de este libro, nos vamos a centrar enuna 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- La fase de mantenimiento se centra en el cambio querísticas genéricas del proceso de software. Más ade- va asociado a la corrección de errores, a las adaptacio-lante, en este mismo capítulo, se tratarán modelos nes requeridas a medida que evoluciona el entorno delespecíficos de procesos. software y a cambios debidos a las mejoras producidas El trabajo que se asocia a la ingeniería del software por los requisitos cambiantes del cliente. Durante la fasese puede dividir en tres fases genéricas, con indepen- de mantenimiento se encuentran cuatro tipos de cam-dencia del área de aplicación, tamaño o complejidad del bios:proyecto. Cada fase se encuentra con una o varias cues- Corrección. Incluso llevando a cabo las mejores acti-tiones de las destacadas anteriormente. vidades de garantía de calidad, es muy probable que el de definición se centra sobre el qué. Es decir, cliente descubra los defectos en el software. El mante-durante la definición, el que desarrolla el software inten- nimiento correctivo cambia el software para corregir losta identificar qué información ha de ser procesada, qué defectos.función y rendimiento se desea, qué comportamiento Adaptación. Con el paso del tiempo, es probabledel sistema, qué interfaces van a ser establecidas, qué que cambie el entorno original (por ejemplo: CPU, elrestricciones de diseño existen, y qué criterios de vali- sistema operativo, las reglas de empresa, las caracte-dación se necesitan para definir un sistema correcto. Por rísticas externas de productos) para el que se desarro-tanto, han de identificarse los requisitos clave del siste- lló el software. El mantenimiento adaptativo producema y del software. Aunque los métodos aplicados duran- modificaciónen el software para acomodarlo a los cam-te la fase de definición variarán dependiendo del bios de su entorno externo.paradigma de ingeniería del software (o combinación Mejora. Conforme se utilice el software, elde paradigmas) que se aplique, de alguna manera ten- puede descubrir funciones adicionales quedrán lugar tres tareas principales: ingeniería de sistemas van a producir beneficios. El mantenimiento perfectivoo de información (Capítulo planificación del pro- lleva al software más allá de sus requisitos funcionalesyecto del software (Capítulos 3, 5 , 6 y 7) y análisis de originales.los requisitos (Capítulos 11, 12 y 21). Prevención. El software de computadora se dete- riora debido al cambio, y por esto el ventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el man- El software crea tres fases distintas que se tenimiento preventivo hace cambios en programas de centran en definición, desarrollo y mantenimiento. computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente. 15
  • 13. DEL SOFTWARE. UN ENFOQUE PRACTICO Además de estas actividades de mantenimiento, losusuarios de software requieren un mantenimiento con-tinuo. Los asistentes técnicos a distancia, teléfonos deayuda y sitios Web de aplicaciones específicas sementan frecuentemente como parte de la fase de man-tenimiento. Actividades de protección Entre las actividades típicas de esta categoría se incluyen: Seguimiento y control del proyecto de software el término «mantenimiento» reconocemos que es mucho más que una simple Revisiones técnicas formales de errores. Garantía de calidad del software Hoy en día, el aumento de los programas legales Gestión de configuración del softwareestá forzando a muchas compañías a seguir estrategias Preparación y producción de documentosde reingeniería del software (Capítulo 30). En un sen- Gestión de reutilizacióntido global, la reingeniería del software se considera a Medicionesmenudo como una parte de la reingeniería de procesoscomerciales Gestión de riesgos Las fases y los pasos relacionados descritos en nues- Las actividades de protección se aplican a lo largotra visión genérica de la ingeniería del software se com- de todo el proceso del software y se tratan en las partesplementan con un número de actividades protectoras. Segunda y Quinta del libro.Un proceso de software se puede caracterizar como se del proyecto. Finalmente, las actividades de protecciónmuestra en la Figura 2.2. Se establece un marco común -talescomo garantía de calidad del software,gestión dedel proceso definiendo un pequeño número de activida- configuración del software y medición*-abarcan eldes del marco de trabajo que son aplicables a todos los modelo de procesos. Las actividades de protección sonproyectos del software,con independenciade su tamaño independientes de cualquier actividad del marco de tra-o complejidad.Un número de conjuntos de tareas - c a d a bajo y aparecen durante todo el proceso.uno es una colección de tareas de trabajo de ingeniería En los Últimos años, se ha hecho mucho énfasis endel software, hitos de proyectos, productos de trabajo, y la «madurez del El Softwate Engineeringpuntos de garantía de calidad-que permiten que las acti- ha desarrollado un modelo completo quevidades del marco de trabajo se adapten a las caracterís- se basa en un conjunto de funciones de ingeniería delticas del proyecto del software y a los requisitos del equipo software que deberían estar presentes conforme orga- nizaciones alcanzan diferentes niveles de madurez del proceso. Para determinar el estado actual de madurez del proceso de una organización, el utiliza un cues- Actividades del marco de trabajo tionario de evaluación y un esquema de cinco grados. Tareas Seleccioneun de del proceso común que se producto, 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 delFIGURA 2.2. El proceso del software. proporciona una medida de la efectividad global de término es un eufemismo para sottware Estos temas se tratan con más detalle en capítulos posteriores.antiguo, a menudo diseñado y documentado pobremente, que es crí- El autor se está refiriendo al de la Cannegie University.tico para el negocio y debe ser soportado durante algunos años. 16
  • 14. CAPÍTULO 2 EL PROCESOlas prácticas de ingeniería del software de una compa- ción ha sido detallado y se hace cumplir por medio deñía y establece cinco niveles de madurez del proceso, procedimientos tales como auditorías. Este nivel es aquelque se definen de la forma siguiente: en el que la mayoría de los desarrolladores de softwa- Nivel 1: Inicial. El proceso del software se caracte- re, pretenden conseguir con estándares como el ISOriza según el caso, y ocasionalmente incluso de forma 9001, y existen pocos casos de desarrolladores de soft-caótica. Se definen pocos procesos, y el éxito depende ware que superan este nivel.del esfuerzo individual. El nivel 4 comprende el concepto de medición y el uso de métricas. El capítulo 4 describe este tema con más Nivel 2: Repetible. Se establecen los procesos de detalle. Sin embargo, cabe destacar el concepto de métri-gestión del proyecto para hacer seguimiento del coste, ca para comprenderla importancia que tiene que el desa-de la planificación y de la funcionalidad. Para repetir rrollador del software alcance el nivel 4 o el nivel 5.éxitos anteriores en proyectos con aplicaciones simila- Una métrica es una cantidad insignificanteque puederes se aplica la disciplina necesaria para el proceso. extraerse de algún documentoo código dentro de un pro- Nivel 3: Definido. El proceso del software de las yecto de software. Un ejemplo de métrica es el númeroactividades de gestión y de ingeniería se documenta, se de ramas condicionales en una sección de código de unestandariza y se integra dentro de un proceso de soft- programa. Esta métrica es significativa en el sentido deware de toda una organización.Todos los proyectos uti- que proporciona alguna indicación del esfuerzo necesa-lizan una versión documentada y aprobada del proceso rio para probar el código: está directamente relacionadode la organización para el desarrollo y mantenimiento con el número de caminos de prueba dentro del código.del software. En este nivel se incluyen todas las carac- Una organización del nivel 4 maneja numerosasterísticas definidas para el nivel 2. métricas. Estas métricas se utilizan entonces para super- Nivel 4: Gestionado. Se recopilan medidas deta- visar y controlar un proyecto de software, por ejemplo:lladas del proceso del software y de la calidad del pro- Una métrica de prueba puede usarse para determinarducto. Mediante la utilización de medidas detalladas, cuándo finalizar la prueba de un elemento del código.se comprenden y se controlan cuantitativamente tan-to los productos como el proceso del software. En este Una métrica de legilibilidad puede usarse para juz-nivel se incluyen todas las características definidas gar la legilibilidad de algún documento en lenguajepara el nivel 3. natural. Nivel 5: Optimización. Mediante una retroalimen- Una métrica de comprensióndel programa puede uti-tación cuantitativadel proceso, ideas y tecnologías lizarse para proporcionar algún umbral numérico que se posibilita una mejora del proceso. En este los programadores no pueden cruzar.nivel se incluyen todas las características definidas para Para que estas métricas alcancen este nivel es nece-el nivel 4. sario que todos los componentes del nivel 3 CMM, en castellano MCM (Modelo de Capacidad de Madurez), estén conseguidos, por ejemplo notaciones bien defini- das para actividades como la especificación del diseño de requisitos, por lo que estas métricas pueden ser fácil- El ofrece un amplio conjunto de información relacionada con el proceso en www.sei.cmu.edu mente extraídas de modo automático. El nivel 5 es el nivel más alto a alcanzar. Hasta aho- Merece la pena destacar que cada nivel superior es ra, muy pocos desarrolladores de software han alcan-la suma de los niveles anteriores, por ejemplo, un desa- zado esta fase. Representa la analogía del software conrrollador de softwareen el nivel 3 tiene que haber alcan- los mecanismos de control de calidad que existen enzado el estado nivel 2 para poder disponer de sus otras industrias de mayor madurez. Por ejemplo el fabri-procesos en el nivel 3. cante de un producto industrial como un cojinete de El nivel 1 representa una situación sin ningún esfuer- bolas (rodamiento) puede supervisar y controlar la cali-zo en la garantía de calidad y gestión del proyecto, don- dad de los rodamientos producidos y puede predecir estade cada equipo del proyecto puede desarrollar software calidad basándose en los procesos y máquinas utiliza-de cualquier forma eligiendo los métodos, estándares y dos para desarrollar los rodamientos. Del mismo modoprocedimientos a utilizar que podrán variar desde lo que el desarrollador del sofware en el nivel 5 puede pre-mejor hasta lo peor. decir resultados como el número de errores latentes en El nivel 2 representa el hecho de que un desarrolla- un producto basado en la medición tomada durante lador de software ha definido ciertas actividades tales ejecución de un proyecto. Además, dicho desarrolladorcomo el informe del esfuerzo y del tiempo empleado, y puede cuantificar el efecto que un proceso nuevo o herra-el informe de las tareas realizadas. mienta de manufacturación ha tenido en un proyecto El nivel 3 representa el hecho de que un desarrolla- examinando métricas para ese proyecto y comparándo-dor de software ha definido tanto procesos técnicos como las con proyectos anteriores que no utilizaron ese pro-de gestión, por ejemplo un para la programa- ceso o herramienta. 17
  • 15. 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 el Referencia ’-nivel 3. Si el desarrollador del software no tiene defi- Una tabular del MCM completo del incluyendonidos rigurosamente los procesos pueden ocurrir una todos objetivos, comentarios, habilidades y actividades disponible engran 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 madurez y se distribuyen en niveles diferentes de madu-como consecuencia de evaluar las respuestas del cues- rez del proceso. Las ACPs se deberían lograr en cadationario de evaluación basado en el MCM (Modelo de nivel de madurez de proceso4:capacidad de madurez). Los resultados del cuestiona- Nivel 2 de Madurez del Procesorio se refinan en un único grado numérico que propor- Gestión de configuración del softwareciona una indicación de la madurez del proceso de unaorganización. Garantía de calidad del software El ha asociado áreas claves del proceso Gestión de subcontratación del software(ACPs) a cada uno de los niveles de madurez. Las Seguimiento y supervisión del proyecto del softwareACPs describen esas funciones de la ingeniería delsoftware (por ejemplo: planificación del proyecto de Planificación del proyecto del softwaresoftware, gestión de requisitos) que se deben pre- Gestión de requisitossentar para satisfacer una buena práctica a un nivel Nivel 3 de Madurez del Procesoen particular. Cada ACP se describe identificando las Revisiones periódicascaracterísticas siguientes: Coordinación entre grupos Ingeniería de productos de software lodo organización esforzarse poro Gestión de integración del software lo profundidad del del Sin Programa de formación lo de cualquier aspecto del modelo Definición del proceso de la organización puede eliminarse en su situación. Enfoque del proceso de la organización Objetivos- los objetivos globales que debe alcan- Nivel 4 de Madurez del Proceso zar la ACP Gestión de calidad del software Compromisos-requisitos (impuestos en la organi- Gestión cuantitativa del proceso zación) que se deben cumplir para lograr los objeti- vos y que proporcionan una prueba del intento por Nivel 5 de Madurez del Proceso ajustarse a los objetivos. Gestión de cambios del proceso Capacidades-aquellos elementos que deben encon- Gestión de cambios de tecnología trarse (organizacional y técnicamente) para permitir Prevención de defectos que la organización cumpla los objetivos. Actividades- las tareas específicas que se requieren Cada una de las ACPs se definen con un conjunto para lograr la función ACP. de prácticas clave que contribuyen a cumplir estos obje- tivos. Las prácticas clave son normas, procedimientos Métodos para supervisar la implementación-la y actividades que deben ocurrir antes de que se haya manera en que las actividades son supervisadas con- instituido completamente un área clave de proceso. El forme se aplican. define a los clave como prác- Métodos para verificar la implementución-la forma ticas clave o componentes de prácticas clave que ofre- en que se puede verificar la práctica adecuada para cen una visión mejor para lograr los objetivos de un la ACP. área clave de proceso». Las cuestiones de valoración Se definen dieciocho ACPs (descritas mediante la se diseñan para averiguar la existencia (o falta) de unestructura destacada anteriormente) en el modelo de indicador clave. Téngase en cuenta que las ACPs son acumulativas. Por ejemplo, el nivel 3 de madurez del proceso contiene todas las ACPs del nivel 2 más las destacadas para el nivel 18
  • 16. 2 EL PROCESOPara resolver los problemas reales de una industria, un completo, las etapas descritas anteriormente se aplicaningeniero del software o un equipo de ingenieros debe recursivamente a las necesidades del usuario y a la espe-incorporar una estrategia de desarrollo que acompañe cificación técnica del desarrollador del software.al proceso, métodos y capas de herramientas descritosen la Sección 2.1.1 y las fases genéricas discutidas enla Sección 2.1.2. Esta estrategia a menudo se llamamodelo de proceso o paradigma de ingeniería del soft- c VEware. Se selecciona un modelo de proceso para la inge- Todas etapas de un proceso del -estadoniería del software según la naturaleza del proyecto y actual, definición del problema, desarrollo técnico ede la aplicación, los métodos y las herramientas a utili- integración de solución-coexisten simultáneamentezarse, y los controles y entregas que se requieren. En en algún nivel de detalle.un documento intrigante sobre la naturaleza del proce-so del software, L.B.S. Raccoon utiliza En las secciones siguientes, se tratan diferentes mode-tales como base de estudio de la verdadera naturaleza los de procesos para la ingeniería del software. Cadadel proceso del software. una representa un intento de ordenar una actividad rentemente caótica. Es importante recordar que cada uno de los modelos se han caracterizado de forma que ayuden (con esperanza) al control y a la coordinación de un proyecto de software real. Y a pesar de eso, en el fondo, todos los modelos exhiben características del «Modelo del Caos». Definición Todo el desarrollo del software se puede caracteri- de problemaszar 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- Desarrollogración de soluciones. Status quo «representa el estado técnicoactual de la definición de proble-mas identifica el problema específico a resolverse; eldesarrollo técnico resuelve el problema a través de laaplicaciónde alguna tecnología y la integración de solu- Integraciónciones ofrece los resultados (por ejemplo: documentos, de solucionesprogramas, 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 demanera tan nítida como la Figura 2.3.b da a entender,porque existen interferencias entre las etapas. Aunqueesta visión simplificada lleva a una idea muy impor-tante: con independencia del modelo de proceso que se Estadoseleccione para un proyecto de software, todas las eta- actualpas -status quo, definición de problemas, desarrolloté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 tratadasanteriormente 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 software como una exten- FIGURA 2.3.a) Las fases de un bucle de resolución de pro-sión desde el usuario hasta el desarrollador y la tecno- blemas [RAC 951. Fases dentro de las faseslogía». Conforme progresa el trabajo hacia un sistema del bucle de resolución de problemas 19
  • 17. DEL SOFTWARE. UN ENFOQUE PRÁCTICO 2.4Llamado algunas veces «ciclo de vida básico» o se pueda evaluar su calidad antes de que comience lalo en cascada», el modelo lineal secuencial sugiere un codificación.enfoque5 sistemático, secuencial, para el desarrollo del Generación de código. El diseño se debe traducirsoftware que comienza en un nivel de sistemas y pro- en una forma legible por la máquina. El paso de gene-gresa con el análisis, diseño, codificación, pruebas y man- ración de código lleva a cabo esta tarea. Si se lleva atenimiento. La Figura 2.4 muestra el modelo lineal cabo el diseño de una forma detallada, la generación desecuencial para la ingeniería del software. Modelado código se realiza mecánicamente.según el ciclo de ingeniería convencional, el modelolineal secuencial comprende las siguientes actividades: Ingeniería y modelado deComo el software siempre forma parte de un sistema Aunque el modelo lineal es a menudomás grande (o empresa), el trabajo comienza estable- tradicional», resulto un enfoque razonableciendo requisitos de todos los elementos del sistema y cuando los requisitosse han entendido correctomente.asignando al software algún de estos requisi-tos. Esta visión del sistema es esencial cuando el soft- Pruebas. Una vez que se ha generado el código,ware se debe interconectar con otros elementos como comienzan las pruebas del programa. El proceso de prue-hardware, personas y bases de datos. La ingeniería y el bas se centra en los procesos lógicos internos del soft-análisis de sistemas comprende los requisitos que se ware, asegurando que todas las sentencias se hanrecogen en el nivel del sistema con una pequeña parte comprobado, y en los procesos externos funcionales; esde análisis y de diseño. La ingeniería de información decir, realizar las pruebas para la detección de erroresabarca los requisitos que se recogen en el nivel de y asegurar que la entrada definida produce resultadosempresa estratégico y en el nivel del área de negocio. 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án cambios porque se han encontrado errores, porque el soft- ware debe adaptarse para acoplarse a los cambios de su entorno 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 o de rendimiento. El soporte y mantenimiento del softwa- re vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.FIGURA 2.4. El modelo lineal secuencial. El modelo lineal secuencial es el paradigma más anti- guo y más extensamente utilizado en la ingeniería del Análisis de los requisitos del software. El proceso software. Sin embargo, la crítica del paradigma ha pues-de reunión de requisitos se intensifica y se centra espe- to en duda su eficacia Entre los problemascialmente en el software. Para comprender la naturaleza que se encuentran algunas veces en el modelo linealdel (los) a construirse, el ingeniero secuencial se incluyen:lista») del software debe comprender el dominio deinformación del software (descrito en el Capítulo 1 así qué falla algunas vecescomo la función requerida, comportamiento,rendimien- el modelo lineal?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 1. Los proyectos reales raras veces siguen el modelodistintos de programa: estructura de datos, arquitectu- secuencial que propone el modelo. Aunque el modelora de software, representaciones de interfaz y detalle lineal puede acoplar interacción, lo hace indirecta-procedimental (algoritmo). El proceso del diseño tra- mente. Como resultado, los cambios pueden causarduce requisitos en una representación del software donde confusión cuando el equipo del proyecto comienza. Aunque el modelo original en cascada propuesto por Winston Royce hacía provisiones para de la granmayoría d e las organizaciones que aplican este modelo de procesolo hacen como si fuera estrictamente lineal. 20
  • 18. 2 EL PROCESO A menudo es difícil que el cliente exponga explíci- Cada uno de estos errores es real. Sin embargo, el tamente todos los requisitos. El modelo lineal paradigma del ciclo de vida clásico tiene un lugar defi- cial lo requiere y tiene dificultades a la hora de nido e importante en el trabajo de la ingeniería del soft- acomodar la incertidumbre natural al comienzo de ware. Proporciona una plantilla en la que se encuentran muchos proyectos. métodos para análisis, diseño, codificación, pruebas y El cliente debe tener paciencia. Una versión de tra- mantenimiento. El ciclo de vida clásico sigue siendo el bajo del (los) no estará disponible hasta modelo de proceso más extensamente utilizado por la que el proyecto esté muy avanzado. Un grave error ingeniería del software. Pese a tener debilidades, es puede ser desastroso si no se detecta hasta que se nificativamente mejor que un enfoque hecho al azar para revisa el programa. el desarrollo del software.Un cliente, a menudo, define un conjunto de objetivosgenerales para el software, pero no identifica los requi-sitos detallados de entrada, proceso o salida. En otros Escucharcasos, el responsable del desarrollo del software puede al clienteno estar seguro de la eficacia de 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. El cliente prueba2.5) comienza con la recolección de requisitos. El la maquetarrollador y el cliente encuentran y definen los objeti-vos globales para el software, identifican los requisitosconocidos y las áreas del esquema en donde es obli- FIGURA 2.5. El paradigma de construcción de prototipos.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 Pero hacemos con el prototipo una vez que hapara el (por ejemplo: enfoques de entra- servidopara el propósito descrito anteriormente? Brooksda y de salida). El diseño rápido lleva a la proporciona una respuesta:construcción de un prototipo. El prototipo lo evalúa el y se utiliza para refinar los requisitos En la mayoría de los proyectos, el primer sistema construidodel software a desarrollar. La iteración ocurre cuando apenas se puede utilizar. Puede ser demasiado lento, demasiadoel prototipo se pone a punto para satisfacer las nece- 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-sidades del cliente, permitiendo al mismo tiempo que ligente, y construir una versión rediseñada en la que se resuelvanel desarrollador comprenda mejor lo que se necesita estos problemas ... Cuando se utiliza un concepto nuevo de siste-hacer. ma o una tecnología nueva, se tiene que construir un sistema que no sirva y se tenga que tirar, porque incluso la mejor planificación no es omnisciente como para que esté perfecta la primera vez. Por lo 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- el tiene uno necesidad nificar de antemano construir un desechable, o prometer pero sobre los entregárselo a los clientes... el poso es un El prototipo puede servir como «primer sistema». El que Brooks recomienda tirar. Aunque esta puede ser Lo ideal sería que el prototipo sirviera como un meca- una visión idealizada. Es verdad que a los clientes y anismo para identificar los requisitos del software. Si se los que desarrollan les gusta el paradigma de cons-construyeun prototipo de trabajo, el desarrolladorinten- trucción de prototipos. A los usuarios les gusta el sis-ta hacer uso de los fragmentos del programa ya exis- tema real y a los que desarrollan les gusta construir algotentes o aplica herramientas (por ejemplo: generadores inmediatamente. Sin embargo, la construcción de pro-de informes, gestores de ventanas, etc.) que permiten totipos también puede ser problemática por las siguien-generar rápidamente programas de trabajo. tes razones: 21
  • 19. DEL SOFTWARE. U N E N F O Q U E El cliente ve lo que parece ser una versión de trabajo para demostrar la capacidad. Después de algún del software, sin tener conocimiento de que el pro- tiempo, el desarrollador debe familiarizarse con estas totipo también está junto con chicle y el cable de selecciones, y olvidarse de las razones por las que embalar», sin saber que con la prisa de hacer que son inadecuadas. La selección menos ideal ahora es funcioneno se ha tenido en cuenta la calidad del soft- una parte integral del sistema. 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 los niveles altos de calidad, el cliente no lo entiende y Resisto lo presión de ofrecer un prototipo en el pide que se apliquen pequeños para producto Corno lo colidod se resiente que se pueda hacer del prototipo un producto final. siempre. De forma demasiado frecuente la gestión de desa- rrollo del software es muy lenta. Aunque pueden surgir problemas, la construcción de2. El desarrollador, a menudo, hace compromisos de prototipos puede ser un paradigma efectivo para la inge- implementación para hacer que el prototipo funcione niería del software. La clave es definir las reglas del jue- rápidamente. Se puede utilizar un sistema operativo go al comienzo; es decir, el cliente y el desarrollador se o lenguaje de programación inadecuado simplemente deben poner de acuerdo en que el prototipo se constru- porque está disponible y porque es conocido; un algo- ya para servir como un mecanismo de definición de ritmo eficiente se puede implementar simplemente requisitos.El Desarrollo Rápido de Aplicaciones (DRA)s un mode- e Generación de aplicaciones. El DRA asume la uti-lo de proceso del desarrollo del software lineal secuencial lización de técnicas de cuarta generación (Sección 2.10).que un ciclo de desarrollo extremadamente cor- En lugar de crear software con lenguajes de programa-to. El modelo DRA es una adaptación a «alta velocidad» ción de tercera generación, el proceso DRA trabaja paradel modelo lineal secuencial en el que se logra el desa- volver a utilizar componentes de programas ya exis-rrollo rápido utilizando una construcción basada en com- tentes (cuando es posible) o a crear componentesponentes. Si se comprenden bien los requisitos y se limita lizables (cuando sea necesario). En todos los casos seel ámbito del proyecto, el proceso DRA permite al equi- utilizan herramientas para facilitar la construcción delpo de desarrollo crear un completamente fun- software.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 Equipo 3enfoque DRA comprende las siguientes fases Modelado Modelado de Gestión. El flujo de información entre degestiónlas funciones de gestión se modela de forma que res-ponda a las siguientes preguntas: información con- Modelado Modeladoduce el proceso de gestión? información se genera? de gestión de datos la genera? dónde va la información?la procesa? El modelado de gestión se describe con más Modelado de procesosdetalle en el Capítulo 10. Modelado de datos Modelado de datos. El flujo de información defini- Generación dedo como parte de la fase de modelado de gestión se refi- aplicacionesna como un conjunto de objetos de datos necesarios para Modeladoapoyar la empresa. Se definen las características (lla- de procesosmadas atributos) de cada uno de los objetos y las rela-ciones entre estos objetos. El modelado de datos se trata Generaciónen 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 necesariopara Pruebasimplementar una función de gestión. Las descripciones y entregadel proceso se crean para añadir, modificar, suprimir, orecuperar un objeto de datos. En ingles: (Rapid Application Deveiopment) El FIGURA 2.6. modelo DRA. 22
  • 20. 2 EL PROCESO Pruebas y entrega. Como el proceso DRA Al igual que todos los modelos de proceso, el enfo-za la reutilización, ya se han comprobado muchos de que DRA tiene inconvenienteslos componentes de los programas. Esto reduce tiempo Para proyectos grandes aunque por escalas, el D R Ade pruebas. Sin embargo, se deben probar todos los com- requiere recursos humanos suficientes como paraponentes nuevos y se deben ejercitar todas las crear el número correcto de equipos DRA.ces a fondo. D R A requiere clientes y desarrolladores compro- metidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abre- EDRA l un fuerte de viado. Si no hay compromiso por ninguna de las par- Paro sobre el tes constituyentes, los proyectos DRA fracasarán. de véase el 27. No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modularizar adecuadamente, la construcción de los componentes El modelo de proceso DRA se ilustra en la Figura necesarios para DRA será problemático. S está en i2.6. Obviamente, las limitaciones de tiempo impuestas juego el alto rendimiento, y se va a conseguir el ren-en un proyecto DRA demandan «ámbito en escalas» dimiento convirtiendo interfaces en componentes de Si una aplicación de gestión puede sistemas, el enfoque DRA puede que no funcione.se de forma que permita completarse cada una de lasfunciones principales en menos de tres meses (utilizando DRA no es adecuado cuando los riesgos técnicos sonel enfoque descrito anteriormente), es un candidato del altos. Esto ocurre cuando una nueva aplicación haceDRA. Cada una de las funciones pueden ser afrontadas uso de tecnologías nuevas, o cuando el softwarepor un equipo DRA separado y ser integradas en un solo nuevo requiere un alto grado de interoperatividadconjunto. con programas de computadora ya existentes.Se reconoce que el software, al igual que todos los sis- 2.7.1. El modelo incrementaltemas complejos, evoluciona con el tiempo El modelo incrernental combina elementos del modeloLos requisitos de gestión y de productos a menudo cam- lineal secuencial (aplicados repetidamente) con la filo-bian conforme a que el desarrollo proceda haciendo que sofía interactiva de construcción de prototipos. Comoel camino que lleva al producto final no sea real; las muestra la Figura 2.7, el modelo incremental aplicaestrictas fechas tope del mercado hacen que sea impo- secuencias lineales de forma escalonada mientras pro-sible finalizar un producto completo, por lo que se debe gresa el tiempo en el calendario. Cada secuencia linealintroducir una versión limitada para cumplir la presión produce un «incremento» del software Porcompetitiva y de gestión; se comprende perfectamente ejemplo, el software de tratamiento de textos desarro-el conjunto de requisitos de productos centrales o del llado con el paradigma incremental podría extraer fun-sistema, pero todavía se tienen que definir los detalles ciones de gestión de archivos básicos y de producciónde extensiones del producto o sistema. En estas y en de documentos en el primer incremento; funciones deotras situaciones similares, los ingenieros del software edición más sofisticadas y de producción de documen-necesitan un modelo de proceso que se ha diseñado tos en el segundo incremento; corrección ortográfica yexplícitamente para acomodarse a un producto que evo- gramatical en el tercero; y una función avanzada delucione con el tiempo. esquema de página en el cuarto. Se debería tener en cuen- El modelo lineal secuencial (Sección 2.4) se diseña ta que el flujo del proceso de cualquier incremento pue-para el desarrollo en línea recta. En esencia, este enfo- de incorporarel paradigma de construcciónde prototipos.que en cascada asume que se va entregar un sistemacompleto una 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 Emodelo l entrega el software en partesse diseña para entregar un sistema de producción. En pero utilizables, llamadas ((incrementos).ninguno de los paradigmas de ingeniería del software En general, cado incrementose construye sobre aquélse tiene en cuenta la naturaleza evolutiva del software. que ya ho sido entregado. Los modelos evolutivos son iterativos. Se caracteri-zan por la forma en que permiten a los ingenieros del Cuando se utiliza un modelo incremental, el primersoftware desarrollar versiones cada vez más completas incremento a menudo es un producto esencial. Es decir,del software. se afrontan requisitos básicos, pero muchas funciones 23
  • 21. DEL SOFTWARE. UN ENFOQUE PRACTICOsuplementarias (algunas conocidas, otras no) quedan sin El modelo de proceso incremental, como la cons-extraer. El cliente utiliza el producto central (o sufre la trucción de prototipos (Sección 2.5) y otros enfoquesrevisión detallada). Como un resultado de utilización evolutivos, es iterativo por naturaleza. Pero a dife-de evaluación, se desarrolla un plan para el incremento rencia de la construcción de prototipos, el modelosiguiente. El plan afronta la modificación del producto incremental se centra en la entrega de un productocentral a fin de cumplir mejor las necesidades del clien- operacional con cada incremento. Los primeros incre-te y la entrega de funciones, y características adiciona- mentos son versiones del productoles. Este proceso se repite siguiendo la entrega de cada final, pero proporcionan al usuario la funcionalidadincremento, hasta que se elabore el producto completo. que precisa y también una plataforma para la eva- luación. El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para Cuando tenga una fecha de entrega imposible una implementación completa en la fecha límite que se de cambiar, el modela incremental es un buen haya establecido para el proyecto. Los primeros incre- a considerar. mentos se pueden implementar con menos personas. incremento 1 Prueba incremento , Código Prueba 2." incremento Diseño Código incremento Análisis Prueba incremento Tiempo de calendarioFIGURA 2.7. El modelo incremental.2.7.2. El modelo espiralEl modelo en espiral, propuesto originalmente porBoehm es un modelo de proceso de soft-ware evolutivo que conjuga la naturaleza iterativa deconstrucción de prototipos con los aspectos controla- nieriados y sistemáticos del modelo lineal secuencial. Pro-porciona el potencial para el desarrollo rápido de del clienteversiones incrementales del software. En el modeloespiral, el software se desarrolla en una serie de ver- Proyectode mantenimiento de productos.siones incrementales. Durante las primeras Proyectode mejora de productos. Proyecto de desarrollo de nuevos productos.nes, la version incremental podría ser un modelo en Proyecto de desarrollo de conceptos.papel o un prototipo. Durante las últimas iteraciones,se producen versiones cada vez más completas deltema diseñado. FIGURA 2.8. Un modelo espiral típico. 24
  • 22. 2 EL PROCESO El modelo en espiral se divide en un número de acti- más sofisticadas del software. Cada paso por la región de marco de trabajo, también llamadas regio- de planificación produce ajustes en el plan del proyec- de Generalmente, existen entre tres y seis to. El coste y la planificación se ajustan con laregiones de tareas. La Figura 2.8 representa un modelo mentacion ante la evaluación del cliente. Además, elen espiral que contiene seis regiones de tareas: gestor del proyecto ajusta el número planificado de comunicación con el cliente- las tareas requeridas raciones requeridas para completar el software. para establecer comunicación entre el desarrollador y el cliente. planificación- las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto. análisis de riesgos- las tareas requeridas para eva- Modelo de proceso adaptable. luar riesgos técnicos y de gestión. ingeniería- las tareas requeridas para construir una A diferencia del modelo de proceso clásico que ter- o más representaciones de la aplicación. mina cuando se entrega el software, el modelo en espi- construcción y acción- las tareas requeridas para ral puede adaptarse y aplicarse a lo largo de la vida del construir, probar, instalar y proporcionar soporte al software de computadora. Una visión alternativa del usuario (por ejemplo: documentación y práctica) modelo en espiral puede ser considerada examinando el eje de punto de entrada en el proyecto también refle- evaluación del cliente- las tareas requeridas para jado en la Figura 2.8. Cada uno de los cubos situados a obtener la reacción del cliente según la evaluación lo largo del eje pueden usarse para representar el pun- de las representaciones del software creadas durante to de arranque para diferentes tipos de proyectos. Un la etapa de ingeniería e implementada durante la de desarrollo de comienza en el etapa de instalación. centro 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 de actividades del marco de trabajo se aplican un producto real, el proceso continúa a través del cubo a cualquier proyecto de que realice, siguiente (punto de entrada del proyecto de desarrollo sin tener en cuenta el ni complejidad. del producto nuevo) y se inicia un proyecto de desarrollo”. El producto nuevo evolucionará a través de Cada una de las regiones están compuestas por un con- iteraciones alrededor de la espiral siguiendo el caminojunto de tareas del trabajo, llamado conjunto de tareas, que limita la región algo más brillante que elque se adaptan a las características del proyecto que va esencia, la espiral, cuando se caracteriza de esta forma,a emprenderse. Para proyectos pequeños, el número de permanece operativa hasta que el software se retira. Haytareas de trabajo y su formalidad es bajo. Para proyectos veces en que el proceso está inactivo, pero siempre quemayores y más críticos cada región de tareas contiene se inicie un cambio, el proceso arranca en el punto detareas de trabajo que se definen para lograr un nivel más entrada adecuado (por ejemplo: mejora del producto).alto de formalidad. los casos, se aplican las acti- El modelo en espiral es un enfoque realista del desa-vidades de protección (por ejemplo: gestión de configu- rrollo de sistemas y de software a gran escala. Como elración del software y garantía de calidad del software) software evoluciona, a medida que progresa el procesomencionadas en la Sección 2.2. el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evoluti- es un conjunto de vos. El modelo en espiral utiliza la construcción de pro- tareas? totipos como mecanismo de reducción de riesgos, pero, Cuando empieza este proceso evolutivo, el equipo lo que es más importante, permite a quien lo desarrollade ingeniería del software gira alrededor de la espiral aplicar el enfoque de construcción de prototipos en cual-en la dirección de las agujas del reloj, comenzando por quier etapa de evolución del producto. Mantiene el enfo-el centro. El primer circuito de la espiral puede produ- que sistemático de los pasos sugeridos por el ciclo decir el desarrollo de una especificación de productos; los vida clásico, pero lo incorpora al marco de trabajopasos siguientes en la espiral se podrían utilizar para rativo que refleja de forma más realista el mundo real.desarrollar un prototipo y progresivamente versiones El modelo en espiral demanda una consideración El modelo en espiral de esta sección es una 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
  • 23. DEL SOFTWARE. UN ENFOQUE PRACTICOta de los riesgos técnicos en todas las etapas del pro- El modelo en espiral WINWIN de Boehmyecto, y, si se aplica adecuadamente, debe reducir los define un conjuntode actividades de negociación al prin-riesgos antes de que se conviertan en problemáticos. cipio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente, se defi- nen las siguientes actividades: Identificación del sistema o subsistemas clave de los la Parte 2. Determinación de las «condiciones de victoria» de los directivos. Pero al igual que otros paradigmas, el modelo en 3. Negociación de las condiciones de «victoria» de losespiral no es la panacea. Puede resultar difícil conven- directivos para reunirlas en un conjunto de condi-cer a grandes clientes (particularmente en situaciones ciones «victoria-victoria» para todos los afectadosbajo contrato) de que el enfoque evolutivo es controla- (incluyendo el equipo del proyecto de software).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 de Habilidadesde negociaciónprototipos. Todavía tendrán que pasar muchos años antesde que se determine con absoluta certeza la eficacia deeste nuevo e importante paradigma. Conseguidos completamente estos pasos iniciales se logra un resultado «victoria-victoria», que será el crite- rio clave para continuar con la definición del sistema y2.7.3. El modelo espiral WINWIN del software. El modelo en espiral WINWIN se ilustra en la Figura 2.9.El modelo en espiral tratado en la Seccion 2.7.2 sugie-re una actividad del marco de trabajo que aborda la 2. Identificar las condiciones 3a. Reunir las condicionescomunicación con el cliente. El objetivo de esta activi- de victoria de victoria.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- y comentarios. 5. Definir el siguiente niveldimiento, y otros productos o características del siste- 6. Validar las del producto y del proceso,ma frente al coste y al tiempo de comercialización. definiciones incluyendo particiones. del producto y del proceso. FIGURA 2.9. El modelo en espiral WINWIN l a obtención de requisitos software requiere una negociación. Tiene éxito cuando ambas partes Además del énfasis realizado en la negociación ini- cial, el modelo en espiral WINWIN introduce tres hitos Las mejores negociaciones se esfuerzan en obtener en el proceso, llamados puntos de«victoria-victoria». Esto es, el cliente gana obteniendo que ayudan a establecer la completitud de un ciclo alre-el producto o sistema que satisface la mayor parte de dedor de la espiral y proporcionan hitos de decisiónsus el desarrollador gana trabajando para antes de continuar el proyecto de software.conseguir presupuestos y lograr una fecha de entrega En esencia, los puntos de fijación representan tresrealista. visiones diferentes del progreso mientras que el Hay docenas de libros escritos sobre habilidades en la negocia- Un directivo e s alguien e n la organización que tiene un interésción ej., una de las cosas mas directo, por el negocio, en el sistema o producto a construir y puedeimportantes que un ingeniero o gestor joven (oviejo) puede apren- ser premiado por un resultado con éxito o criticado si el esfuerzoder. Lea uno. falla. 26
  • 24. 2 EL PROCESOyecto recorre la espiral. El primer punto de fijación, des del usuario, las decisiones de la gestión y los resultados dellamado objetivos del ciclo de vida (OCV), define un las revisiones.conjunto de objetivos para cada actividad principal El modelo de proceso concurrente se puede repre-de ingeniería del software. Como ejemplo, de una par- sentar en forma de esquema como una serie de acti-te de OCV, un conjunto de objetivos asociados a la vidades técnicas importantes, tareas y estadosdefinición de los requisitos del del asociados a ellas. Por ejemplo, la actividad de inge-nivel más alto. El segundo punto de fijación, llama- niería definida para el modelo en espiral (Seccióndo arquitectura del ciclo de vida (ACV), establece los se lleva a cabo invocando las tareas siguien-objetivos que se deben conocer mientras que se defi- tes: modelado de construcción de prototipos aná-ne la arquitectura del software y el sistema. Como lisis, especificación de requisitos y diseño.ejemplo, de una parte de la ACV, el equipo del pro- La Figura 2.10 proporciona una representación esque-yecto de software debe demostrar que ha evaluado la mática de una actividad dentro del modelo de procesofuncionalidad de los componentes del software concurrente. La actividad -análisis-se puede encon-lizables y que ha considerado su impacto en las deci- trar en uno de los estados" destacados anteriormente ensiones de arquitectura. La capacidad operativa inicial cualquier momento dado. De forma similar, otras acti-(COI) es el tercer punto de fijación y representa un vidades (por ejemplo: diseño o comunicación con elconjunto de objetivos asociados a la preparación del cliente) se puede representar de una forma análoga.software para la preparación Todas las actividades existen concurrentemente, perodel lugar previamente a la instalación, y la asistencia residen en estados diferentes. Por ejemplo, al principioprecisada de todas las partes que utilizará o manten- del proyecto la actividad de comunicación con el clien-drá el software. te (no mostrada en la figura) ha finalizado su primera2.7.4. El modelo de desarrollo concurrente iteración y está en el estado de cambios,en espera. La actividad de análisis (que estaba en el estado ningunoDavis y Sitaram han descrito el modelo de mientras que se iniciaba la comunicación inicial con eldesarrollo concurrente, llamado algunas veces inge- cliente) ahora hace una transición al estado bajo desa-niería concurrente, de la forma siguiente: rrollo. Sin embargo, si el cliente indica que se deben Los gestores de proyectos que siguen los pasos del estado hacer cambios en requisitos, la actividad análisis cam-del proyecto en lo que se refiere a las fases importantes [del bia del estado bajo desarrollo al estado cambios enciclo de vida clásico] no tienen idea del estado de sus proyec-tos. Estos son ejemplos de un intento por seguir los pasos extre- espera.madamente complejos de actividades mediante modelos El modelo de proceso concurrente define una seriedemasiado simples. Tenga en cuenta que aunque un proyecto de acontecimientos que dispararán transiciones de[grande]esté en la fase de codificación, hay personal de ese pro- estado a estado para cada una de las actividades de layecto implicado en actividades asociadas generalmente a muchasfases de desarrollo simultáneamente. Por ejemplo, ... El perso- ingeniería del software. Por ejemplo, durante las pri-nal está escribiendo requisitos, diseñando, codificando, hacien- meras etapas del diseño, no se contempla una incon-do pruebas y probando la integración [todo al mismo tiempo]. sistencia del modelo de análisis. Esto genera laLos modelos de procesos de ingeniería del software de corrección del modelo de análisis de sucesos, que dis-rey y Kellner han mostrado la concurrencia parará la actividad de análisis del estado hecho alque existe para actividades que ocurren durante cualquier fase. estado cambios en espera.El trabajo más reciente de Kellner utiliza diagramasde estado [una notación que representa los estados de un pro- El modelo de proceso concurrente se utiliza a menu-ceso] para representar la relación concurrente que existe entre do como el paradigma de desarrollo de aplicacionesactividades asociadas a un acontecimiento específico (por ejem- (Capítulo 28). Un sistemaplo: un cambio de requisitos durante el último desarrollo), pero se compone de un conjunto de componentes funciona-falla en capturar la riqueza de la concurrencia que existe en todas les. Cuando se aplica a el modelo de pro-las actividades de desarrollo y de gestión del software en unproyecto. .. La mayoría de los modelos de procesos de desarro- ceso concurrente define actividades en dos dimensionesllo del software son dirigidos por el tiempo; cuanto más tarde una dimensión de sistemas y una dimensióndesea, más atrás se encontrará en el proceso de desarrollo. [Un componentes. Los aspectos del nivel de sistemas se afron-modelo de proceso concurrente] está dirigido por las necesida- tan mediante tres actividades: diseño, ensamblaje y uso.9 En funcionalidad del sejas que requieren un estudio sustancial. y del libroconsideran estos temas con más detalle. tadora más potente) que generalmente mantiene una base de datos centralizada. U estado es algún modo externamente observable del compor- ntamiento. 27
  • 25. DEL SOFTWARE. UN ENFOQUE PR A CTICOLa 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 sistemas y de compo-nentes ocurren simultáneamente y pueden modelarse conel enfoque orientado a objetos descrito anteriormente;(2)una aplicación típica se implementa conmuchos componentes, cada uno de los cuales se puedendiseñar y realizar concurrentemente. En realidad, el mode-lo de proceso concurrentees aplicable a todo tipo de desa- O Reperesenia un estado derrollo de software y proporciona una imagen exacta del una actividad de del software.estado actual de un proyecto. FIGURA 2.10. Un elemento del modelo de proceso concurrente.Las tecnologías de objetos Parte de este libro) pro- La actividad de la ingeniería comienza con la iden-porcionan el marco de trabajo técnico para un modelo tificación de clases candidatas. Esto se lleva a cabo exa-de proceso basado en componentes para la ingeniería minando los datos que se van a manejar por parte de ladel software. El paradigma orientado a objetos aplicación y el algoritmo que se va a aplicar para con-za la creación de clases que encapsulan tanto los datos seguir el Los datos y los algoritmos corres-como los algoritmos que se utilizan para manejar los pondientes se empaquetan en una clase.datos. Si se diseñan y se implementan adecuadamente, Las clases creadas en los proyectos de ingeniería dellas clases orientadas a objetos son reutilizables por las software anteriores, se almacenan en una biblioteca dediferentes aplicaciones y arquitecturas de sistemas basa- clases o diccionario de datos (repository) (Capítulo 3dos en computadora. Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si estas clases ya existen. 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 orientados objetos (Capítulos 2 1-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 construidas para cumplir necesidades Únicas de la aplicación. El flujo 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-FIGURA 2.1 Desarrollo basado en componentes. duce a la reutilización del software, y la reutilización pro- porciona beneficios a los ingenieros de software. Según El modelo de desarrollo basado en componentes (Fig. estudios de reutilización, QSM Associates, Inc. informa2.11) incorpora muchas de las características del mode- que el ensamblaje de componentes lleva a una reducciónlo en espiral. Es evolutivo por naturaleza y exi- del 70 por 100 de tiempo de ciclo de desarrollo, un 84ge un enfoque iterativo para la creación del software. por 100 del coste del proyecto y un índice de producti-Sin embargo, el modelo de desarrollo basado en com- vidad del 26.2, comparado con la norma de industria delponentes configura aplicaciones desde componentes pre- 16.9 Aunque estos resultados están en funciónparados de software (llamados en la Fig. 2.11). de la robustez de la biblioteca de componentes, no hay duda de que el ensamblaje de componentes proporciona en lo ventajas significativas para los ingenieros de software. El proceso unificado de desarrollo de software un estudio representa 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. Para un estudio más detallado, consulte el Capítulo 20. 28
  • 26. 2 EL PROCESOla industria. Utilizando el Lenguaje de Modelado Uni- to de vista usuario). Entonces acopla la función con (UML), el proceso unificado define los un marco de trabajo arquitectónico que identifica la for-nentes que se utilizarán para construir el sistema y las ma que tomará el software.interfaces que conectarán los componentes. Utilizandouna combinacion del desarrollo incremental e iterativo,el proceso unificado define la función del sistema apli- En los Capítulos 21 y 22 se trata con más detalle.cando un enfoque basado en escenarios (desde elEl modelo de métodos formales comprende un conjun- consiguientepermiten que el ingeniero del software des-to de actividades que conducen a la especificación mate- cubra y corrija errores que no se pudieron detectar demática del software de computadora. Los métodos otra manera.formales permiten que un ingeniero de software espe- Aunque todavía no hay un enfoque establecido, loscifique, desarrolle y verifique un sistema basado en com- modelos de métodos formales ofrecen la promesa de unputadora aplicando una notación rigurosa y matemática. software libre de defectos. Sin embargo, se ha habladoAlgunas organizaciones de desarrollo del software de una gran preocupación sobre su aplicabilidad en unactualmenteaplican una variación de este enfoque, lla- entorno de gestión:mado ingeniería del software de sala limpia El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo. 2. Se requiere un estudio detallado porque pocos res- los métodosformales se tratan en los Capítulos 25 y 26. ponsables del desarrollo de software tienen los ante- cedentes necesarios para aplicar métodos formales. Cuando se utilizan métodos formales (Capítulos 25 3. Es difícil utilizar los modelos como un mecanismoy 26) durante el desarrollo, proporcionan un mecanis- de comunicación con clientes que no tienen muchosmo para eliminar muchos de los problemas que son difí- conocimientos técnicos.ciles de superar con paradigmas de la ingeniería del No obstante es posible que el enfoque a través desoftware. La ambigüedad, lo incompleto y la inconsis- métodos formales tenga más partidarios entre los desa-tencia se descubren y se corrigen más fácilmente - no rrolladores del software que deben construir softwaremediante un revisión a propósito para el caso, sino de mucha seguridad (por ejemplo: los desarrolladoresmediante la aplicación del análisis matemático-. Cuan- de aviónica y dispositivos médicos), y entre los desa-do se utilizan métodos formales durante el diseño, sir- rrolladores que pasan grandes penurias económicas alven como basepara la verificación de programas y por aparecer errores de software.El término técnicas de cuarta generación abarca siguientes herramientas: lenguajes no procedimentalesun amplio espectro de herramientas de software que tie- de consulta a bases de datos, generación de informes,nen algo en común: todas facilitan al ingeniero del soft- manejo de datos, interacción y definición de pantallas,ware la especificación de algunas características del generación de códigos, capacidades gráficas de alto nivelsoftwarea alto nivel. Luego, la herramienta genera y capacidades de hoja de cálculo, y generación auto-máticamente el código fuente basándose en la especifi- matizada de HTML y lenguajes similaresutilizados paracación del técnico. Cada vez parece más evidente que la creación de sitios web usando herramientas de soft-cuanto mayor sea el nivel en el que se especifique el ware avanzado. Inicialmente, muchas de estas herra-software,más rápido se podrá construir el programa. El mientas estaban disponibles, pero sólo para ámbitos deparadigma T4G para la ingeniería del software se orien- aplicación muy específicos, pero actualmente losta hacia la posibilidad de especificar el software usan- nos T4G se han extendido a todas las categorías de apli-do formas de lenguaje especializado o notaciones caciones del software.gráficas que describa el problema que hay que resolver Al igual que otros paradigmas, T4G comienza conen términos que los entienda el cliente. Actualmente, el paso de reunión de requisitos. Idealmente, el clienteun entorno para el desarrollo de software que soporte describe los requisitos, que son, a continuación, tradu-el paradigma T4G puede incluir todas o algunas de las cidos directamente a un prototipo operativo. Sin 29
  • 27. DEL SOFTWARE. U N ENFOQUEgo, en la práctica no se puede hacer eso. El cliente pue- que facilite la realización del mantenimiento de formade que no esté seguro de lo que necesita; puede ser ambi- expeditiva.guo en la especificaciónde hechos que le son conocidos, Al igual que todos los paradigmas del software, ely puede que no sea capaz o no esté dispuesto a especi- modelo T4G tiene ventajas e inconvenientes. Los defen-ficar la información en la forma en que puede aceptar sores aducen reducciones drásticas en el tiempo de desa-una herramienta Por esta razón, el diálogo clien- rrollo del software y una mejora significativa en late-desarrollador descrito por los otros paradigmas sigue productividad de la gente que construye el software.siendo una parte esencial del enfoque Los detractores aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de programación, que el código fuente producido por tales herramientas es y que el manteni- utilice tiene que miento de grandes sistemas de software desarrollados del mediante T4G es cuestionable. el diseño y /os Hay algún mérito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado actual de Para aplicaciones pequeñas, se puede ir directamen- los enfoques dete desde el paso de recolección de requisitos al paso de El uso de T4G es un enfoque viable para muchas deimplementación, usando un lenguaje de cuarta genera- las diferentes áreas de aplicación. Junto con las herra-ción no procedimental o un modelo comprimi- mientas de ingeniería de software asistida por com-do de red de iconos gráficos. Sin embargo, es necesario putadora (CASE) y los generadores de código, T4Gun mayor esfuerzo para desarrollar una estrategia de ofrece una solución fiable a muchos problemas deldiseño para el sistema, incluso si se utiliza un El software.uso de T4G sin diseño (para grandes proyectos) causa- 2. Los datos recogidos en compañías que usan T4Grá las mismas dificultades (poca calidad, mantenimien- parecen indicar que el tiempo requerido para produ-to pobre, mala aceptación por el cliente) que se cir software se reduce mucho para aplicacionesencuentran cuando se desarrolla software mediante los pequeñas y de tamaño medio, y que la cantidad deenfoques convencionales. análisis y diseño para las aplicaciones pequeñas tam- La implementación mediante L4G permite, al que bién se reduce.desarrolla el software, centrarse en la representación delos resultados deseados, que es lo que se traduce 3. Sin embargo, el uso de T4G para grandes trabajos demáticamente en un código fuente que produce dichos desarrollo de software exige el mismo o más tiemporesultados. Obviamente, debe existir una estructura de de análisis, diseño y prueba (actividades de ingenie-datos con información relevante y a la que el L4G pue- ría del software), para lograr un ahorro sustancial deda acceder rápidamente. tiempo que puede conseguirse mediante la elimina- Para transformar una implementación T4G en un ción de la codificación.producto, el que lo desarrolla debe dirigir una prueba Resumiendo, las técnicas de cuarta generación ya secompleta, desarrollar con sentido una documentación han convertido en una parte importante del desarrolloy ejecutar el resto de las actividades de integración que de software. Cuando se combinan con enfoques deson también requeridas requeridas por otros ensamblaje de componentes (Sección el paradig-mas de ingeniería del software. Además, el software ma T4G se puede convertir en el enfoque dominantedesarrollado con T4G debe ser construido de forma hacia el desarrollo del software. OLos modelos de procesos tratados en las secciones ante- ción tratadas en la Sección 2.3. El modelo, presentadoriores se deben adaptar para utilizarse por el equipo del normalmente como una red, se puede analizar para deter-proyecto del software. Para conseguirlo, se han desarro- minar el flujo de trabajo típico y para examinar estruc-llado herramientas de tecnología de procesos para ayudar turas alternativas de procesos que pudieran llevar a una organizacionesde software a analizar los procesos actua- tiempo o coste de desarrollo reducidos.les, organizar tareas de trabajo, controlar y supervisar el Una vez que se ha creado un proceso aceptable, seprogreso y gestionar la calidad técnica pueden utilizar otras herramientas de tecnología de pro- Las herramientas de tecnología de procesos permi- cesos para asignar, supervisar e incluso controlar todasten que una organización de software construya un las tareas de ingeniería del software definidas como par-modelo automatizado del marco de trabajo común de te del modelo de proceso. Cada uno de los miembrosproceso, conjuntos de tareas y actividades de protec- de un equipo de proyecto de softwarepuede utilizar tales 30
  • 28. E L P R OC E S Oherramientas para desarrollar una lista de control de se puede utilizar para coordinar el uso de otras herra-tareas de trabajo a realizarse, productos de trabajo a pro- mientas de ingeniería del software asistida por compu-ducirse, y actividades de garantía de calidad a condu- tadora (Capítulo 3 1) adecuadas para una tarea de trabajocirse. La herramienta de tecnología de proceso también en particular. YSi el proceso es débil, el producto final va a sufrir indu- Toda actividad humana puede ser un proceso, pero uno dedablemente. Aunque una dependencia obsesiva en el nosotros obtiene el sentido de autoestima ante esas actividades que producen una representación o ejemplo que más de una personaproceso también es peligrosa. En un breve ensayo, puede utilizar o apreciar, una u otra vez, o en algún otro contextogaret Davis comenta la dualidad producto y no tenido en cuenta. Es decir, los sentimientos de satisfacción seproceso: obtienen por volver a utilizar nuestros productos por nosotros mis- Cada diez años o cinco aproximadamente,la comunidad del soft- mos o por otros.ware vuelve a definir «el problema» cambiando el foco de los aspec- Así pues, mientras que la asimilación rápida de los objetivostos de producto a los aspectos de proceso. Por consiguiente, se han de reutilización en el desarrollo del software aumenta potencial-abarcado lenguajes de programación estructurados (producto) segui- mente la satisfacción que los desarrolladores obtienen de su tra-dos por métodos de análisis estructurados (proceso) seguidos a su bajo, esto incrementa la urgencia de aceptar la dualidad productovez por encapsulaciónde datos (producto) y después por el énfasis y proceso. Pensar en un mecanismo reutilizable como el únicoactual en el Modelo Madurez de Capacidad de Desarrollo del soft- producto o el único proceso, bien oscurece el contexto y la formaware del Instituto de ingeniería de software (proceso). de utilizarlo, o bien el hecho de que cada utilización elabora el Mientras que la tendencia natural de un péndulo es parar en medio producto que a su vez se utilizará como entrada en alguna otrade dos extremos, el enfoque de la comunidad del software cambia actividad de desarrollo del software. Elegir un método sobre otroconstantemente porque se aplica una fuerza nueva cuando falla el reduce enormemente las oportunidades de reutilización y de aquí movimiento. Estos movimientos son perjudicialespor sí mis- que se pierda la oportunidad de aumentar la satisfacción ante elmos y en sí mismos porque confunden al desarrollador del softwa- trabajo.re medio cambiando radicalmente lo 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 enlugar de una dualidad. se aplica puede convertirse] en Las personas obtienen tanta satisfacción (o má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 la En la comunidad científica hay un precedente que se adelanta a búsqueda de la metáfora adecuada al igual que con ellas nociones de dualidad cuando contradicciones en observacionesno se pueden explicar completamente con una teoría competitiva u libro final. Un profesional creativo del software debe-otra. La naturaleza de la luz, que parece ser una partícula y una ría también obtener tanta satisfacción de la programa-onda al mismo tiempo, se ha aceptado desde los años veinte cuan- ción como del producto final.do Louis de lo propuso. Creo que las observaciones que se El trabajo de los profesionales del software cambia-hacen sobre los mecanismos del software y su desarrollo demues- rá en los próximos años. La dualidad de producto y pro-tran una dualidad fundamental entre producto y proceso. Nunca se ceso es un elemento importante para mantener ocupadapuede comprender el mecanismo completo, su contexto, uso, signi-ficado y valor si se observa sólo como un proceso o sólo como un a la gente hasta que se finalice la transición deproducto.. . la programación a la ingeniería del software.La ingeniería del software es una disciplina que inte- venientes, pero todos tienen una serie de fases gené-gra procesos, métodos y herramientas para el desa- ricas en común. En el resto de este libro se consideranrrollo del software de computadora. Se han propuesto los principios, conceptos y métodos que permiten lle-varios modelos de procesos para la ingeniería del soft- var a cabo el proceso que se llama ingeniería del soft-ware diferentes, cada uno exhibiendo ventajas e incon- ware. 31
  • 29. DEL SOFTWARE. U N ENFOQUE PRÁCTICO Baetjer, H., Jr., Software as Capital,IEEE Intl. Conference on Software Engineering, IEEE ter Society Press, 1998, 85. puter Society Press, pp. 331-342. Bandinelli, et al, and Improving an IEEE Standards Collection: Engineering, Industrial Software IEEE Software Engi- IEEE Standard 610.12-1990, IEEE, 1993. neering, vol. 2 5 , Mayo 1995, pp. 440-454. Jacobson, I., G. Booch y Rumbaugh, The Bradac, M., y Votta, a Software Developement Addison-Wesley, 1999. IEEE Trans. Software Engi- Kellner, M., Software Process Modeling: and neering, vol. 20, 10, Octubre 1994, pp. 774-784. Experience, Technical Review- 1989, SEI, Pittsburgh, Boehm, Spiral Model for Software PA, 1989. pement and Enhancement",Computer,vol. 21, 5 , Mayo Kellner, M., «Software Process Modeling Support 1988, 61-72. for Management Planning and Control», Proc. Intl. Boehm, the Software IEEE On the Process, IEEE Computer Society Software, vol. 13, 4, Julio 1996, pp.73-82. Press, 1991, pp. 8-28. Boehm, the WINWIN Spiral Model: A Kerr, y Hunter, 1994. Case Computer,vol. 31, 7, Julio 1998, pp. 44. Martin, Rapid Aplication Developement, tice-Hall, 1991. Brooks, The Man-Month, ley, 1975. y Rook, «Software Developement Process en Book, Butler, Aplication Developement CRC Press, 1993, pp. Managing Developement, Applied puter Research, vol. 14, 5 , Mayo 1995, pp. 6-8. H.D., M. Dyer y Soft- ware IEEE Software, Septiembre 1987, pp. Davis, A., y Sitaram, «A Concurrent Process 19-25. Model for Software Software ring Notes, ACM Press, vol. 19, 2, Abril 1994, pp. Naur, y (eds.), Engineering: 51. A Report on a Conference the NATO ce NATO, 1969. Davis, M.J., and Product: Dichotomy or Software Engineering Notes, ACM Press, vol. Nierstrasz, Software Deve- 20, 2, Abril 1995, pp. 17-18. CACM, vol. 35, 9, Septiembre 1992, pp. 160-165. Donaldson, M.C., y M. Donaldson,Negotiating for IDB Books Worldwide, 1996. Paulk, M., et al., Maturity Model for Dyer, M., The Cleanroom to Software», Software Engineering Institute, Carnegie ware Developement, 1992. University, Pittsburgh, PA, 1993. Farber, Sense Negotiation: The Art Raccoon, Chaos Model and the Chaos of Winning Gracefully, Bay Press, 1997. Life ACM Software Engineering Notes, vol. 20, 1, Enero 1995, pp. 55-66. Fisher, W. Ury y Bruce Patton, Getting to Yes: Negotiating Without Giving 2." ed., Penguin Royce, W.W., the Developement of Large USA, 1991. Software Systems: Concepts and Proc. CON, Agosto 1970. Gilb, T., of Software Engineering gement, Addison-Wesley, 1988. Sheleg, W., Engineering: A New dign for C/S Application Developement Hanna, M., to Software Trends, vol. 1, 6, Junio 1994, pp. 28-33. Magazine, Mayo 1995, pp.38-46. Yourdon, E., «Software Application Deve- Humphrey, W., y M. Kellner, «Software Process Strategies, vol. VI, 12, Diciembre 1994, pp. Modeling: Principles of Entity Process Proc. 1-16.2.1. La Figura 2.1 sitúa las tres capas de ingeniería del soft- 2.2. algún caso en que no se apliquen fases genéricasware encima de la capa titulada «enfoque de calidad». Esto del proceso de ingeniería del software? Si es así, descríbalo.implica un programa de calidad tal como Gestión de Cali- 2.3. El Modelo Avanzado de Capacidad del es un docu-dad Total. Investigue y desarrolle un esquema de los prin- mento en evolución. Investigue y determine si se han aña- clave de un programa de Gestión de Calidad Total. dido algunas ACP nuevas desde la publicación de este libro. 32
  • 30. 2 EL PROCESO2.4. El modelo del caos sugiere que un bucle de resolución de 2.8. Proponga un proyecto específico de software que sea ade-problemas se pueda aplicar en cualquier grado de resolución. cuado para el modelo incremental. Presente un escenario paraEstudie la forma en que se aplicaría el bucle para com- aplicar el modelo al software.prender los requisitos de un producto de tratamiento de texto; 2.9. A medida que vaya hacia afuera por el modelo en espiral,(2) para desarrollarun componente de corrección ortográfica puede decir del software que se está desarrollando o man-y gramática avanzado para el procesador de texto; (3) para teniendo?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.10. Muchas personas creen que la Única forma en la que se van a lograr mejoras de magnitud en la calidad del software y2.5. paradigmas de ingeniería del software de los presen- en su productividad es a través del desarrollo basado en com-tados en este capítulopiensa que sería el más eficaz? qué? ponentes. Encuentre tres o cuatro artículos recientes sobre el2.6. Proporcione cinco ejemplos de proyectos de desarrollo asunto y resúmalos para la clase.del software que sean adecuados para construir prototipos. 2.11. Describa el modelo de desarrollo concurrente con susNombre dos o tres aplicaciones que fueran más difíciles para propias palabras.construir prototipos. 2.12. Proporcione tres ejemplos de técnicas de cuarta genera-2.7. El modelo DRA a menudo se une a herramientas CASE. ción.Investiguela literatura y proporcione un resumen de una herra-mienta típica CASE que soporte DRA. 2.13. es más importante, el producto o el proceso?El estado actual del arte en la ingeniería del software se puede controvertidos y amenos sobre el software y el proceso de la mejor a partir de publicaciones mensuales tales como ingeniería del software. Pressman y Herron (SoftwareShock,IEEE Software, Computer e IEEE Transactions on Software Dorset House, 1991) consideran el software y su impactoEngineering.Periódicos sobre la industria tales como sobre particulares, empresas y el gobierno.tionDevelopement Trends,Cutter IT Journal y Software El Instituto de ingeniería del software localizado enlopement a menudo contienen artículos sobre temas de ingeniería la Universidad de Carnegie-Mellon) ha sido creado con ladel software. La disciplina se «resume» cada año en el responsabilidad de promocionar series monográficas sobreeding the International Conference on Software Engineering, la ingeniería del software. Los profesionales académicos,promocionadopor el IEEE y ACM y tratado en profundidad en en la industria y el gobierno están contribuyendo con nue-periódicos como ACM Transactions Software Engineering vos trabajos importantes. El Consorcio de Productividad deland Methodology,ACM Software Engineering Notes y Software dirige una investigación adicional de ingeniería Software Engineering. de software. Se han publicado muchos libros de ingeniería del softwa- En la última década se ha publicado una gran variedad dere en los últimos años. Algunos presentan una visión general estándares y procedimientos de ingeniería del software. El IEEEdel proceso entero mientras que otros se dedican a unos pocos Software Engineering Standards contiene muchos estándarestemas importantes para la exclusión de otros. Las siguientes diferentes que abarcan casi todos los aspectos importantes deson tres antologías que abarcan algunos temas importantes la tecnología. Las directrices ISO 9000-3 proporcionan unade ingeniería del software: guía para las organizaciones de software que requieren un regis- Keyes, (ed.), Engineering Productivity tro en el de calidad ISO 9001. Otros estándares debook, 1993. ingeniería del software se pueden obtener desde el MOD, la (ed.), Software Reference Book, Autoridad Civil de Aviación y otras agencias del gobierno yCRC Press, 1993. sin ánimo de lucro. Fairclough (SoftwareEngineering Guides, Marchiniak, J.J. (ed.), Encyclopedia Software Prentice-Hall, 1996) proporciona una referencia detallada deering, Wiley, 1994. los estándares de ingeniería del software producidos por Gautier (Distributed Engineering Software, pean Space Agency (ESA).Hall, 1996)proporciona sugerencias y directrices para orga- En internet se dispone de una gran variedad de fuentes denizaciones que deban desarrollar software en lugares información sobre la ingeniería del software y del proceso degeográficamentedistantes. software. Se puede encontrar una lista actualizada con refe- En la parte más brillante del libro de Robert Glass (Soft- rencias a sitios (páginas) web que son relevantes para el pro-ware Yourdon Press, 1991) se presentan ensayos ceso del software en http://www.pressman5.com. 33
  • 31. PARTEII DE PROYECTOS DE SOFTWARE U n enfoque Práctico, estudiamos organizar, supervisar vienen a ema durante un de software? y cómo pueden emplearse para nar un proyecto e y el proceso del software? genera e software estimaciones fiables del esfuerzo, costes y duración del proyecto? 35
  • 32. CONCEPTOS SOBRE GESTION DE PROYECTOS E N el prefacio de su libro sobre gestión de proyectos de software, Meiler Page-Jones ware: dice una frase que pueden corroborar muchos asesores de ingeniería del soft- 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 que entregaban sistemas que decepcionaban a sus usuarios y que devoraban ingentes cantidades de horas de mantenimiento. Lo 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 se encontrara 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 a una 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 y del 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 correcta supervisión, reducción y gestión del riesgo se presentan en el Capítulo 6. El Capítulo 7 estudia las 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 una aplicación.tomamos la visión de falta una software de comnecesaria cuando se plan define el proceso y las tareas ay control del perso realizar el personal que eld e los eventos que y los mecanismos para evaluar los puedo seguro de que hecho estás completamente segurod e que el alcance del producto y los requisi- alta calidad dentro del tiempo y del tos. Debe seleccionarse el proceso presupuesto. Sin embargo, un gestor Y adecuado para el personal, y el pro- d e proyectos hace lo correcto cuandotécnicas. Los gestores d El proyecto debe planificarse estimula a l personal para trabajar Y estimando el esfuerzo y el tiempo tos como un equipo efectivo, centran- para cumplir l a s tareas; definiendo do su atención en las necesidades del los productos del trabajo, estable- cliente y en la calidad del producto. 37
  • 33. DEL SOFTWARE. U N ENFOQUE PRÁCTICOLa gestión eficaz de un proyecto de software se cen- 3.1.2. Productotra en las cuatro P’s: personal, producto, proceso y Antes de poder planificar un proyecto, se deberían esta-proyecto. El orden no es arbitrario. El gestor que se blecer los objetivos y el ámbito del producto‘, se debe-olvida de que el trabajo de ingeniería del software es rían considerar soluciones alternativas e identificar lasun esfuerzo humano intenso nunca tendrá éxito en la dificultades técnicas y de gestión. Sin esta información,gestión de proyectos. Un gestor que no fomenta una es imposible definir unas estimaciones razonables (yminuciosa comunicación con el cliente al principio exactas) del coste; una valoración efectiva del riesgo,de la evolución del proyecto se arriesga a construir una subdivisión realista de las tareas del proyecto o unauna elegante solución para un problema equivocado. planificación del proyecto asequible que proporcioneEl administrador que presta poca atención al proce- una indicación fiable del progreso.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. En 1 se una taxonomía de las de producen los de software.3.1.1. PersonalLa necesidad de contar con personal para el desarrollodel software altamente preparado y motivado se viene El desarrollador de software y el cliente deben reunir-discutiendo desde los años 60 (por ejemplo, se para definir los objetivos del producto y su ámbito. En De hecho, el humano» es tan muchos casos, esta actividad empieza como parte del pro-importante que el Instituto de Ingeniería del Software ceso de ingeniería del sistema o del negocio (Capítuloha desarrollado un Modelo de madurez de la capacidad y continúa como el primer paso en el análisis de los requi- gestión de personal (MMCGP) aumentar la sitos del software (Capítulo 11). Los objetivos identificanpreparación de organizaciones del software para llevar las metas generales del proyecto sin considerar cómo sea cabo las cada vez más complicadas aplicaciones ayu- conseguirán (desde el punto de vista del cliente).dando a atraer, aumentar, motivar, desplegar y retener El ámbito identifica los datos primarios, funciones yel talento necesario para mejorar su capacidad de desa- comportamientos que caracterizan al producto, y, másrrollo de software» importante, intenta abordar estas características de una manera cuantitativa. Una vez que se han entendidolos objetivosy el ámbi- to del producto, se consideran soluciones alternativas. 3.1.3. Proceso Un proceso de software (Capítulo 2) proporciona la estructura desde la que se puede establecer un detalla- do plan para el desarrollo del software. Un pequeño El modelo de madurez de gestión de personal defi- número de actividades estructurales se puede aplicar ane las siguientes áreas clave prácticas para el personal todos los proyectos de software, sin tener en cuenta suque desarrolla software: reclutamiento, selección, ges- tamaño o complejidad. Diferentes conjuntos de tareastión de rendimiento, entrenamiento, retribución, desa- -tareas,hitos, productos del trabajo y puntos de garan-rrollo de la carrera, diseño de la organización y del tía de calidad-permiten a las actividades estructura-trabajo y desarrollo cultural y de espíritu de equipo. les adaptarse a las características del proyecto de El MMCGP es compañero del modelo de madurez software y a los requisitos del equipo del proyecto. Final-de la capacidad software (Capítulo 2), que guía a las mente, las actividades protectoras -talescomo garan-organizaciones en la creación de un proceso de software tía de calidad del software, gestión de la configuraciónmaduro. Más adelante en este capítulo se consideran del software y medición-cubren el modelo de proce-aspectos asociados a la gestión de personal y estructu- so. Las actividades protectoras son independientes deras para proyectos de software. las 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 en computadora, software empotrado y software de resolución de pro- blemas (por ejemplo, programas para la resolución de problemas ingeniería). 38
  • 34. 3 CONCEPTOS SOBRE DE PROYECTOS por 100 experimentaron un desbordamiento en la pla- nificación y en el coste Aunque la proporción c VE de éxito para los proyectos de software ha mejorado un las actividades estructurales se componende tareas, hitos, poco, nuestra proporción de fracaso de proyecto per- productos de y puntos de de calidad. 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 que3.1.4. Proyecto construyeron el producto deben eludir un conjunto deDirigimos los proyectos de software planificados y con- señales de peligro comunes; comprender los factorestrolados por una razón principal -es la Única manera del éxito críticos que conducen a la gestión correcta delconocida de gestionar la complejidad-. Y todavía proyecto y desarrollar un enfoque de sentido comúnseguimos esforzándonos. En 1998, los datos de la indus- para planificar, supervisar y controlar el proyecto. Cadatria del software indicaron que el 26 por 100 de pro- uno de estos aspectos se trata en la Sección 3.5 y en losyectos de software fallaron completamente y que el 46 capítulos siguientes.En un estudio publicado por el IEEE se les del software, damos este aspecto por descontado. Lospreguntó a los vicepresidentes ingenieros de tres gran- gestores argumentan (como el grupo anterior) que eldes compañías tecnológicas sobre el factor más impor- personal es algo primario, pero los hechos desmiententante que contribuye al éxito de un proyecto de software. a veces sus palabras.Respondieron de la siguiente manera: En esta sección examinamoslos participantes que cola- VP 1: Supongo que si tuviera que elegir lo más importante boran en el proceso del software y la manera en que se de nuestro entorno de trabajo, diría que no son las organizan para realizar una ingeniería del Software eficaz. herramientas que empleamos, es la gente. VP 2: El ingrediente más importante que contribuyó éxi- 3.2.1. Los participantes to de este proyecto fue tener gente lista ...pocas cosas más importan en mi opinión ... Lo más importante El proceso del software (y todos los proyectos de soft- que se puede hacer por un proyecto es seleccionar el ware) lo componen participantes que pueden clasificarse personal ... El éxito de la organización de desarrollo en una de estas cinco categorías: del software está muy, muy asociado con la habili- 1. Gestores superiores, que definen los aspectos de dad de reclutar buenos profesionales. negocios que a menudo tienen una significativa VP 3: La única regla que tengo en cuanto a la gestión influencia en el proyecto. es asegurarme de que tengo buenos profesionales -genterealmente buena-, de que preparo bue- 2. Gestores (técnicos)del proyecto, que deben planifi- na gente y de que proporciono el entorno en el car, motivar, organizar y controlar a los profesiona- que los buenos profesionales puedan producir. les que realizan el trabajo de software. 3. Profesionales, que proporcionan las capacidades téc- nicas necesarias para la ingeniería de un producto o aplicación. 4. Clientes, que especifican los requisitos para la inge- niería del software y otros elementos que tienen menor influencia en el resultado. 5. Usuarios que interaccionan con el software Ciertamente, éste es un testimonio convincente sobre una vez que se ha entregado para la producción.la importanciadel personal en el proceso de ingeniería Para ser eficaz,el equipo del proyecto debe organizarsedel software. Y, sin embargo, todos nosotros, desde los de manera que maximice las y capacidadesveteranos vicepresidentes al más modesto profesional de cada persona. Y este es el trabajo del jefe del equipo. Dadas estas estadísticas, es razonable preguntarse cómo el impacto de 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 estos proyectos 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 como ellos habían pensado), y los proyectos son cancelados. 39
  • 35. DEL SOFTWARE. UN ENFOQUE PRACTICO3.2.2. Los jefes de equipo Incentivos por logros. Para optimizar la productividad de un equipo de proyecto, un gestor debe recompensar la inicia-La gestión de un proyecto es una actividad intensamente tiva y los logros, y demostrar a través de sus propias accioneshumana, y por esta razón, los profesionales competen- que no se penalizará si se corren riesgos controlados.tes del software a menudo no son buenos jefes de equi- Influencia y construcciónde espíritu de equipo. Un ges-po. Simplemente no tienen la mezcla adecuada de tor de proyecto eficiente debe ser capaz de a la gente;capacidades del personal. Y sin embargo, como dice debe ser capaz de entender señales verbales y no verbales yEdgemon: «Desafortunadamente y con demasiada fre- reaccionar ante las necesidades de las personas que mandancuencia, hay individuos que terminan en la gestión de esas señales. El gestor debe mantener el control en situacionesproyectos y se convierten en gestores de proyecto acci- de gran estrés.dentales» qué nos fijamos cuando seleccionamos a alguien para Un experto de puede no tener deseo de ser jefe de equipo. fuerce experto poro ser conducir un proyecto de software? uno de ellos. En un excelente libro sobre gestión técnica, JerryWeinberg sugiere el modelo de gestión MOI: 3.2.3. El equipo de software Motivación.La habilidad para motivar (con un y aflo- Existen casi tantas estructuras de organizaciónde perso- ja») personal técnico para que produzca a sus mejo- res capacidades. nal para el desarrollo de software como organizaciones que se dedican a ello. Para bien o para mal, el organi- Organización. La habilidad para amoldar procesos exis- grama no puede cambiarse fácilmente. Las consecuen- tentes (oinventar unos nuevos) que permita al concepto inicial transformarse en un producto cias prácticas y políticas de un cambio de organización no están dentro del alcance de las responsabilidades del Ideas o innovación. La habilidad para motivar al personal gestor de un proyecto de software. Sin embargo, la orga- para crear y sentirse creativos incluso cuando deban de traba- jar dentro de los límites establecidos para un producto o apli- nización del personal directamente involucrado en un cación de software particular. nuevo proyecto de software está dentro del ámbito del gestor del proyecto. Las siguientes opciones pueden aplicarse a los recur- sos humanos de un proyecto que requiere n personas trabajando durante k años: 1. n individuos son asignados a m diferentes tareas fun- cionales, tiene lugar relativamente poco trabajo con- junto; la coordinación es responsabilidad del gestor del software que puede que tenga otros seis proyec- Weinberg sugiere que el éxito de los gestores de pro- tos de los que preocuparse.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 problemaque 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 2. individuos son asignados a m diferentes tareas fun-que definen a un gestor de proyectos eficiente resalta cionales de manera que se establecen «equi-cuatro apartados clave: pos~ informales; se puede nombrar un líder al efecto; Resolución del problema. Un gestor eficiente de un pro- la coordinación entre los equipos es responsabilidad yecto de software puede diagnosticar los aspectos técnicos y de organización más relevantes, estructurar una solución de un gestor del software. máticamente o motivar apropiadamente a otros profesionales 3. n individuos se organizan en t equipos; a cada equipo para que desarrollen la solución, aplicar las lecciones aprendi- se le asignan una o más tareas funcionales; cada das de anteriores proyectos a las nuevas situaciones, mante- equipo tiene una estructura específica que se define nerse lo suficientementeflexible para cambiar la gestión si los para todos los equipos que trabajan en el proyecto; intentos iniciales de resolver el problema no dan resultado. la coordinación es controlada por el equipo y por el Dotes de gestión. Un buen gestor de proyectos debe tomar gestor del proyecto de software. las riendas. Debe tener confianza para asumir el control cuan- do sea necesario y garantía para permitir que los buenos téc- Aunque es posible encontrar argumentos en pro y en nicos sigan sus instintos. contra para cada uno de los enfoques anteriores, existe 40
  • 36. 3 CONCEPTOS SOBRE DE PROYECTOSuna gran evidencia que indica que una organización de jar problemas sencillos. Los equipos descentralizadosequipo formal (opción 3) es la más productiva. generan más y mejores soluciones que los individua- La «mejor» estructura de equipo depende del esti- les. Por tanto, estos equipos tienen más probabilidadeslo de gestión de una organización, el número de per- de éxito en la resolución de problemas complejos. Pues-sonas que compondrá el equipo, sus niveles de to que el equipo DC es centralizado para la resoluciónpreparación y la dificultad general del problema. Man- de problemas, tanto el organigrama de equipo DC comotei sugiere tres organigramas de equipo el de CC pueden aplicarse con éxito para problemasgenéricos: sencillos. La estructura DD es la mejor para problemas Descentralizado democrático Este equipo de difíciles. ingeniería del software no tiene un jefe permanente. Más Como el rendimiento de un equipo es inversamente bien, nombran coordinadores de tareas a corto plazo y proporcional a la cantidad de comunicación que se debe se sustituyen por otros para diferentes Las entablar, los proyectos muy grandes son mejor dirigi- sobre problemas y los enfoques se hacen por con- dos por equipos con estructura CC o DC, donde se pue- senso del grupo. La comunicación entre los miembros del equipo es horizontal. den formar fácilmente subgrupos. El tiempo que los miembros del equipo vayan a juntos» afecta a la moral del equipo. Se ha des- debería estar cubierto que los organigramas de equipo tipo DD pro- organizado un equipo ducen una moral más alta y más satisfacción por el de software? trabajo y son, por tanto, buenos para equipos que per- manecerán juntos durante mucho tiempo. Descentralizado controlado (DC). Este equipo de inge- El organigrama de equipo DD se aplica mejor a pro- niería del software tiene un jefe definido que coordina tare- blemas con modularidad relativamente baja, debido a as específicas y jefes secundarios que tienen responsabilidades sobre subtareas. La resolución de problemas sigue siendo la gran cantidad de comunicación que se necesita. Los una actividad del grupo, pero la implementación de solu- organigramas CC o DC funcionan bien cuando es posi- ciones se reparte entre subgrupos por el jefe de equipo. La ble una modularidad alta (y la gente puede hacer cada comunicación entre subgrupos e individuos es horizontal. uno lo suyo). También hay comunicación vertical a lo largo de la jerarquía de control. Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coor- dinación interna del equipo. La comunicación entre el jefe y Frecuentementees mejor tener pocos equipos pequeños, los miembros del equipo es vertical. bien centrados que un gran equipo solamente. Mantei describe siete factores de un pro-yecto que deberían considerarse cuando se planifica el Los equipos CC y DC producen menos defectos queorganigrama de equipos de ingeniería del software: los equipos DD, pero estos datos tienen mucho que ver la dificultad del problema que hay que resolver con las actividades específicas de garantía de calidad el tamaño del líneas de que aplica el equipo. Los equipos descentralizados código o puntos de función (Capítulo 4) requieren generalmente más tiempo para completar un proyecto que un organigrama centralizado y al mismo el tiempo que el equipo estará junto (tiempo de vida tiempo son mejores cuando se precisa una gran canti- del equipo) dad de comunicación. el grado en que el problema puede ser Constantine sugiere cuatro zado de organización» para equipos de ingeniería del soft- ware: factores 1. Un paradigma cerrado estructura a un equipo con deberíamos considerar una jerarquía tradicional de autoridad (similar al cuando estructuramos equipo CC). Estos equipos trabajan bien cuando pro- un equipo de software? ducen software similar a otros anteriores, pero pro- bablemente sean menos innovadores cuando trabajen dentro de un paradigma cerrado. la calidad requerida y fiabilidad del sistema que se va a construir 2. El paradigma aleatorio estructura al equipo libre- mente y depende de la iniciativa individual de los la rigidez de la fecha de entrega miembros del equipo. Cuando se requiere innova- el grado de sociabilidad (comunicación) requerido ción o avances tecnológicos, los equipos de para- para el proyecto digma aleatorio son excelentes. Pero estos equipos Debido a que una estructura centralizada realiza las pueden chocar cuando se requiere un «rendimientotareas más rápidamente, es la más adecuada para mane- ordenado». 41
  • 37. DEL SOFTWARE. U N ENFOQUE3. El paradigma abierto intenta estructurar a un equipo nen una definición común de éxito o un espíritu de equi- de manera que consiga algunos de los controles aso- po identificable. Lo que falta es un fenómeno que deno- minamos cuajar. ciados con el paradigma cerrado, pero también mucha de la innovación que tiene lugar cuando se Un equipo cuajado es un grupo de gente tejido tan fuer- utiliza el paradigma aleatorio. El trabajo se desa- temente que el todo es mayor que la suma de las partes ... rrolla en colaboración, con mucha comunicación y Una vez que el equipo empieza a cuajar, la probabilidad toma de decisiones consensuadas y con el sello de de éxito empieza a subir. El equipo puede convertirse en imparable, un monstruo de éxito ... No necesitan ser dirigi- los equipos de paradigma abierto. Los organigra- dos de una manera tradicional y no necesitan que se les moti- mas de equipo de paradigma abierto son adecuados ve. Están en su gran momento. para la resolución de problemas complejos, pero pueden no tener un rendimiento tan eficiente como DeMarco y Lister mantienen que los miembros de otros equipos. 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, en muchos 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 un entorno de equipo tóxico potencial»:4. El paradigma se basa en la mentación natural de un problema y organiza los miembros del equipo para trabajar en partes del pro- blema con poca comunicación activa entre ellos. Constantine propone una variación en elequipo descentralizado democrático defendiendo a losequipos con independencia cuyo enfoque detrabajo podría ser mejor llamado «anarquía innova-dora». Aunque se haya apelado al enfoque de libre 1. una atmósfera de trabajo frenética en la que losespíritu para el desarrollo del software, el objetivo miembros del equipo gastan energía y se descentranprincipal de una organización de Ingeniería del Soft- de los objetivos del trabajo a desarrollar;ware debe ser «convertir el caos en un equipo de alto 2. alta frustración causada por factores tecnológicos,rendimiento» Para conseguir un equipo de del negocio, o personales que provocan fricción entrealto rendimiento. los miembros del equipo; Los miembros del equipo deben confiar unos en otros. 3. «procedimientos coordinados pobremente o frag- mentados» o una definición pobre o impropiamente La distribución de habilidades debe adecuarse al pro- elegida del modelo de procesos que se convierte en blema. un obstáculo a saltar; Para mantener la unión del equipo, los 4. definición confusa de los papeles a desempeñar pro- tas tienen que ser excluidos del mismo duciendo una falta de responsabilidad y la acusación Cualquiera que sea la organización del equipo, el correspondiente, yobjetivo para todos los gestores de proyecto es colabo- 5. «continua y repetida exposición al fallo» que con-rar a crear un equipo que presente cohesión. En su libro, duce a una pérdida de confianza y a una caída de laPeopfeware,DeMarco y Lister estudian este moral.aspecto: Jackman sugiere varios antitóxicos que tratan los problemas destacados Para evitar un entorno de trabajo frenético, el gestor de proyectos debería estar seguro de que el Epapel del l existe sin tener en cuento lo estructura del equipo. Poro más detalles equipo tiene acceso a toda la información requerida el 9. 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, Tendemos a usar la palabra equipo demasiado libre- mente en el mundo de los negocios, denominando «equi- sino entregarse al equipo tan pronto como fuese posi- po» a cualquier grupo de gente asignado para trabajar junta. ble (mientras haya tiempo para reaccionar de un modo Pero muchos de estos grupos no parecen equipos. No tie- racional y controlado). 42
  • 38. 3 CONCEPTOS SOBRE DE PROYECTOS presenta un argumento lógico, de un modo ordenado. Otros son intuitivos, pudiendo tomar una decisión basán- los equipos son lo pero no es dose en sus «sensaciones».Algunos desarrolladorespre- conseguirlos.Como mínimo, esté seguro de fieren una planificación detallada compuesta por tareas un organizadas que les permita lograr el cierre para algún elemento de un proyecto. Otros prefieren un entorno Aunque la frustración tiene muchas causas, los desa- más espontáneo donde aspectos abiertos son correctos.rrolladores de software a menudo la sienten cuando pier- Algunos trabajan duro para tener las cosas hechas muchoden la autoridad para controlar la situación. Un equipo antes de la fecha de un hito, de ese modo eliminan lade software puede evitar la frustración si recibe tanta presión cuando se aproximan a las fechas, mientras queresponsabilidad para la toma de decisiones como sea otros están apurados por las prisas para hacer la entre-posible. Cuanto más control se le de al equipo para tomar ga en el Último minuto. Un estudio detallado de la psi-decisiones técnicas y del proceso, menos frustración cología de estos rasgos y de las formas en las que unsentiran los miembros del equipo. jefe de equipo cualificado puede ayudar a la gente con Una elección inapropiada del proceso del software rasgos opuestos para trabajar juntos está fuera del ámbi-(p.ej.,tareas innecesarias o pesadas, pobre elección de to de éste libro4. Sin embargo, es importante destacarlos productos del trabajo) puede ser evitada de dos for- que el reconocimiento de las diferencias humanas es elmas: (1) estando seguros de que las características del primer paso hacia la creación de equipos que cuajan.software a construir se ajustan al rigor del proceso ele-gido, y (2) permitiendo al equipo seleccionar el proce- 3.2.4. Aspectos sobre la coordinaciónso (con el reconocimiento completo de que, una vez y la comunicaciónelegido, el equipo tiene la responsabilidad de entregarun producto de alta calidad). Hay muchos motivos por los que los proyectos de soft- El gestor de proyectos de software, trabajando ware pueden tener problemas. La escala (tamaño) dejunto con el equipo, debería refinar claramente los roles muchos esfuerzos de desarrollo es grande, conduciendoy las responsabilidades antes del comienzo del proyec- a complejidades, confusión y dificultades significativasto. El equipo debería establecer su propios mecanismos para coordinar a los miembros del equipo. La incerti-para la responsabilidad (las revisiones técnicas dumbre es corriente, dando como resultado un continuo son una forma para realizar esto) y definir una serie flujo de cambios que impactan al equipo del proyecto.de enfoques correctivos cuando un miembro del equi- La interoperatividad se ha convertido en una caracterís-po falla en el desarrollo. tica clave de muchos sistemas. El software nuevo debe Todo equipo de software experimentapequeños fallos. comunicarse con el anterior y ajustarse a restriccionesLa clave para eliminar una atmósfera de fallos será esta- predefinidas impuestas por el sistema o el producto.blecer técnicas basadas en el equipo para retroalimentary 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. Estas características del software moderno debemos evitar la, incertidumbre e interoperatividad-son aspectos de «toxinas» que con frecuencia la vida. Para enfrentarse a ellos eficazmente, un equi- infectan un equipo de software? po de ingeniería del software debe establecer métodos efectivos para coordinar a la gente que realiza el tra- Además de las cinco toxinas descritas por Jackman, bajo. Para lograr esto se deben establecer mecanismosun equipo de software a menudo se enfrenta con los ras- de comunicación formales e informales entre los miem-gos humanos diferentes de sus miembros. Algunos bros del equipo y entre múltiples equipos. La comuni-miembros del equipo son extrovertidos, otros son cación formal se lleva a cabo «por escrito, con reunionesvertidos. Algunas personas recogen información organizadas y otros canales de comunicación relativa-tivamente, separando amplios conceptos de hechos mente no interactivos e impersonales» Ladispares. Otros procesan la información linealmente, comunicación informal es más personal. Los miembrosreuniendo y organizando detalles minuciosos de los de un equipo de software comparten ideas de por sí,datos proporcionados. Algunos miembros del equipo piden ayuda a medida que surgen los problemas etoman las decisiones apropiadas solamente cuando se actúan los unos con los otros diariamente. Las revisiones técnicas formales se tratan con detalle en el Capi- Se puede encontrar una excelente introducción a estos temas rela-tulo 8. cionados con los equipos de proyectos de software en 43
  • 39. DEL S O FTWARE . UN ENFOQUE a productos de ingeniería del software. Estos incluyen reu- discusión entre niones de revisión de estado e inspecciones de diseño y de código. hitos del proyecto revisiones de de seguimiento coordinar de errores las acciones de los miembros correo electrónico del equipo? inspecciones de código o boletines del proyecto 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 del personal de desarrollo». Comunicación electrónica. Comprende correo electróni- herramientas de control del proyecto 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 pero 3 4 5 6 que pueden tener o una profunda visión que pue- empleo de la técnica de coordinación de ayudar a los miembros del equipo. Enfoque impersonal, formal Para valorar la eficacia de estas técnicas para la coor- Procedimiento formal o Procedimiento informal dinación de proyectos, Kraul y Streeter estudiaron 65 o Comunicación electrónica proyectos de software con cientos de personas implica- A Red das. La Figura 3.1 (adaptada de expresa el valor y empleo de las técnicas de coordinación apunta- das anteriormente. En la figura, el valor percibido (cla-FIGURA 3.1. Valor y empleo de técnicas de coordinación sificadoen una escala de siete puntos) de varias técnicas y comunicación. de comunicación y coordinación es contrastado con su frecuencia de empleo en un proyecto. Las técnicas situa- Kraul y Streeter examinan una colección das por encima de la línea de regresión fueron «juzga-de técnicas de coordinación de proyectos que se das como relativamente valiosas, dado la cantidad degorizan de la siguiente manera: veces que se Las técnicas situa- Formal, enfoque impersonal. Incluyen documentos de das por debajo de la línea se consideraronde menor valor. ingeniería del software y entregas (incluyendo el código fuen- Es interesante resaltar que las redes interpersonales fue- te), memorandos técnicos, hitos del proyecto, planificacio- nes del programa y herramientas de control del proyecto ron catalogadas como las técnicas de mayor valor de (Capítulo 7), peticiones de cambios y documentación relati- coordinación y de comunicación. Es también importan- va (Capítulo 9), informes de seguimiento de errores e infor- te hacer notar que los primeros mecanismos de garantía mación almacenada (Capítulo 3 1). de calidad del software (requisitos y revisiones de dise- Formal, procedimientos interpersonales. Se centra en ño) parecieron tener más valor que evaluaciones poste- las actividades de garantía de calidad (Capítulo 8) aplicada riores de código fuente (inspecciones de código).El gestor de un proyecto de software se enfrenta a un dile- 3.3.1. Ámbito del softwarema al inicio de un proyecto de ingeniería del software. La primera actividad de gestión de un proyecto de soft-Se requieren estimaciones cuantitativas y un plan orga- ware es determinar el ámbito del software. El ámbito senizado, pero no se dispone de información sólida. Un define respondiendo a las siguientes cuestiones:aná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 Si no puede de/regularmente a medida que progresa el proyecto. Y, aún que intento considere característica como un riesgo de/ proyecto.así, se necesita un plan Por tanto, debemos examinar el producto y el Contexto. encaja el software a construirblema a resolver justo al inicio del proyecto. Por lo en un sistema, producto o contexto de negociosmenos se debe establecer el ámbito del producto y mayor y qué limitaciones se imponen como resulta-delimitarlo. do del contexto? 44
  • 40. 3 CONCEPTOS SOBRE DE PROYECTOS Objetivosde información. objetos de datos Las funciones del software, descritas en la exposi- visibles al cliente (Capítulo 11)se obtienen del softwa- ción del ámbito, se evalúan y refinan para proporcionar re? objetos de datos son requeridos de entrada? más detalle antes del comienzo de la estimación (Capí- Función y rendimiento. función realiza el tulo 5). Puesto que ambos, el coste y las estimaciones software para transformar la información de entra- de la planificación temporal, están orientados da en una salida? características de rendimiento nalmente, un pequeño grado de descomposición suele especiales que abordar? ser útil. El ámbito de un proyecto de software debe ser uní- Por ejemplo, considere un proyecto que construirá y entendible a niveles de gestión y técnico. Los un nuevo procesador de textos. Entre las característicasenunciados del ámbito del software deben estar deli- peculiares del producto están: la introducción de infor-mitados. mación a través de la voz así como del teclado; carac- Es decir, los datos cuantitativos (por ejemplo: núme- terísticas extremadamente sofisticadas de «ediciónro de usuarios simultáneos, tamaño de la lista de correo, automática de copia»; capacidad de diseño de página;máximo tiempo de respuesta permitido) se establecen indexación automática y tabla de contenido, y otras. Elexplícitamente;se anotan las limitaciones (por ejemplo: gestor del proyecto debe establecer primero la exposi-el coste del producto limita el tamaño de la memoria) y ción del ámbito que delimita estas características (asíse los factores de reducción de riesgos (por como otras funciones más normales, como edición,ejemplo: los algoritmos deseados se entienden muy bien administración de archivos, generación de documen-si están disponibles en tos). Por ejemplo, ¿requerirá la introducción de infor- mación mediante voz «entrenamiento» por parte del usuario? capacidades específicas proporcionará3.3.2. Descomposición del problema la característica de editar copias? cómo La descomposición del problema, denominado a veces será de sofisticado la capacidad de diseño de página?particionado o elaboración del problema, 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- En el 12 se presento parosición del ámbito no se intenta descomponer el proble- descomponer el problema,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. 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ón Para desarrollar un plan de proyecto razonable, tiene ortográfica; (2) comprobación gramatical; ( 3 ) compro- que descomponer funcionalmente el problema a resolver bación de referencias para documentos grandes ej.: puede encontrar una referencia a una entrada biblio- Los seres humanos tienden a aplicar la estrategia de gráfica en la lista de entradas de la bibliografía?), y (4)divide y vencerás cuando se enfrentan a problemas com- validación de referencias de sección y capítulo paraplejos. Dicho de manera sencilla,un problema complejo documentos grandes. Cada una de estas característicasse parte en problemas más pequeños que resultan más representa una subfunción para implernentar en soft-manejables. Ésta es la estrategia que se aplica al inicio ware. Cada una puede ser aún más refinada si la des-de la planificación del proyecto. composición hace más fácil la planificación. fases genéricasque el proceso de soft- el modelo incrementalware definición, desarrollo y soporte-son aplicablesa todo software. El problema es seleccionar el modelo deproceso apropiado para la ingeniería del software que debe . el modelo en espiral el modelo en espiral WINWINaplicar el equipo del proyecto. En el Capítulo 2 se estudió el modelo de desarrollo basado (ensamblaje) en com- ponentesuna gran gama de paradigmas de ingeniería del software: el modelo secuencia1lineal . el modelo de desarrollo concurrente el modelo de prototipo el modelo de métodos formales el modelo DRA . el modelo de técnicas de cuarta generación 45
  • 41. DEL SOFTWARE. UN ENFOQUE PRACTICO Comunicación con el cliente-tareas requeridas para establecer la obtención de requisitos eficiente entre Uno vez eleyido el modelo de proceso, ocompóñelo con el desarrollador y el cliente. el mínimo conjunto de de y productos que Planificación- tareas requeridas para definir los desembocaronen un producto de - e v i t e la recursos, la planificación temporal del proyecto y de destruccióndel procese. cualquier información relativa a él. El gestor del proyecto debe decidir qué modelo deproceso es el más adecuado para (1) los clientes que hansolicitado el producto y la gente que realizará el traba- Recuerde.... sejo; ( 2 )las característicasdel producto en sí, y ( 3 ) el entor- en todos los proyectos- no hoy excepciones.no del proyecto en el que trabaja el equipo de software.Cuando se selecciona un modelo de proceso, el equipo Análisis del riesgo-tareas requeridas para valorardefine entonces un plan de proyecto preliminar basado los riesgos técnicos y de gestión.en un conjunto de actividades estructurales. Una vez tareas requeridas para construir una oestablecido el plan preliminar, empieza la descomposi- más representaciones de la aplicación.ción del proceso. Es decir, se debe crear un plan com- Construccióny entrega-tareas requeridas para cons-pleto reflejando las tareas requeridas a las personas para truir, probar, instalar y proporcionar asistencia al usua-cubrir las actividades estructurales. Exploramos estas rio (por ejemplo: documentación y formación).actividades brevemente en las secciones que siguen y Evaluación del cliente-tareas requeridas para obte-presentamos una visión más detallada en el Capítulo 7. ner información de la opinión del cliente basadas en la evaluación de las representaciones de software Maduración del producto y del proceso creadas durante la fase de ingeniería eLa planificación de un proyecto empieza con la madu- das durante la fase de instalación.ración del producto y del proceso. Todas las funciones Los miembros del equipo que trabajanen cada funciónque se deben tratar dentro de un proceso de ingeniería aplicarán todas las actividades estructurales. En esencia,por el equipo de software deben pasar por el conjunto se crea una matriz similar a la que se muestra en la Figu-de actividades estructurales que se han definido para ra 3.2. Cada función principal del problema (la figura con-una organización de software. Asuma que la organiza- tiene las funciones para el software procesador de textosción ha adoptado el siguiente conjunto de actividades comentado anteriormente) se lista en la columna de laestructurales (Capítulo 2): izquierda. Las actividades estructurales se en la filaFIGURA 3.2.Maduración del problema y del proceso. 46
  • 42. CAPITULO 3 CONCEPTOS SOBRE DE PROYECTOSde arriba. Las tareas de trabajo de ingeniería del software Por ejemplo, un pequeño proyecto, relativamen-(paracada actividad estructural) se introducirían en la fila te simple, requiere las siguientes tareas para la actividadsiguiente5. El trabajo del gestor del proyecto (y de otros de comunicación con el cliente:miembros del equipo) es estimar los requisitos de recur- 1. Desarrollar una lista de aspectos que se han de cla-sos para cada celda de la matriz, poner fechas de inicio y rificar.finalización para las tareas asociadas con cada celda y los 2. Reunirse con el cliente para resolver los aspectosproductos a fabricar como consecuencia de cada celda. que se han de clarificar.Estas actividades se consideran en los Capítulos y 7. 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. descomposición del producto y del proceso se produce simultóneamente con evolución del plan de proyecto. Estos acontecimientospueden ocurrir en un periodo de menos de 48 horas. Representan una descomposición del problema apropiado para proyectos pequeños relativa-3.4.2. Descomposición del proceso mente sencillos.Un equipo de software debería tener un grado significa- Ahora, consideremos un proyecto más complejo quetivo de flexibilidad en la elección del paradigma de inge- tenga un ámbito más amplio y un mayor impacto comer-niería del software que resulte mejor para el proyecto y cial. Un proyecto como ése podría requerir las siguientesde las tareas de ingeniería del software que conforman el tareas para la actividad de comunicación con el cliente:modelo de proceso una vez elegido. Un proyecto relati-vamente pequeño similara otros que se hayan hecho ante- 1.Revisar la petición del cliente.riormente se debería realizar con el enfoque secuencia1 2. Planificar y programar una reunión formal con ellineal. Si hay límites de tiempo muy severos y el proble- cliente.ma se puede compartimentarmucho, el modelo apropia- 3. Realizar una investigación para definir solucionespro-do es el DRA (en inglés RAD). Si la fecha límite está tan puestas y enfoques existentes.próxima que no va a ser posible entregar toda la 4. Preparar un «documentode trabajo» y una agenda paranalidad, una estrategia incremental puede ser lo mejor. la reunión formal.Similarmente,proyectos con otras características ej.: Realizar la reunión.requisitos inciertos, nuevas tecnologías, clientes difíci- 6. Desarrollar conjuntamente mini-especificacionesqueles, potencialidad de reutilización) llevarán a la selección reflejen la información, función y características dede otros modelos de proceso6. comportamientodel software. Aplique siempre la (Estructura Común de sin tener en cuenta el tamaño, o tipo del proyecto. tareas pueden variar pero la no. Modelo de proceso adaptable. Una vez que se ha elegido el modelo de proceso, laestructuracomún de proceso (ECP) se adapta a él. En todos 7. Revisar todas las mini-especificaciones para compro-los casos,el ECP estudiado anteriormente en este capítu- bar su corrección, su consistencia,la ausencia de ambi-lo -comunicación con el cliente, planificación, análisis güedades.de riesgo, ingeniería, construcción, entrega y evaluación 8. Ensamblar las mini-especificacionesen un documentodel cliente-puede adaptarse al paradigma. Funcionará de alcance del proyecto.para modelos lineales, para modelos iterativos e incre- 9. Revisar ese documento general con todo lo que puedamentales,para modelos de evolución e para mode- afectar.losconcurrenteso de ensamblaje de componentes.El ECP 10. Modificar el documento de alcance del proyectoes invariable y sirve como base para todo el trabajo de cuando se requiera.software realizado por una organización. Ambos proyectos realizan la actividad estructural que Pero las tareas de trabajo reales sí La descom- denominamos comunicacióncon el cliente, pero el equipoposición del proceso comienza cuando el gestor del pro- del primer proyecto lleva a cabo la mitad de tareas deyecto pregunta: vamos a realizar esta actividad ingeniería del software que el segundo. Se hace notar que las tareas se deben adaptar a las necesidades Recuerde que las características del proyecto tienen también unaespecíficasde un proyecto. Las actividades estructurales siempre per- fuerte influencia en la estructura del equipo que va a realizar el tra-manecen igual, pero las tareas se seleccionarán basándose en unos bajo. Vea la Seccióncriterios de adaptación. Este tema e s discutido más adelante en elCapitulo 7 y en la página SEPA 47
  • 43. DEL SOFTWARE. UN ENFOQUE 3.5Para gestionar un proyecto de software con éxito, vaya a estar involucrado en el proyecto. Sedebemos comprender qué puede ir mal (para evitar za construyendo el equipo adecuado (Sección 3.2.3)esos problemas) y cómo hacerlo bien. En un excelente y dando al equipo la autonomía, autoridad y tecno-documento sobre proyectos de software, John logía necesaria para realizar el trabajo. define diez señales que indican que un pro- Mantenerse. Muchos proyectos no realizan unyecto de sistemas de información está en peligro: buen comienzo y entonces se desintegran lentamente. Para mantenerse, el gestor del proyecto debe pro- porcionar incentivos para conseguir una rotación del personal 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 de software, el progreso se sigue mientras se realizan los productos del trabajo (por ejemplo, especificaciones, 1.La gente del software no comprende las necesi- código fuente, conjuntos de casos de prueba) y se dades de los clientes. aprueban (utilizando revisiones técnicas formales) como parte de una actividad de garantía de calidad. 2. El ámbito del producto está definido pobremente. Además, el proceso del software y las medidas del 3 . Los cambios están mal realizados. proyecto (capítulo 4) pueden ser reunidas y utilizadas 4. La tecnología elegida cambia. para evaluar el progreso frente a promedios desarro- llados por la organización de desarrollo de software. 5. Las necesidades del negocio cambian [o están mal definidas]. Tomar Decisiones Inteligentes. En esencia, las decisiones del gestor del proyecto y del equipo de 6. Las fechas de entrega no son realistas. software deberían «seguir siendo Siem- 7. Los usuarios se resisten. pre que sea posible, utilice software del mismo 8. Se pierden los patrocinadores [o nunca se obtu- comercial o componentes de software existentes; vieron adecuadamente]. evite personalizar interfaces cuando estén dispo- nibles aproximaciones estándar; identifique y eli- 9. El equipo del proyecto carece del personal con las mine entonces riesgos obvios; asigne más tiempo habilidades apropiadas. del que pensaba necesitar para tareas arriesgadas10.Los gestores [y los desarrolladores] evitan buenas o complejas (necesitará cada minuto). prácticas y sabias lecciones. Los profesionales veteranos de la industria hacenreferencia frecuentemente a la regla 90-90 cuandoestudian proyectos de software particularmente difí-ciles: el primer 90 por 100 de un sistema absorbe el90 por 100 del tiempo y del esfuerzo asignado. El últi- Se puede un gran conjunto de recursos que pueden ayudar tanto a gestores de proyectomo 10 por 100 se lleva el otro 90 por 100 del esfuer- experimentodos como principiantes en:zo y del tiempo asignado Los factores que www.pmi.org, www.4pm.com yconducen a la regla 90-90 están contenidos en las diez www.projectmanagement.comseñales destacadas en la lista anterior. negatividad! actúa un gestor paraevitar los problemas señalados anteriormente? Realizar un Análisis (después sugiere una aproximación de sentido común lizar el proyecto}. Establecer un mecanismo consis-a los proyectos de software dividida en cinco partes: tente para extraer sabias lecciones de cada proyecto. Empezar con el pie derecho. Esto se realiza tra- Evaluar la planificación real y la prevista,reunir y ana- bajando duro (muy duro) para comprender el pro- lizar métricas del proyecto de software y blema a solucionar y estableciendo entonces con datos de los miembros del equipo y de los clien- objetivos y expectativasrealistas para cualquiera que 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 estar capacitado para realizar esto. 48
  • 44. 3 CONCEPTOS SOBRE DE PROYECTOSEn un excelente documento sobre proyectos y proce- ponsabilidad de cada miembro del equipo de soft-so del software, Boehm afirma: se ware debe estar definida. La respuesta a la pre-necesita un principio de organización que haga una gunta ayuda a cumplir esto.simplificación con el fin de proporcionar planes [de Dónde están situados organizacionalmente?proyectos] sencillos para proyectos pequeños». Boehm No todos los roles y responsabilidades residen ensugiere un enfoque que trate los objetivos, hitos y pla- el equipo de software. El cliente, los usuarios, ynificación, responsabilidades, enfoque técnico y de otros directivos también tienen responsabilidades.gestión, y los recursos requeridos del proyecto. Bohemlo llama el principio después deuna serie de preguntas (7 cuestiones) que conducen ala definición de las características clave del proyectoy el plan del proyecto resultante: qué se desarrolla el sistema? La respuesta a esta pregunta permite a todas las partes evaluar la vali- dez de las razones del negocio para el trabajo del soft- de Proyecto de Software ware. Dicho de otra forma, el propósito del negocio el gasto en personal, tiempo, y dinero? estará realizado el trabajo desde se realizaráy cuándo? La respuesta a estas to de vista técnico y de gestión? Una vez estable- preguntas ayuda al equipo a establecer la planifi- cido el ámbito del producto, se debe definir una cación del proyecto identificando las tareas clave estrategia técnica y de gestión para el proyecto. del proyecto y los hitos requeridos por el cliente. cantidad de cada recurso se necesita? La respuesta a esta pregunta se deriva de las estima- ciones realizadas (Capítulo 5 ) basadas en res- preguntas necesitan puestas a las preguntas anteriores. ser respondidas para desarrollar un Plan de Proyecto? El principio de Boehm es aplicable sin tener en cuenta el tamaño o la complejidad del proyecto de software. Las preguntas señaladas proporcionan un es el responsable de unafunción? Antes perfil de planificación al gestor del proyecto y al equi- en este capítulo, señalamos que el papel y la res- po de software. El Concilio8 Airlie ha desarrollado una lista de uno de los riesgos es la oportunidad de que«prácticas críticas de software para la gestión basada el riesgo se convierta en un problema y cuál es elen el rendimiento». Estas prácticas son «utilizadas de impacto si lo hace?un modo consistente por, y consideradas críticas por, Coste empírico y estimación de la planificación.organizaciones y proyectos de software de mucho éxi- es el tamaño actual estimado de la aplicaciónto cuyo rendimiento “final” es más consistente que de software (sin incluir el software del sistema) quelos promedios de la En un esfuer- será entregada en la operación? se obtuvo?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 desarrolladoun conjunto de preguntas de «Visión Rápida»para un proyecto’: Gestión formal del riesgo. son los diez riesgos principales para este proyecto? Para cada rápida del Proyecto Airlie Concilio Airlie es un equipo de expertos en ingeniería del Solo se destacan aquí aquellas practicas críticas relacionadas conpromocionado por el Departamento de Defensa U.S. ayudando en el la del proyecto)).Otras practicas mejores se trataran endesarrollo de directrices para prácticas importantes en la gestión de capítulos posteriores.proyectosde software y en la ingeniería del Software. 49
  • 45. DEL SOFTWARE. UN ENFOQUE Gestión de proyectos basada en métricas. de el principio del programa y del número de defectos pone de un programa de métricas para dar una prime- que se corrigen y se producen en la actualidad? ra indicación de los problemas del desarrollo? Si es así, Gestión del programa del personal. es es la volatilidad de los requisitos actualmente? la media de rotación de la plantilla en los tres Últi- Seguimiento del valor ganado. men- mos meses por cada uno de los sualmente de las métricas del valor ganado ...? Si rrolladores involucrados en el desarrollo del es así, calculadas estas métricas desde una software para este sistema? red de actividades de tareas para el esfuerzo total Si un equipo de proyectos de software no puede a próxima entrega? responder a estas preguntas, o las responde Seguimientode defectos frente a objetivos de cali- cuadamente, se debe realizar una revisión completa dad. el seguimientoe informa periódicamente de las prácticas del proyecto. Cada una de las prácti- del número de defectos encontrados en cada prueba de cas críticas señaladas anteriormente se tratan con deta- inspección [revisión técnica formal] y ejecución des- lle a lo largo de la Parte de este libro.La gestión de proyectos de software es una actividad pletar el trabajo. Finalmente, el proyecto debe organi-protectora dentro de la ingeniería del software. Empie- zarse de una manera que permita al equipo de softwareza antes de iniciar cualquier actividad técnica y con- tener éxito.tinúa a lo largo de la definición, del desarrollo y del El elemento fundamental en todos los proyectos demantenimiento del software. software es el personal. Los ingenieros del software Hay cuatro P’s que tienen una influencia sustan- pueden organizarse en diferentes organigramas de equi-cial en la gestión de proyectos de software -personal, po que van desde las jerarquías de control tradiciona-producto, proceso y proyecto-. El personal debe orga- les a los equipos de abierto». Se puedennizarse en equipos eficaces, motivados para hacer un aplicar varias técnicas de coordinación y comunica-software de alta calidad y coordinadospara alcanzar una ción para apoyar el trabajo del equipo. En general, lascomunicación efectiva. Los requisitos del producto revisiones formales y las comunicaciones informalesdeben comunicarse desde el cliente al desarrollador, persona a persona son las más valiosas para los pro-dividirse (descomponerse) en las partes que lo consti- fesionales.tuyen y distribuirse para que trabaje el equipo de soft- La actividad de gestión del proyecto comprendeware. El proceso debe adaptarse al personal y al medición y métricas, estimación, análisis de riesgos,problema. Se selecciona una estructura común de pro- planificación del programa, seguimiento y control.ceso, se aplica un paradigma apropiado de ingeniería Cada uno de estos aspectos se trata en los siguientesdel software y se elige un conjunto de tareas para com- capí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. Curtis, et al., Management lity Maturity Model, Software Engineering Institute, Baker, F.T., Programmer Team Pittsburgh, PA, 1994. ment of Production IBM vol. 11, 1, 1972, pp. 56-73. T., y Peopleware, edi- ción, Dorset House, 1998. Boehm, the Software IEEE vol. 13, 4, Julio de 1996, pp. 73-82. Edgemon, Stuff How to Recognize Constantine, L., Organization: Paradigms It When a Project Manager», Application for Project Management and CACM, vol. Development Trends, vol. 2, 5, Mayo de 1995, 36, 10, Octubre de 1993, 34-43. 37-42. Cougar, y Zawacky, Managing and Ferdinandi, L., Computer Personnel, Wiley, 1980. IEEE Software, Septiembre de 1998, pp. 92-96. Curtis, et al, Field Study of the Software Jackman, M., Remedies for Team Design Process for Large IEEE Trans. IEEE Software, Julio de 1998, pp. 43-45. 50
  • 46. 3 CONCEPTOS SOBRE DE PROYECTOS Kraul, y Streeter, Software Factors Software CACM,vol. 38, 3, Marzo de pp. IEEE Software, Mayo de 1999, 18-23. 69-8 Weinberg, G., On Becoming a Mantei, M., Effect of Programming Team Dorset House, 1986. Structureson Programming CACM,vol. 24, 3, Whitaker, K., Software Maniacs, Wiley, Marzo de 1981, pp. 106-113. 1994. Page-Jones, M., Practica1 Project Management, Zahniser, for Top Team Perfor- Dorset House, 1985, VII. mance», Development, Marzo de 1994,pp. 35-38.3.1. Basándose en la información contenida en este capítu- por el mercado de entretenimiento casero es intensa, hay cier-lo y en su propia experiencia, desarrolle «diez mandamien- ta presión para terminar el trabajo rápidamente. estruc-tos» para potenciar a los ingenieros del software. Es decir, tura de equipo elegiría y por qué? de procesohaga una lista con las diez líneas maestras que lleven al per- de software elegiría y por qué?sonal que construye software a su máximo potencial. 3.8. Se le ha nombrado gestor de proyecto de una gran com-3.2. El Modelo de Madurez de Capacidad de Gestión de Per- pañía de productos software. Su trabajo consiste en dirigir lasonal (MMCGP) del Instituto de Ingeniería del Software hace versión de la siguiente generación de su famoso procesadorun estudio organizado de las «áreas clave prácticas de textos. Como la competencia es intensa, se han estableci-que cultivan los buenos profesionales del software. Su profe- do y anunciado fechas límite rígidas. estructura de equi-sor le asignará una ACP para analizar y resumir. po elegiría y por qué? de proceso de software3.3. Describa tres situaciones de la vida real en las que el elegiría y por qué?cliente y el usuario final son el mismo. Describa tres situa- 3.9. Se le ha nombrado gestor de proyecto de software de unaciones en que son diferentes. compañía que en el mundo de la ingeniería Su trabajo es dirigir el desarrollo de un nuevo producto de soft-34 Las decisiones tomadas por una gestión experimentada .. ware que acelere el ritmo de impresión de El trabajo espueden tener un impacto significativo en la eficacia de un equi- orientado a pero la meta es fabricar el producto dentro delpo de ingeniería del software. Proporcione cinco ejemplos para siguiente año. estructura de equipo elegiría y por qué?ilustrar que es cierto. de proceso de software elegiría y por qué?3.5. Repase el libro de Weinberg y escriba un resu- 3.10. Como muestra la Figura 3.1, basándose en los resulta-men de dos o tres páginas de los aspectos que deberían tener- dos de dicho estudio, los documentos parecen tener más usose en cuenta al aplicar el modelo MOI. que valor. qué cree que pasó esto y qué se puede hacer36 Se le ha nombrado gestor de proyecto dentro de una .. para mover el punto documentos por encima de la línea deorganización de sistemas de información. Su trabajo es regresión en el gráfico? Es decir, se puede hacer para una aplicaciónque es bastante similar a otras que ha cons- mejorar el valor percibido de los documentos?truido su equipo, aunque ésta es mayor y más compleja. Los 3.11. Se le ha pedido que desarrolle una pequeña aplicaciónrequisitos han sido detalladamente documentados por el clien- que analice todos los cursos ofrecidos por la universidad ete. estructura de equipo elegiría y por qué? mode- informe de las notas medias obtenidas en los cursos (para unlo(~) e proceso de software elegiría y por qué? d periodo determinado). Escriba una exposición del alcance que37 Se le ha nombrado gestor de proyecto de una pequeña .. abarca este problema.compañía de productos software. Su trabajo consiste en cons- 3.12. Haga una descomposición funcional de primer niveltruir un producto innovador que combine hardware de reali- de la función diseño de página tratado brevemente en ladad con software innovador. que la competencia Sección 3.3.2.Una excelente serie de cuatro volúmenes escrito por proporcionar una nueva visión profunda de los aspectos delberg (Quality Software Management, Dorset House, 1992, proyecto de software y de su gestión. Purba y Shah (How to1993,1994,1996)introduce los conceptos básicos sobre sis- Manage a Software Project, Wiley, 1995)presen-temas y conceptos de gestión, explica cómo usar medicio- tan un número de estudios de casos de proyectos que indicannes eficazmente y menciona la «acción congruente», la por qué unos fracasaron y otros fueron un éxito. Bennatanhabilidad de «encajar» las necesidades del gestor, del per- (Software Management in asonal técnico y las del negocio. Proporciona información Wiley, 1995) estudia aspectos específicos de gestiónÚtil tanto a los gestores noveles como a los experimentados. asociados con el desarrollo de sistemasBrooks (The Mythical Man-Month, Aniversary Edition, Se puede argumentar que el aspecto más importante de laAddison-Wesley, 1995) ha actualizado su clásico libro para gestión del proyecto de software es la gestión de personal. El 51
  • 47. DEL SOFTWARE. UN ENFOQUElibro definitivo sobre este tema lo escribieron y jo más eficazmente. House (The Human o Project fter pero se han publicado en los Últimos años los Management, Addison-Wesley, 1988) y Crossby (Runningsiguientes libros donde se examina su importancia: Things: The art of Making Things Happen, Beaudouin-Lafon, M., Computer Supported 1989)proporcionan directrices prácticas para gestores que Work, 1999. deban tratar con problemas humanos y técnicos. Carmel, E., Global Software Teams: Collaborating Aunque no están relacionados específicamente con elAcross Borders and Time Zones, Prentice Hall, 1999. mundo del software, y algunas veces sufren demasiadas Humphrey, W. Managing Technical People: simplificaciones y amplias generalizaciones, los libros devation, Teamwork, and the Software Process, gran éxito de Drucker (Management theley 1997. Century, Harperbusines, Buckingham y Coffman Humphrey, W. Introduction to the Team of Software (First, Break the Rules: What the World’sProcess, Addison-Wesley, 1999. Managers Do Simon Schuster, 1999) y Jones, H., Handbook of Team Design: A tensen (The Business School Guide to Team Development, Press, 1997) enfatizan «nuevas reglas» definidas por una 1997. economía que cambia con rapidez. Viejos títulos como Karolak, Global Software Development: Minute Manager e Search of continúanging Virtual Teams and Environments, IEEE Computer proporcionando enfoques valiosos que pueden ayudarle a Society, 1998. gestionar los temas relacionados con el personal de un modo Mayer, M., The Virtual Edge: Embracing Technology más eficiente.for Distributed Project Team Success, Project Management En Internet están disponibles una gran variedad de fuen-Institute Publications, 1999. tes de información relacionadas con temas de gestión de pro- Otro excelente libro de Weinberg es lectura yectos de software. Se puede encontrar una lista actualizadaobligada para todo gestor de proyecto y jefe de equipo. Le con referencias a sitios (páginas) web que son relevantes paradará una visión interna y directrices para realizar su traba- los proyectos de software en 52