Análise e deseño detallado de aplicacións de informática e de xestión/Mitos do software

En Galilibros, o Wikibooks en galego.


Moitas das causas da crise do software poden atoparse nunha mitoloxía que xurdiu durante os primeiros anos do desenvolvemento de software. Os mitos do software propagaron información errónea e confusión.

Mitos de xestión[editar]

«Xa temos un libro cheo de estándares e procedementos para construír software. Acaso iso non lle proporciona aos meus todo o que necesitan saber?».

Está moi ben que exista o libro, pero utilízase? Saben del os traballadores? Reflicte as prácticas actuais de desenvolvemento de software? É completo?

«Os meus dispoñen das ferramentas de desenvolvemento de software máis avanzadas. Despois de todo, mercámoslles os computadores máis modernos».

Para conseguir unha maior productividade e calidade son máis importantes as ferramentas de enxeñaría do software asistida por computador (CASE) que o hardware.

«Se fallamos na planificación, podemos engadir máis programadores e adiantar o tempo perdido».

O desenvolvemento de software non é un proceso mecánico como a fabricación, senón que adoita tratarse dun proceso artesanal. Engadir máis programadores, en vez de adiantar o proceso, adoita resultar nun atraso maior.

Mitos do cliente[editar]

«Unha declaración xeral dos obxectivos abonda para comezar a escribir os programas. Os detalles pódense dar máis adiante».

Unha mala definición inicial é a causa principal do traballo baldío no software.

«Os requisitos do proxecto cambian continuamente, pero os cambios poden acomodarse facilmente, xa que o software é flexible».

É certo que os requisitos do software cambian, pero o impacto do cambio varía segundo o momento en que se introduza. Se se pon coidado ao dar a definición inicial, os cambios solicitados ao principio poden acomodarse facilmente, mentres que se os cambios se solicitan durante o deseño do software, o impacto en custo crece rapidamente. Os cambios na función, o rendemento, as interfaces ou outras características durante a implantación (codificación e proba) poden ter un impacto moi importante no custo. Cando se solicitan ao final dun proxecto, os cambios poden producir unha orde de magnitude máis cara que o mesmo cambio pedido ao principio.

Nótese que un detalle insignificante para o cliente pode darlle un cambio completo a todo o traballo realizado.

Mitos dos desenvolvedores[editar]

«Unha vez escrito o programa e comprobado que funciona, o noso traballo acabou».

Máis da metade do esforzo adicado aos programas realízase despois de que estes se lles entreguen por vez primeira aos clientes.

«Ata que o programa non se está “executando” non teño forma de comprobar a súa calidade».

Dende o principio do proxecto se pode aplicar un dos mecanismos máis efectivos para garantir a calidade do software: a revisión técnica formal.

«O único que se entrega ao rematar o proxecto é o programa funcional».

Un programa funcional só é unha parte dunha configuración do software que inclúe programas, documentos e datos. O recoñecemento das realidades do software é o primeiro paso cara a formulación de solucións prácticas para o seu desenvolvemento. O intento da enxeñaría do software é proporcionar un marco de traballo para construír software con maior calidade.