Leccion 4 - Mitos del software

7/30/2019 Leccion 4 - Mitos del software

1/3

[FUNDAMENTOS Y DESARROLLO DE SISTEMAS] IDSYSTEMS 2013

LECCION 4 MITOS DEL SOFTWARE Pgina 1

LECCION 4 MITOS DEL SOFTWARE

Muchas de las causas de la crisis del software se pue - den encontrar en una mitologa quesurge durante los primeros aos del desarrollo del software. A diferencia de los mitos antiguos, que amenudo proporcionaban a los hombres lecciones dignas de tener en cuenta, los mitos del softwarepropagaron informacin errnea y confusin. Los mitos del software tienen varios atributos que los

hacen insidiosos: por ejemplo, aparecieron como declaraciones razonables de hechos (algunas vecesconteniendo elementos verdaderos), tuvieron un senti - do intuitivo y frecuentemente fueronpromulgados por expertos que estaban al da.

Mitos de gestin. Los gestores con responsabilidad sobre el software, como los gestores en lamayora de las disciplinas, estn normalmente bajo la presin de cumplir los presupuestos, hacer queno se retrase el proyecto y mejorar la calidad. Igual que se agarra al vaco una persona que se ahoga,un gestor de software se agarra frecuentemente a un mito del software, aunque tal creencia slodisminuya la presin temporalmente.

Mito. Tenemos ya un libro que est lleno de estndares y procedimientos para construirsoftware, no le proporciona ya a mi gente todo lo que necesita saber?

Realidad. Est muy bien que el libro exista, pero se usa?.conocen los trabajadores suexistencia?, refleja las prcticas modernas de desarrollo de software?, es completo?, estdiseado para mejorar el tiempo de entrega mientras mantiene un enfoque de calidad? En muchoscasos, la respuesta a todas estas preguntas es no.

Mito. Mi gente dispone de las herramientas de desarrollo de software ms avanzadas, despusde todo, les compramos las computadoras ms modernas.

Realidad. Se necesita mucho ms que el ltimo modelo de computadora grande o de PC parahacer desarrollo de software de gran calidad. Las herramientas de ingeniera del software asistida porcomputadora (CASE) son ms importantes que el hardware para conseguir buena calidad yproductividad, aunque la mayora de los desarrolladores del software todava no las utiliceneficazmente.

Mito. Si fallamos en la planificacin, podemos aadir ms programadores y adelantar el tiempoperdido (el llamado algunas veces concepto de la horda Mongoliana).

Realidad. El desarrollo de software no es un proceso mecnico como la fabricacin. Enpalabras de Brooks: ...aadir gente a un proyecto de software retrasado lo retrasa an ms. Alprincipio, esta declaracin puede parecer un contrasentido. Sin embargo, cuando se aaden nuevaspersonas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca lacantidad de tiempo gastado en el desarrollo productivo. Puede aadirse gente, pero slo de unamanera planificada y bien coordinada.

Mitos del Cliente. Un cliente que solicita una aplicacin de software puede ser una persona deldespacho de al lado, un grupo tcnico de la sala de abajo, el departamento de ventas o una compaaexterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos queexisten sobre el software, debido a que los gestores y desarrolladores del software hacen muy pocopara corregir la mala informacin. Los mitos conducen a que el cliente se cree una falsa expectativa y,final- mente, quede insatisfecho con el que desarrolla el software.


2/3



Mito. Una declaracin general de los objetivos es suficiente para comenzar a escribir losprogramas -podemos dar los detalles ms adelante-.

Realidad. Una mala definicin inicial es la principal causa del trabajo baldo en software. Esesencial una descripcin formal y detallada del mbito de la informacin, funciones, comportamiento,rendimiento, interfaces, ligaduras del diseo y criterios de validacin. Estas caractersticas pueden

determinarse slo despus de una exhaustiva comunicacin entre el cliente y el analista.

Mito. Los requisitos del proyecto cambian continuamente, pero los cambios puedenacomodarse fcilmente, ya que el software es flexible.

Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio vara

segn el momento en que se introduzca. La Figura 1.3 ilustra el impacto de los cambios. Si se ponecuidado al dar la definicin inicial, los cambios solicitados al principio pueden acomodarse fcilmente.El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impactoen el coste. Cuando los cambios se solicitan durante el diseo del software, el impacto en el costecrece rpidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de trabajodel diseo. Los cambios pueden producir trastornos que requieran recursos adicionales e importantesmodificaciones del diseo; es decir, coste adicional. Los cambios en la funcin, rendimiento, interfacesu otras caractersticas, durante la implementacin (codificacin y prueba) pueden tener un impactoimportante sobre el coste. Cuando se solicitan al final de un proyecto, los cambios pueden producir unorden de magnitud ms caro que el mismo cambio pedido al principio.

Mitos de los desarrolladores. Los mitos en los que an creen muchos desarrolladores se han

ido fomen - tando durante 50 aos de cultura informtica. Durante los primeros das del desarrollo delsoftware, la programacin se vea como un arte. Las viejas formas y actitudes tardan en morir.

Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo haterminado.

Realidad. Alguien dijo una vez: cuanto ms pronto se comience a escribir cdigo, ms setardar en terminarlo. Los datos industriales indican que entre el 60 y el 80 por ciento de todo el


3/3



esfuerzo dedicado a un programa se realizar despus de que se le haya entregado al cliente porprimera vez.

Mito. Hasta que no tengo el programa ejecutndo- se, realmente no tengo forma decomprobar su calidad.

Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos msefectivos para garan - tizar la calidad del software: la revisin tcnica formal. La revisin del software esun filtro de calidad que se ha comprobado que es ms efectivo que la prueba, para encontrar ciertasclases de defectos en el software.

Mito. Lo nico que se entrega al terminar el proyecto es el programa funcionando.

Realidad. Un programa que funciona es slo una parte de una configuracindel softwarequeincluye muchos elementos. La documentacin proporciona el funda mento para un buen desarrollo y,lo que es ms importante, proporciona guas para la tarea de mantenimiento del software.

Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente.Lamentablemente, las actitudes y mtodos habituales fomentan una pobre gestin y malas prcticastcnicas, incluso cuando la realidad dicta un mtodo mejor. El reconocimiento de las realidades delsoftware es el primer paso hacia la formulacin de soluciones prcticas para su desarrollo.

Documents

Leccion 4 - Mitos del software