Your SlideShare is downloading. ×
Guia 1 is
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Guia 1 is

835
views

Published on


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

  • Be the first to like this

No Downloads
Views
Total Views
835
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
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. PAIITE EL PRODUCTO Y EL PROCESO a la tecnología de Ingeniería del asados en com- ad de un proceso? Una vez contestad ntas, estará más preparado para com- s y de gestión de la disciplina de ingeniería a la que 1
  • 2. CAPÍTULO EL PRODUCTQ 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 negocic3s comprometieron grandes cantidades de dinero, y por Último, las advertencias horri- bles de catástrofe llegaron a la conciencia del público. El software, al igual que el ahora famoso error Y2K, 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 mater. 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 caki interminable. El software es casi ineludible en un mun- do moderno. A medida que nos adentremos en el siglo XXI, será el que nos conduzca a nuevos avances en todo, desde la educación elemental a la ingeniería genética.&Que es? El software de computadora es ¿Por qué e s importante? Porque &Cu610S dudo obtenido?Des- el producto que diseiian 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 obtenido son los ca programas que se ejecutan omercio, cuí- programas, documentos y los datos vidades coti- que configuran el software d e compu- de el punto de vista de os? Construir los usuarios el producto obt e impresos y datos que combinan ora cons- información resultante números y texto y tambien incluyen producto =tis- algún modo el mund representaciones d e información de oceso que usuarios. audio, vídeo e imágenes. conduce a un resultado de alta calidad ¿Cómo puedo estar u r g e de que&Quién hace? Los ingenierosde soft- lo que satisface las necesidades de l a lo he hecho comeatmneate? L e e ware lo construyen, y virtualmente gente que usará el producto. Debes el resto deeste libro, selecciona aque- cualquier persona en el mundo indus- aplicar un enfoque d e ingeniería d e llas ideas que son aplicablers al soft- trialiiado lo utiliza bien directa o indi- software. ware que construyes y aplícalas a tu rectaniate. trabajo. Cinco años después de que la cuarta edición de este libro fue escrita, el papel del software como «alma maten>ha llegado a ser más obvio.Un 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 «punto-com» estimaciones en billones de dólares antes de que éstas comenzasen 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 informático -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
  • 3. INGENIERfA 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 la edemo-transmitiendo información que puede ser tan simple cratización del conocimiento». A Yourdon [YOU92] 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 [HAM93] 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 areingeniería de lay entomos). compañía».A mediados de los años 90, la persistencia de las computadoras y del softwaregeneró una erupción de libros por «neo-Luddites» (por ejemplo: Resisting the Vir- tual Life, editado por James Brook y Ian Boal, y The Futu- re Does not Compute de Stephen Talbot). Estos autores Esoftware es tonto un producto, l 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 [LEV95]. El papel del software informático ha sufrido un cam-bio significativo durante un periodo de tiempo superiora 50 años. Enormes mejoras en rendimiento del hard- cosas 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 [YOU96] 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 «resurrección 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: [YOU98b], [DEJ98], [KAR99]). Aunquey de su impacto en nuestra cultura. Osborne [OSB79] muchos vieron las predicciones de los críticos del Y2Khablaba de una «nueva revolución industriah. Toffler como reacciones, sus populares lecturas devolvieron la[TOF80] llamó a la llegada de componentes microelec- difusión del software a sus vidas. Hoy en día, «la com-trónicos la «tercera ola del cambio» en la historia de la putación omnipresente» [NOR98] ha producido una gene-humanidad, y Naisbitt "A1821 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 McCorduck [FE1831 sugirieron que «una capa de conexión sobre nuestras casas, oficinas, yla información y el conocimiento (controlados por com- autopistas» [LEV99]. El papel del software continúa suputadora) serían el foco de poder del siglo veintiuno, y expansión.Sto11 [STO891 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. centrado en una parte de la tecnología requerida para entre- Al comienzo de los años 90, Toffler [TOF90] 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 modernos basados en computadoras: 4
  • 4. CAPITULO 1 EL PRODUCTO Y EL PROCESO ¿Por qué lleva tanto tiempo terminar los programas? ¿Por qué son tan elevados los costes de desarrollo? ¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes? ¿Por qué nos resulta difícil constatar el progreso con- Estadísticas globoles 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 significa que los proyectos de software no se puedenba «software de 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. ¿Pero lo entien- 2. El software no se «estropea».den realmente? La Figura 1.1 describe, para el hardware, la proporción de fallos como 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 al pnnci-Para 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 (vease más información en el Capítulo 8). Sin embargo la implicación es clara, el soft- ".% c VE El software se desarrolla, no se fabrica. ware no se estropea. ¡Pero se deteriora! W$ CLAVE1. 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 u) Mortalidad Se estropea - -buen diseño, pero la fase de construcción del hard- m c alware puede introducii problemas de calidad que no D alexisten (o son fácilmente corregibles) en el software. ._ UAmbas actividades dependen de las personas, pero la ._relació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
  • 5. INGENIER~ADEL 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 «la curva actual» 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 -e1 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 lograrse 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 ser reutiliza-en 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 componentes reu-truye 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 componentes reu-Después de seleccionar cada componente, puede soli- 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 f del índice de fallos c VE l a mayoría del s o h a r e 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- -Curva 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 a$$ base de datos) y producen «informes» 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 la magnitud de los picos y la inclinación da y produce órdenes concretas para la máquina en rápi- de la curva (Fig. 1.2). da sucesión. 6
  • 6. CAPÍTULO 1 EL PRODUCTO Y EL PROCESO Software de gestión. El proceso de la información l a revolución del software se foto en el Capítvlo 13. comercial constituye la mayor de las áreas de aplica- Lo ingeniería de software basada en canponentes ción del software. Los «sistemas» discretos (por ejem- se presento en el Capítulo 27. plo: nóminas, cuentas de haberes-débi.tos, inventarios, 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 pre- 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 algorit- gestionar la toma de decisiones. Además de las tareasmo(s) 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 de inge-nificativas. Conforme aumenta la complejidad del niería/ciencia 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 periféricos, 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, una comparti-ción de recursos y una sofisticada gestión de procesos;unas estructuras de datos complejas y múltiples inter-faces externas. Software de tiempo real. El software que coor-dina/analiza/controla sucesos del mundo real conforme Se puede encontrar una de las mayores bibliotecasocurren, se denomina de tiempo real. Entre los elemen- de shurewure/freewure en www.shoieware.comtos 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 componente de controVsalida 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. 7
  • 7. INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO Software basado en Web. Las páginas Web busca- Software de 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 complejos para los que no sono Java), y datos (por ejemplo, hipertexto y una varie- adecuados el cálculo o el análisis directo. Los sistemas exper-dad de formatos 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), redes neu-recurso software casi ilimitado que puede ser accedido ronales 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 crucial», nin-autor) han caracterizado los problemas asociados con el gún «momento 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: [GLA97], [FL097], en las disciplinas relacionadas con el software.[YOU98a]) 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: «el 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 Glass, 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 [GLA98]: «Puedo ver en mis La palabra aflicción 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 llena.» 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 «no 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 «un punto decisivo en el curso de algo, momento, Vivimos con esta aflicción desde este día - d e hecho,etapa o evento decisivo o crucial». Sin embargo, en térmi- la industria prospera a pesar de e l l e . 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 Michigan en una conferencia impartida en Ginebra, Suiza, Abril, 1989. 8
  • 8. CAPfTULO 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 estánda- ducen a que el cliente se cree una falsa expectativa y, final-res y procedimientos para construir software, ¿no 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 usa?.¿conocen 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?, ¿es completo?, ¿está 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 «no». 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 de cambio esm tratadarrollo de software más avanzadas, después de todo, les con detalle en el Capítulo 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 «concepto de la horda Mongoliana»). 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 [BR075]: «...añadir gente a un proyecto de software retrasado lo retrasa aún más». 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 comunicarse con 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 Puede 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 www.sprnn.com puede ayudarle nos que requieran recursos adicionales e importantes a desmitificar estos y otros mitos. modificaciones del diseño; es decir, coste adicional. Los 9
  • 9. INGENIERfA 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- RealUiad. 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 [LIE80, JON91, PUT971 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 kobojo muy duro poro entender lo que tienes que hacer reconocimiento de las realidades del software es el antes de empezar. No serías copoz de desorrollor codo primer paso hacia la formulación de soluciones prác- detalle; por más que sepos, 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 Cuando te pones o pensar, no encueniros tiempo poro loinformáticos. El software se compone de programas, disciplino de lo ingeniería del sohare, y te preguntas:datos y documentos. Cada uno de estos elementos com- ((2 kndré tiempo para poder hacerlo?))[BR075] Brooks, F., The Mytical Man-Month, Addison-Wes- [GLA97] Glass, R. L., Software Runaways, Prentice Hall, ley, 1975. 1997.[DEJ98] De Jager, P., et al, Countdown Y2K: Business Sur- [GLA98] Glass, R. L.,«Is there Really a Software Crisis?», viva1 Planning for the Year 2000, Wiley, 1998. IEEE Sofmare, vol. 15, n." 1, Enero 1998, pp. 104-105.[DEM95] De Marco, T., Why Does Software Cost So Much?, [HAM93] Hammer, M., y J. Champy, Reengineering rhe Cor- Dorset House, 1995, p. 9. poration, HarpperCollins Publisher, 1993.[FE1831Feigenbaum, E. A., y P. McCorduck, The Fith Gene- [-TON911Jones, C.,Applied Software Measurement, McGraw- ration, Addison-Wesley, 1983. Hill, 1991.[FL097] Flowers, S., Software Failure, Management Fui- [KAR99] Karlson, E., y J. Kolber, A Basic Introdiiction to lure-Amaicing Stories and Cautionary Tails, Wiley, Y2K: How the Year 2000 Computer Crisis Affects You?, 1997 (?). Next Era Publications, Inc., 1999. 10
  • 10. CAPfTULO 1 EL PRODUCTO Y EL PROCESO[LEV95] Levy, S., «The Luddites Are Pack», Newsweek, 12 de [STO891 Stoll, C., The cuckoos Egg, Doubleday, 1989. Julio de 1995, p. 55. [TOF80] Toffler, A., The Third Wave, Morrow Publishers,[LEV99] Levy, S., «The New Digital Galaxy», Newsweek, 1980. 31 de Mayo de 1999, p.57. . [TOF90] Toffler, A., Powershif, Bantam Publishers, 1990.[LIE80] Lientz, B., y E. Swanson, Software Maintenance [YOU92] Yourdon, E., The Decline and Fa11 of the Americun Management, Addison Wesley, 1980. Programmer, Yourdon Press, 1992.“A1821 Naisbitt, J., Megatoends, Warner Books, 1982. [YOU96] Yourdon, E., The Rise and Resurrection of the Ame-[NOR98]Norman, D., The Invisible Computer,MIT Press, 1998. rican Programmer, Yourdon Press, 1996.[OSB79] Osborne, A,, Running Wild-The Next Industrial [YOU98a] Yourdon, E., Death March Projects, Prentice-Hall, Revolution, Osborne/McGraw-Hill, 1979. 1998.[PUT97] Putnam, L., y W. Myers, Industrial Strength Soft- [YOU98b] Yourdon, E., y J. Yourdon, Time Bomb 2000, Pren- 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 informáticos. 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 Y2K) en donde el fallo de computadora podría hacer un gran daño (económico o humano).1.2. En los años 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. ¿Cómo ha afectado esto a las prácticas de desa- comp.risk 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 «era 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- Minasi (The Software Conspiracy: Why Software Com-tan 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, McGraw-Hill, 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. DeMarco (Why Does 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 XXI. Los software y el proceso a través del cual se desarrolla.libros de Norman [NOR98] y Bergman (Information En Intemet están disponibles una gran variedad de fuen-Appliances & Beyond, Academic Pres/Morgan 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 en http://www.press-la difusión de la programación conecten a todos en el mun- man5.com. 11
  • 11. CAPÍTULO H OWARD Baetjer, Jr. [BAE98], 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 «capital del software», es el conjunto del software reunido. denurado v orpanizado mientras se desarrolla el Droceso.;Qué es? Cuando trabaja para construir ¿Por qué es importante? Porque pro- software, los productos obtenidos son un producto o un sistema, es impor- porciona estabilidad, control y organi- programas, documentos y datos gue se tante seguir una serie d e pasos pre- zación a una actividad que puede, si producen como consecuencia d e l a s decibles -un mapa de carreteras que no se controla, volverse caótica. actividades de ingeniería del software le ayude a obtener el resultado opor- ¿Cuáies son los pasos? A un nivel deta- definidas por el proceso. tuno de calidad-. El mapa de carre- llado, el proceso que adoptemos ¿Cómo puedo estar seguro de que teras a seguir es llamado .proceso del depende del software que estamos lo he hecho correctamente?Hay software.. construyendo. Un proceso puede ser una cantidad de mecanismos d e eva- lo&Quién hace? Los ingenieros de soft- apropiado para crear software de un luacion del proceso del software que ware y sus gestores adaptan el proce- sistema de aviación, mientras que un permiten a las organizaciones deter- so a sus necesidades y entonces lo proceso diferente por completo puede minar la «madurez. de su proceso del siguen. 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 del a desempeñar en el proceso del soft- &Cuál es el producto obtenido? Des- producto que está construyendo son los ware. de el punto de vista de un ingeniero d e mejores indicadores de la eficiencia del proceso que estamos utilizando. Pero, ¿qué 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. ¿Es «proceso» sinónimo de ingeniería del softwa- re? La respuesta es «sí» 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
  • 12. INGENIERfA 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 [NAU69] 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 (ACPs) [PAU93] 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. ¿Cuáles 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? ¿Cómo construimos pruebas y mantenimiento. Los métodos de la ingenieríael software «económicamente» para que sea «fiable»? del software dependen de un conjunto de principios bási-¿Qué se necesita para crear programas de computa- cos que gobiernan cada área de la tecnología e incluyendora que funcionen «eficientemente» 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. s i& CLAVE l a Ingeniería de software comprende un proceso, ¿Cómo definimos la métodos técnicos y de gestión, y herramientas. Ingeniería del software? Las herramientas de la Ingeniería del software pro- El IEEE [IEE93] 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: (1) 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 (1). 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ía multica-pa. 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
  • 13. CAPfTULO 2 EL PROCESO ¿Cuál es el problema a resolver? La fase de desarrollo se centra en el cómo. Es decir, ¿Cuáles 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 ¿Cómo se realizará la entidad (y la solución)? arquitectura de software, cómo han de implementarse ¿Cómo se construirá la entidad? los detalles procedimentales, cómo han de caracteri- zarse interfaces, cómo ha de traducirse el diseño en un ¿Qué enfoque se va a utilizar para no contemplar los lenguaje de programación (o lenguaje no procedimen- 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 ¿Cómo 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 21), gene- dad? ración de código y prueba del software (Capítulos 16, 17 y 22). 3 Referencia Web lrosstdk es un periódico que proporciona conseios y comentarios prócticos de ingeniería del software. Estón disponibles temas relocionados 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 Lafase 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ón en 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, el clien-de paradigmas) que se aplique, de alguna manera ten- te/usuario 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 lo), 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 mantenimientopre- ventivo también llamado reingeniería del software, se ?$ ¿% debe conducir a permitir que el software sirva para las CLAVE necesidades de los usuarios finales. En esencia, el man- El software se crea aplicondo tres fases distintas que se tenimiento preventivo hace cambios en programas de centran en la definición, desarrollo y mantenimiento. computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente. 15
  • 14. INGENIERfA 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 se imple-mentan 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 Cuando utilizamos el término «mantenimiento» reconocemos que es mucho más que una simple Revisiones técnicas formales corrección 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 [STA95]. 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 -tales como 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 independencia de 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 proceso>>. Softwate Engineering Ins- Elpuntos de garantía de calidad-que permiten que las acti- titute (SEI)3 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 SE1 utiliza un cues- Actividades del marco de trabajo tionario de evaluación y un esquema de cinco grados. Tareas *m li" Seleccione un marco de trabajo del proceso común que se odecue al producto, o1 personal y o1 proyecto. El esquema de grados determina la conformidad con un modelo de capacidad de madurez [PAU93] 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. SE1 proporciona una medida de la efectividad global de El término .programas iegales~~ un eufemismo para el sottware es 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 SE1 de la Cannegie Mellon University.tico para el negocio y debe ser soportado durante algunos años. 16
  • 15. 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 comprender la 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 documento o 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ón del programa puede uti-tación cuantitativa del proceso, ideas y tecnologías inno- lizarse para proporcionar algún umbral numérico quevadoras 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 3 Referenciu Web El llS ofrece un amplio conjunto de información relacionada con el proceso en www.sei.cmu.edu 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- 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 software en 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 estándar para la programa- ceso o herramienta. 17
  • 16. INGENIERfA DEL SOFTWARE. U N E N F O Q U E PRÁCTICO En este orden debe destacarse que para que un desa-rrollador 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 Web/ ’-nivel 3. Si el desarrollador del software no tiene defi- Una versi6n tabular del MCM completo del llS, incluyendonidos rigurosamente los procesos pueden ocurrir una todos los objetivos, comentarios, habilidades y actividades estó disponible engran cantidad de cambios en el proceso de desarrollo sepo.nosc.mil/CMMmatrices.htmly no se podrán utilizar las estadísticas para estas acti-vidades. Los cinco niveles definidos por el SE1 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 SE1 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 debería esforzarse poro olconzor Gestión de integración del software lo profundidad del MíM del IIS. Sin embargo, Programa de formación lo implementoción 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. SE1 define a los indicudores clave como «aquellas 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 1 . 18
  • 17. CAPfTULO 2 EL PROCESO E 2 -. > PPara 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 descritos “*eden 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 las etapas de un proceso del software - e s t a d onierí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 la 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 [RAC95] utiliza frac- 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 inhe- 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. 2.3a)en el que se encuentran cuatro etapas distintas: «statusquo», definición de problemas, desarrollo técnico e inte- Desarrollogración de soluciones. Status quo «representa el estado técnicoactual de sucesos» [RAC95]; la definición de proble-mas identifica el problema específico a resolverse; el tdesarrollo técnico resuelve el problema a través de laaplicación de 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 2.3b, 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 [RAC95] 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. b) Fases dentro de las faseslogía». Conforme progresa el trabajo hacia un sistema del bucle de resolución de problemas [RAC 951. 19
  • 18. INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 2.4Llamado algunas veces «ciclo de vida básico» o cmode- 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 de Sistemas/Información.Como el software siempre forma parte de un sistema Aunque el modelo lineal es a menudo denominadomás grande (o empresa), el trabajo comienza estable- «modelo tradicional», resulto un enfoque razonableciendo requisitos de todos los elementos del sistema y cuando los requisitos se han entendido correctomente.asignando al software algún subgrupo 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 [HAN95]. Entre los problemascialmente en el software. Para comprender la naturaleza que se encuentran algunas veces en el modelo linealdel (los) programa(s) a construirse, el ingeniero («aria- secuencial se incluyen:lista») del software debe comprender el dominio deinformación del software (descrito en el Capítulo 1l), así ¿Por 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[ROY70] hacía provisiones para ((buclesde realimentación)b, la granmayoría d e las organizaciones que aplican este modelo de procesolo hacen como si fuera estrictamente lineal. 20
  • 19. CAPfTULO 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 secuen- 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) programa(s) 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 sig- 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 Escuchar Construir/revisarcasos, 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ón hombre-má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 desa- 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- v 4 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 ¿qué hacemos con el prototipo una vez que hapara el usuario/cliente (por ejemplo: enfoques de entra- servido para el propósito descrito anteriormente? Brooksda y formatos de salida). El diseño rápido lleva a la [BR075] proporciona una respuesta:construcción de un prototipo. El prototipo lo evalúa elcliente/usuario 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 pregunta de la gestión no es si construir un sistema pilo- to y tirarlo. Tendremos que hacerlo. La Única pregunta es si pla- Cuando el cliente tiene uno necesidad legífimo, nificar de antemano construir un desechable, o prometer pero esfó desorientado sobre los defulles, entregárselo a los clientes... el primer poso es desarrollar un prototipo. 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-construye un prototipo de trabajo, el desarrollador inten- 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
  • 20. INGENIERfA DEL SOFTWARE. U N E N F O Q U E PRÁCTICO1. 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 «el 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 funcione no 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 rnol prototipo en el pide que se apliquen a n o s pequeños ajustes>> para producto finol. Corno resultado, lo colidod se resiente casi 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) un mode- es 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 enfatiza 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 componentes reuti-ponentes. 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 «sistema completamente fun- software.cional» dentro de períodos cortos de tiempo (por ejemplo:de 60 a 90 días) [MAR91]. Cuando se utiliza principal-mente para aplicaciones de sistemas de información, el Equipo no 3enfoque DRA comprende las siguientes fases [KER94]: Modelado Modelado de Gestión. El flujo de información entre Equipo no 1 degestiónlas funciones de gestión se modela de forma que res-ponda a las siguientes preguntas: ¿Qué información con- Modelado Modeladoduce el proceso de gestión? ¿Qué información se genera? de gestión de datos¿Quién la genera? ¿A dónde va la información? ¿Quiénla 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 1 dedo como parte de la fase de modelado de gestión se refi- aplicacionesna como un conjunto de objetos de datos necesarios para Modelado -7apoyar 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 necesario para Pruebasimplementar una función de gestión. Las descripciones y entregadel proceso se crean para añadir, modificar, suprimir, orecuperar un objeto de datos. b9 6-0 -0 dd -í sa En ingles: RAD (Rapid Application Deveiopment) El FIGURA 2.6. modelo DRA. 22
  • 21. CAPfTULO 2 EL PROCESO Pruebas y entrega. Como el proceso DRA enfati- Al igual que todos los modelos de proceso, el enfo-za la reutilización, ya se han comprobado muchos de que DRA tiene inconvenientes [BUT94]:los 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 interfa- 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 hace un fuerte uso de tomponentes l viado. Si no hay compromiso por ninguna de las par- reutilizobles. Paro mayor informotin sobre el tes constituyentes, los proyectos DRA fracasarán. desanollo de componentes, véase el Capítulo 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[KER94]. Si una aplicación de gestión puede modular- 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. PROC- SOFTWWSe reconoce que el software, al igual que todos los sis- 2.7.1. El modelo incrementaltemas complejos, evoluciona con el tiempo [GIL88]. 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 [MDE93]. 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 incorporar el paradigma de construcción de 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 que % CLAVEdesarrolla) a comprender los requisitos. En general, no Emodelo incremento1entrega el software en partes lse diseña para entregar un sistema de producción. En pequenos, pero utilizables, llamadas ((incrementos).ninguno de los paradigmas de ingeniería del software En general, cado incremento se 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
  • 22. INGENIERfA 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 y/o 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 «incompletas» 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- parodigma a considerar. mentos se pueden implementar con menos personas. incremento 1 Sistemas/información Prueba Entrega del l.er incremento , Código + Prueba Entrega del 2." incremento Diseño + Código incremento 4 Análisis Prueba Entrega del 4." incremento Tiempo de calendarioFIGURA 2.7. El modelo incremental.2.7.2. El modelo espiralEl modelo en espiral, propuesto originalmente porBoehm [BOE88], 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- 0Proyecto de mantenimiento de productos.siones incrementales. Durante las primeras iteraccio- 0Proyecto de 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 del sis-tema diseñado. FIGURA 2.8. Un modelo espiral típico. 24
  • 23. CAPfTULO 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ónvidades de marco de trabajo, también llamadas regio- de planificación produce ajustes en el plan del proyec-rzes de tareas6.Generalmente, existen entre tres y seis to. El coste y la planificación se ajustan con la reali-regiones 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 ite- 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 «proyecto de desarrollo de conceptos» comienza en el etapa de instalación. centro de la espiral y continuará (aparecen múltiples ite- a$$ raciones a lo largo de la espiral que limita la región som- breada central) hasta que se completa el desarrollo del CLAVE concepto. Si el concepto se va a desarrollar dentro de Las actividades del marco de trabajo se aplican un producto real, el proceso continúa a través del cubo a cualquier proyecto de software que realice, siguiente (punto de entrada del proyecto de desarrollo sin tener en cuenta el tamaño ni la complejidad. del producto nuevo) y se inicia un «nuevo 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 el centro.Enque 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. Enitodos 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- ¿Qué 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 trabajo ite-pasos 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 direc- 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 [BOE88]. Un tratado más reciente del modeloen espiral puede encontrarse en [BOE98]. 25
  • 24. INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICOta de los riesgos técnicos en todas las etapas del pro- El modelo en espiral WINWIN de Boehm [BOE98]yecto, y, si se aplica adecuadamente, debe reducir los define un conjunto de 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: 1. Identificación del sistema o subsistemas clave de los «directivos»8. la Parte cuarto. 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 Habilidades de 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 (Victoria&Victoria) 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 al 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 IBOE981. l a obtención de requisitos del software requiere una negociación. Tiene éxito cuando ambas partes «ganan». 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 fijación [BOE96],«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 necesidadesy 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 pro- 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 [p. ej., [FiC91], [DON96], [FAR97]].Es una de las cosas mas directo, por el negocio, en el sistema o producto a construir y puedeimportantes que un ingeniero o gestor joven (o viejo) puede apren- ser premiado por un resultado con éxito o criticado si el esfuerzoder. Lea uno. falla. 26
  • 25. CAPfTULO 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 producto/sistema 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 2.7.2), se lleva a cabo invocando las tareas siguien-objetivos que se deben conocer mientras que se defi- tes: modelado de construcción de prototipos y/o 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 reuti- 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 instalación/distribución,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 [DAV94] 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 Humph- corrección del modelo de análisis de sucesos, que dis-rey y Kellner [HUM89, KEL891 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 [KEL91] 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 aplicaciones clien-actividades asociadas a un acontecimiento específico (por ejem- te/servidor" (Capítulo 28). Un sistema cliente/servidorplo: 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 cliente/servidor,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 [SHE94]: una dimensión de sistemas y una dimensión desea, 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 Se debería destacar que el análisis JI el diseño son tareas comple- l 1 En apiicaciones cliente/servidor, la funcionalidad del Software sejas que requieren un estudio sustancial. LX Partes III y IV del libro divide entre clientes (normalmente P W Y un servidor (una compu-consideran estos temas con más detalle. tadora más potente) que generalmente mantiene una base de datos centralizada.l o U estado es algún modo externamente observable del compor- ntamiento. 27
  • 26. INGENIERfA 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 cliente/servidor típica se implementa conmuchos componentes, cada uno de los cuales se puedendiseñar y realizar concurrentemente. En realidad, el mode-lo de proceso concurrente es aplicable a todo tipo de desa- O Reperesenia un estado derrollo de software y proporciona una imagen exacta del una actividad de ingenieria del software.estado actual de un proyecto. FIGURA 2.10. Un elemento del modelo de proceso concurrente.Las tecnologías de objetos (4.g 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 enfati- 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 tratamientoI2.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 3 1).dos 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 métobos orientados B 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 las 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 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 [NIE92], 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 [YOU94]. Aunque estos resultados están en funciónparados de software (llamados «clases» en la Fig. 2.11). de la robustez de la biblioteca de componentes, no hay duda de que el ensamblaje de componentes proporciona troto en lo Porte ventajas significativas para los ingenieros de software. El proceso unificado de desarrollo de software esento un estudio más detallado [JAC99] 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
  • 27. CApfTULO 2 EL PROCESOla industria. Utilizando el Lenguaje de Modelado Uni- to de vista de1 usuario). Entonces acopla la función conjcado (UML), el proceso unificado define los compo- 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 UMl con más detalle.cando un enfoque basado en escenarios (desde el pun-El modelo de métodos formales comprende un conjun- consiguiente permiten 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 unactualmente aplican una variación de este enfoque, lla- entorno de gestión:mado ingeniería del software de sala limpia [MIL87, 1. El desarrollo de modelos formales actualmente esDYE921. bastante caro y lleva mucho tiempo. 2. Se requiere un estudio detallado porque pocos res- los métodos formales 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 (T4G) 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 nivelsoftware a alto nivel. Luego, la herramienta genera auto- 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 similares utilizados 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 los entor-ta 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 embar- 29
  • 28. INGENIERfA DEL SOFTWARE. U N ENFOQUE PRACTiCOgo, 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ón de 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 T4G. 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 T4G. 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 «ineficiente» y que el manteni- lncluso cuundo utilice unu 14G, tiene que destocar miento de grandes sistemas de software desarrollados durumente /u inyenieríu del sohore huciendo e/ an6/isis, mediante T4G es cuestionable. el diseño y /os pruebus. 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 de T4G:te desde el paso de recolección de requisitos al paso de 1 . 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 (L4G) 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 L4G. 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 auto- 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 paradig- ensamblaje de componentes (Sección 2.8), 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 organizaciones de 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 [BAN95]. 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 software puede utilizar tales 30
  • 29. z CAP~TULO 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. O D U O Y PR-O . .Si el proceso es débil, el producto final va a sufrir indu- Toda actividad humana puede ser un proceso, pero cada 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, Mar- puede utilizar o apreciar, una u otra vez, o en algún otro contextogaret Davis [DAV95] 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ón de 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íúltimo 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 dual 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 Broglie 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 creativa 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
  • 30. INGENIERfA DEL SOFTWARE. U N ENFOQUE PRÁCTICO[BAE98] Baetjer, H., Jr., Software as Capital, IEEE Compu- Ilth Intl. Conference on Software Engineering, IEEE Com- ter Society Press, 1998, p. 85. puter Society Press, pp. 331-342.[BAN95] Bandinelli, S. et al, «Modeling and Improving an [IEE93] IEEE Standards Collection: Softvtzare Engineering, Industrial Software Process», IEEE Truns. Software Engi- IEEE Standard 610.12-1990, IEEE, 1993. neering, vol. 2 1, nO 5 , Mayo 1995, pp. 440-454. . [JAC99] Jacobson, I., G. Booch y J. Rumbaugh, The Unified[BRA94] Bradac, M., D. Peny y L. Votta, «Prototyping a Pro- Software Developement Proccess, Addison-Wesley, 1999. cess Monitoring Experiment", IEEE Trans. Software Engi- [KEL89] Kellner, M., Software Process Modeling: Vulue and neering, vol. 20, n." 10, Octubre 1994, pp. 774-784. Experience, SE1 Technical Review- 1989, SEI, Pittsburgh,[BOE88] Boehm, B., «A Spiral Model for Software Develo- PA, 1989. pement and Enhancement", Computer, vol. 21, n.Q5 , Mayo [KEL9 11 Kellner, M., «Software Process Modeling Support 1988, pp. 61-72. for Management Planning and Control», Proc. 1st Intl.[BOE96] Boehm, B., «Anchoringthe Software Pocess», IEEE Conf, On the Sofhvare Process, IEEE Computer Society Software, vol. 13, n." 4, Julio 1996, pp.73-82. Press, 1991, pp. 8-28.[BOE98] Boehm, B., «Using the WINWIN Spiral Model: A [KER94]Kerr, J., y R. Hunter, InsideRAD, McGraw-Hill, 1994. Case Study», Computer, vol. 31, n." 7, Julio 1998, pp. 33- 44. [MAR9 11 Martin, J., Rapid Aplication Developement, Pren- tice-Hall, 1991.[BR075] Brooks, F., The Mytical Man-Month, Addison-Wes- ley, 1975. [MDE93] McDermid, J. y P. Rook, «Software Developement Process Modelw, en Softilwe IngineerS Reference Book,[BUT94] Butler, J., «Rapid Aplication Developement in CRC Press, 1993, pp. 15/26-15/28. Action», Managing System Developement, Applied Com- puter Research, vol. 14, n." 5 , Mayo 1995, pp. 6-8. [MIL871 Mills, H.D., M. Dyer y R. Linger, «Clearoom Soft- ware Engineeringn, IEEE Software, Septiembre 1987, pp.[DAV94] Davis, A., y P. Sitaram, «A Concurrent Process 19-25. Model for Software Developement», Software Enginee- ring Notes, ACM Press, vol. 19, n." 2, Abril 1994, pp. 38- [NAU69] Naur, P., y B. Randa11 (eds.), Softwure Engineering: 51. A Report on a Conference sponsored by the NATO Scien- ce Committee, NATO, 1969.[DAV95] Davis, M.J., «Process and Product: Dichotomy or Duality», Software Engineering Notes, ACM Press, vol. [NIE92] Nierstrasz, Komponent-Oriented Software Deve- 20, n.Q2, Abril 1995, pp. 17-18. lopement», CACM, vol. 35, n.Q9, Septiembre 1992, pp. 160-165.[DON961 Donaldson, M.C., y M. Donaldson, Negotiating for Dummies, IDB Books Worldwide, 1996. [PAU93] Paulk, M., et al., «Capability Maturity Model for[DYE92] Dyer, M., The Cleanroom Approach to Quality Sof- Software», Software Engineering Institute, Carnegie ware Developement, Wiley, 1992. Mellon University, Pittsburgh, PA, 1993.[FAR97] Farber, D.C., Common Sense Negotiation: The Art [RAC95] Raccoon, L.B.S, «The Chaos Model and the Chaos of Winning Gracefully, Bay Press, 1997. Life Cycle», ACM Software Engineering Notes, vol. 20, n." 1, Enero 1995, pp. 55-66.[FIS91] Fisher, R., W. Ury y Bruce Patton, Getting to Yes: Negotiating Agreement Without Giving In, 2." ed., Penguin [ROY70] Royce, W.W., «Managing the Developement of Large USA, 1991. Software Systems: Concepts and Techniquew, Proc. WES- CON, Agosto 1970.[GIL881 Gilb, T., Principles of Software Engineering Muna- gement, Addison-Wesley, 1988. [SHE94] Sheleg, W., «Concurrent Engineering: A New Para- dign for C/S Developement», Application Developement[HAN951 Hanna, M., «Farewell to Waterfallm, Software Trends, vol. 1, n." 6, Junio 1994, pp. 28-33. Magazine, Mayo 1995, pp.38-46. [YOU94] Yourdon, E., «Software Reuse», Application Deve-[HUM89] Humphrey, W., y M. Kellner, «Software Process Iopement Strategies, vol. VI, n." 12, Diciembre 1994, pp. Modeling: Principles of Entity Process Models», Proc. 1-16. YPUNTQSACONSIL)EBAR2.1. La Figura 2.1 sitúa las tres capas de ingeniería del soft- 2.2. ¿Hay 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 SE1 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-cipios clave de un programa de Gestión de Calidad Total. dido algunas ACP nuevas desde la publicación de este libro. 32
  • 31. CAPfTULO 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 (1) 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 desarrollar un componente de corrección ortográfica ¿qué 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. ¿Qué 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ítulo piensa que sería el más eficaz? ¿Por 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.Investigue la literatura y proporcione un resumen de una herra-mienta típica CASE que soporte DRA. 2.13. ¿Qué 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 ladeterminar mejor a partir de publicaciones mensuales tales como ingeniería del software. Pressman y Herron (Software Shock,IEEE Software, Computer e IEEE Transactions on Software Dorset House, 1991) consideran el software y su impactoEngineering. Periódicos sobre la industria tales como Applica- sobre particulares, empresas y el gobierno.tion Developement Trends, Cutter IT Journal y Software Deve- El Instituto de ingeniería del software (11s 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 Proce- responsabilidad de promocionar series monográficas sobreeding o the International Conference on Software Engineering, f la ingeniería del software. Los profesionales académicos,promocionado por 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 on Software Engineering vos trabajos importantes. El Consorcio de Productividad deland Methodology, ACM Software Engineering Notes y Annals Software dirige una investigación adicional de ingenieríaof 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, J. (ed.), Sofmare Engineering Productivity Hand- tro en el estándar de calidad ISO 9001. Otros estándares debook, McGraw-Hill, 1993. ingeniería del software se pueden obtener desde el MOD, la McDermid, J. (ed.), Software Engineer’s Reference Book, Autoridad Civil de Aviación y otras agencias del gobierno yCRC Press, 1993. sin ánimo de lucro. Fairclough (Software Engineering Guides, Marchiniak, J.J. (ed.), Encyclopedia o Software Engine- f Prentice-Hall, 1996) proporciona una referencia detallada deering, Wiley, 1994. los estándares de ingeniería del software producidos por Euro- Gautier (Distributed Engineering o Software, Prentice- f 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áficamente distantes. 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 Conflict, Yourdon Press, 1991) se presentan ensayos ceso del software en http://www.pressman5.com. 33