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.
Saltar ata a navegación Saltar á procura


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.