Costi di sviluppo del software e influenze [chiuso]

Bene, a seconda di chi credi, Healthcare.gov costa tra $ 70 milioni e ... chiamiamolo anche $ 100 similiani-Quintilioni (penso che possiamo essere tutti d'accordo sul fatto che sia sicuramente da qualche parte lì dentro.)

Nelle notizie precedenti, progetti di modernizzazione dell'IRS costano da "centinaia di milioni" a $ 4 miliardi. Non ho personalmente costruito molti grattacieli , naturalmente, ma mi sembra una grossa somma di denaro.

Personalmente, parlando con i dirigenti di alcune compagnie assicurative locali, mi viene detto che un progetto di modernizzazione dell'eredità "di medie dimensioni" può costare $ 40-50 milioni per un certo numero di anni, e questo è solo per la propria azienda da utilizzare. Questi sistemi a volte sostituiscono - I kid you not not - scrolls. (Sono serio - alcuni vecchi documenti assicurativi sono rotoli di carta controllati dal clima chiusi in tubi nel seminterrato perché sono aggiornati di rado ma ancora attivi per molti anni.)

Un'azienda di medie dimensioni può facilmente avere una numerazione dello staff di sviluppo su migliaia, e tutti dovrebbero lavorare su parti di software interconnesse - con relativamente pochi lavori veramente isolati.

Che cosa succede quando si fa a pezzi?

Bene, che ne dici di uccidere le persone? uccide le persone? (Therac-25 ha ucciso persone con overdose di radiazioni negli anni '80). Knight Capital ha perso circa $ 440 milioni in 45 minuti da un problema software: puoi comprare un grattacielo per così tanto? Beh, forse un po '...

I razzi sono esplosi a mezz'aria, come Ariane 5 . Le perdite di NBA di Edward Snowden sono state rese possibili da problemi nell'implementazione dei sistemi di sicurezza. Diamine, l'intero sistema di sorveglianza globale che ha fatto tanti titoli (e probabilmente non ne ha abbastanza) è, di fatto, probabilmente uno sforzo software molto più ampio di qualsiasi di questi progetti menzionati in precedenza. Se conta o meno come un errore, deve essere lasciato al parere del lettore.

Ma onestamente, entrare in un concorso di misurazione dei grattacieli è raramente un modo produttivo per trascorrere il proprio tempo. Resta il fatto che alcuni progetti software sono grandi e hanno bisogno di pianificazione, a volte più o meno di quanto effettivamente fatto, e di altri progetti? Beh, non sono così grandi, e quindi non è sempre necessario avere una grande richiesta / fase di pianificazione in stile cascata.

Come sempre, non è la dimensione del budget che conta ...

Una delle maggiori influenze nella progettazione di software agile è in realtà il motivo per cui le stime dei costi del software sono così difficili da ottenere: software riutilizzabile.

La cosa complicata del software riutilizzabile è che tende a inserirsi in una scomoda via di mezzo tra "soluzioni pronte all'uso" e "costruisci da zero". Non è sempre ovvio come determinare se il software può essere riutilizzato o meno. In effetti, in molti casi ho scoperto che è più economico uscire e costruire il prodotto piuttosto che ottenere un ragionevole errore legato a quanto tempo impiegherebbe!

Sarebbe l'ideale per noi per costruire un discreto repertorio di soluzioni pacchettizzate, ma il mondo del software si muove in modo incredibilmente veloce rispetto ad altri mondi (come l'ingegneria civile). Nel corso del tempo, abbiamo riscontrato che il costo di confezionare una soluzione in modo corretto raramente si ripaga da solo perché il pacchetto diventa obsoleto troppo velocemente.

Questo porta alla differenza interessante tra ingegneria civile e software: le influenze dell'ingegneria del software sono positive, mentre quelle civili sembrano negative. Raramente abbiamo un ampio panorama di vincoli con cui lavorare. Non abbiamo tanti regolamenti o limiti ambientali da considerare. Tuttavia, abbiamo un numero incredibile di influenze positive da considerare. Se un progetto si adatta bene a un particolare blocco di bontà parzialmente impacchettato di un progetto precedente, posso interrompere un lungo periodo di pausa. Se non si adatta, devo costruirlo da zero.

In realtà ho dato questa stima al mio capo una volta: "il lavoro richiederà tra 1,5 giorni e 18 mesi-uomo". Non era contento, inutile dirlo, ma quando ho capito la mia logica del perché la variabilità fosse lì, è stato costretto ad accettare. (La soluzione, a proposito, è che siamo stati agili: abbiamo trascorso gli 1,5 giorni per provare a farlo nel modo più semplice. Se avessimo fallito, saremmo tornati a discutere se valesse la pena dei nostri dollari farlo duramente Alla fine, il modo semplice ha funzionato).

C'è un sacco di opinioni nel mondo agile secondo cui la pianificazione funziona davvero contro di te. I requisiti funzionano in entrambe le direzioni. Racconta all'appaltatore cosa produrre, ma dà anche loro un pezzo di carta potente per dire "questo è tutto ciò che mi hai detto di fare, così l'ho fatto". Questa spada a doppio taglio spesso costringe i clienti a scrivere requisiti che impediscono la soluzione di 1,5 giorni. Anche i contratti governativi stanno abbandonando la pianificazione dei requisiti big-up-front perché i benefici superano i vantaggi.

1. What are the costs figures of a big software construction project? Any published large scale well known projects documentation I can get numbers from?

Ci sono molti progetti che hanno vari livelli di informazioni disponibili al pubblico sui costi del progetto. La documentazione è comunemente disponibile sotto forma di case study. L'istituto di gestione del progetto ha una biblioteca di casi studio e molti altri documenti simili sono disponibile tramite una ricerca sul Web per dire "casi studio in progetti IT".

2. What are a software project influences (besides the goal of the project itself)?

Questa è una domanda ampia, ma concentrandomi sui costi i due maggiori impatti per il costo rispetto alle analisi nella mia esperienza sono:

1. Scarso controllo sull'ambito del progetto e,
2. Autovalutazione ottimistica della capacità dei membri del team / subappaltatori di stimare lo sforzo.

Un buon controllo dell'ambito riguarda la definizione di una dichiarazione di lavoro concordata e, soprattutto, un metodo disciplinato per la regolazione degli orari e delle stime dei costi quando il cliente richiede modifiche alla dichiarazione di lavoro. Le cause per le richieste di modifica sono normalmente valide e comportano sempre un costo in termini di tempo e denaro.

L'autovalutazione eccessivamente ottimistica viene solitamente mitigata utilizzando un'analisi PERT in cui la stima dei costi si basa sulla media ponderata di tre stime separate che sono ottimistiche, realistiche e pessimistiche.

Con ciò ci sono altre influenze sui costi che dipendono dalla scala del progetto, ognuna con metodi di mitigazione ben stabiliti. Alcuni di questi includono, in nessun ordine particolare:

• l'inflazione
• tassi di cambio estero
• fallimenti aziendali (Arthur Anderson come esempio)
• riorganizzazioni all'interno dell'azienda cliente
• perdita della chiave personale (dimissioni, riassegnazione, malattia, morte)
• membri del team poco esperti
• meccanismi di controllo dei costi inefficaci
• tecniche di sviluppo dei prodotti scadenti
• frode