Análise e deseño detallado de aplicacións de informática e de xestión/Estimación de custos e prazos en proxectos de software

Engadir ligazóns
En Galilibros, o Wikibooks en galego.


Observacións[editar]

A principal unidade de medición dos custos dun proxecto adoita ser o número de salarios mensuais ou anuais que deben pagarse. Os salarios adoitan especificarse en persoas-mes ou persoas-ano.

Algúns autores consideran que aparte das peculiaridades do software existen outras razóns que dificultan a estimación dos custos e prazos dos proxectos. Entre elas cómpre salientar as presións políticas na empresa ─para diminuír o custo ou os prazos necesarios─ e o feito de que existe unha carencia xeneralizada de datos sobre proxectos rematados.

A medida que se avanza no proxecto, obtense unha maior cantidade de detalles e de información máis fiable, polo que a precisión da estimación mellora progresivamente.

A complexidade do proxecto ten un gran efecto na incerteza, que é inherente á planificación. Porén, a complexidade é unha medida relativa que se ve afectada pola familiaridade con esforzos anteriores.

O tamaño do proxecto é outro factor importante que pode afectar á precisión das estimacións. O problema da descomposición, un enfoque importante cara a estimación, vólvese máis difícil porque os elementos descompostos poden ser aínda excesivamente grandes.

O grao de incerteza estrutural ten tamén efecto no risco da estimación.

A dispoñibilidade de información histórica tamén determina o risco da estimación.

Métodos de estimación de custos[editar]

Existen catro tipos de métodos para a estimación dos custos dos proxectos de software:

A opinión de expertos.
A estimación por analoxía.
Consiste nunha variante máis formal da opinión de expertos na que se compara o proxecto que se vai desenvolver con un ou máis proxectos rematados dos que se dispón de datos.
A descomposición.
Consiste en descompoñer o produto que se vai construír nos seus compoñentes ata conseguir un nivel de detalle tal que se poida estimar directamente o custo de cada unha das súas unidades elementais.
Ecuacións ou modelos de estimación.
En xeral, trátase de fórmulas matemáticas que relacionan os diversos parámetros do proxecto (tamaño do software a construír, condicións do ambiente do proxecto, etc.) co custo ou esforzo necesario.

Algúns autores falan tamén do “prezo para gañar” e da “lei de Parkinson” como técnicas para a estimación:

O prezo para gañar.
Implica que se debe empregar como estimación o custo que nas negociacións co cliente permita obter o contrato.
A lei de Parkinson.
Indica que o traballo se expande ata ocupar todos os recursos dispoñibles (entre eles o tempo).

Xuízo de expertos[editar]

Adoita empregarse a opinión de máis dun experto para obter unha maior fiabilidade na estimación.

Nalgúns casos simplemente se calcula a media dos valores ofrecidos polas distintas persoas. Isto implica o risco de que a estimación obtida poida resentirse moito a causa dun par de valores extremos.

Tamén se pode efectuar unha reunión tan longa como sexa preciso ata chegar a un consenso, pero córrese o risco de que as persoas de maior influencia sexan as que determinen o resultado final.

A técnica máis coñecida é a técnica “Delphi”, cuxa mecánica é un proceso que consta dos seguintes pasos:

  1. Un coordinador proporciona a cada experto unha especificación do proxecto proposto e un impreso para expresar a súa opinión.
  2. Os expertos enchen o impreso de forma anónima. Poden facerlle preguntas ao coordinador acerca do proxecto, pero non poden intercambiar opinións entre eles.
  3. O coordinador ofrece a cada experto o valor medio das opinións para que o compare co seu. Pídeselle entón que realice unha nova estimación indicando as posibles razóns da mesma.
  4. Repítese o proceso ata que se chega a un consenso na estimación.
Non se realiza ningunha reunión de grupo durante todo o proceso.

Boehm refinou esta técnica e propuxo a unha variación co nome “Delphi de banda ancha”, que parece dar mellores resultados. Consiste nun proceso que consta dos seguintes pasos:

  1. O coordinador proporciona a cada experto unha especificación do proxecto proposto e un impreso.
  2. O coordinador reúne aos expertos para que intercambien puntos de vista sobre o proxecto.
  3. Os expertos enchen o impreso de forma anónima.
  4. O coordinador ofrece a cada experto un resumo co valor medio das opinións para que o compare coa súa opinión persoal. Pídeselle entón que realice unha nova estimación anónima, sen indicar as posibles razóns da mesma.
  5. O coordinador convoca unha reunión de grupo para que os expertos discutan as razóns das diferencias entre as súas estimacións.
  6. Énchense anonimamente os impresos e repítense os puntos 4, 5 e 6 ─este─ ata chegarse a un consenso.

A vantaxe da opinión de expertos é que permite contemplar as diferencias entre experiencias anteriores e o proxecto actual difíciles de avaliar sen recorrer a persoas experimentadas.

A desvantaxe da técnica é a subxectividade e maila inexperiencia que poden amosar as persoas ás que se consulta.

Estimación por analoxía[editar]

Esta técnica constitúe un complemento á do xuízo de expertos. Nela, as persoas involucradas non só traballan coa súa experiencia acumulada, senón que dispoñen tamén de datos de proxectos acabados relativamente similares ao que se vai estimar. Así, por comparación, pódense avaliar as diferencias entre o novo proxecto e mailos antigos e extrapolar o seu custo.

Por outra banda, cando se dispón de bastantes datos de proxectos rematados, pódese mellorar a analoxía. Así, seleccionando dous proxectos parecidos ao actual, un maior e outro menor, pódese obter unha mellor estimación interpolando os valores de ambos.

A principal vantaxe desta técnica é que está baseada na experiencia real dos proxectos e non unicamente na subxectiva.

O inconveniente máis significativo é que resulta difícil coñecer realmente o grao de similitude do proxecto que se usa de referencia e o proxecto a realizar.

Estimación por descomposición[editar]

Nesta técnica o responsable de cada compoñente do software que hai que construír estima o custo do seu desenvolvemento. A estimación para o proxecto completo calcúlase mediante a suma das cantidades parciais.

Para poder aplicar esta técnica cun mínimo de eficacia precísase dispoñer dun diagrama de descomposición do produto, que adoita crearse na planificación do proxecto e que representa a xerarquía do produto. A técnica adoita complementarse cun diagrama de descomposición de actividades do proxecto que indica a xerarquía das tarefas do proxecto. Deste xeito asegúrase que actividades coma a integración dos compoñentes ou a xestión da configuración queden reflectidas na estimación do custo.

Outro aspecto a ter en conta na estimación de cada tarefa do proxecto por parte do seu responsable son as vantaxes e inconvenientes que representa.

Por unha banda, este enfoque obriga a comprender mellor a tarefa a desenvolver e permite a cada compoñente do equipo de desenvolvemento planear o seu traballo, asegurando o compromiso persoal de cada un coa estimación obtida.

Os inconvenientes proceden da dificultade para considerar dúas posibles fontes adicionais de custo:

  • Actividades relacionadas co proxecto que non adoitan incluírse na definición do mesmo ─por exemplo, ler código, revisar, reunirse, etc.─. Segundo un estudo de Boehm estes custos poden supoñer o 40% do custo total do proxecto.
  • Actividades non relacionadas co proxecto. Un estudo sobre os hábitos de traballo diario de 70 programadores deu como resultado que un 30% do tempo se dedicaba a formación, asuntos persoais, etc.

Para rematar, cómpre lembrarmos que a análise xerárquica para a estimación admite que, unha vez estimado o custo total do proxecto, se poida saber que parte do mesmo se asigna a cada un dos compoñentes do software ou a cada tarefa do desenvolvemento.


Traído desde «https://gl.wikibooks.org/w/index.php?title=Análise_e_deseño_detallado_de_aplicacións_de_informática_e_de_xestión/Estimación_de_custos_e_prazos_en_proxectos_de_software&oldid=10851»