Possiamo valutare un software basato sul numero di linee, sulla lingua, sulla tecnologia e su cose del genere? [chiuso]

La lingua è importante se il venditore fornisce al cliente il codice sorgente per apportare modifiche. Altrimenti, potrebbe essere importante per le prestazioni (un'applicazione desktop scritta in C significa che probabilmente si avvia più velocemente di qualcosa basato su un runtime virtuale come JRE o .NET).

Le linee di codice sono lì per dare al cliente che sta pensando di far girare la propria applicazione un'idea di quanto sforzo è effettivamente necessario per costruirlo. Onestamente 10k LOC è un software relativamente piccolo, quindi trovo strano che lo usassero come una dichiarazione di marketing, ma comunque, è per questo che lo faresti.

Modifica

Per rispondere alla tua domanda in modo più diretto, "il prezzo è basato su LOC?"

Sì, puoi. Moralmente, logicamente, qualunque cosa. Puoi valutarlo come preferisci. Indipendentemente dal fatto che il cliente lo comprerà, dipende esclusivamente da quanto sia convincente il tuo tono di vendita.

Serve a convincere i clienti che pensano di poterlo fare da soli in poche pagine di codice VB che è più difficile di quanto pensino e acquistare qualsiasi cosa venga venduta.

My question is that, can we morally and logically price a software based on these factors?

Che cosa c'entra la moralità? Per quanto riguarda la logica, molto dipende dal fatto che tu abbia un prodotto di nicchia o un prodotto del mercato di massa.

Non diventerai ricco sviluppando un prodotto di nicchia. L'obiettivo principale è realizzare un profitto, un profitto, un periodo. Quanto è costato sviluppare il prodotto è certamente una parte dell'equazione per un prodotto di nicchia, e la dimensione del codice è un fattore chiave nel costo di sviluppo. Guarda COCOMO, per esempio. La dimensione del codice è un fattore importante del costo di sviluppo stimato in COCOMO e rimane un fattore importante nei discendenti più moderni di COCOMO. Un altro fattore per il prezzo addebitato per i prodotti di nicchia è quanto costerebbe a qualcuno decodificare il prodotto, ma anche questo è altamente correlato con le dimensioni del codice.

L'economia cambia drasticamente se il prodotto è un prodotto del mercato di massa. La dimensione del codice è meno importante se hai molti, molti e molti clienti. Uno sviluppatore di giochi può ammortizzare assolutamente i costi di sviluppo astronomici per centinaia di migliaia o addirittura milioni di acquirenti.

È il marketing-speak. Spero che il tuo amico sappia che LOC (Linee di Codice) non ha alcuna relazione con la qualità del prodotto finale. L'analogia più vicina che mi viene in mente in questo momento sarebbe quella di vendere auto con informazioni di marketing che vantano il numero di viti e dispositivi di fissaggio nell'auto. Il numero di viti utilizzate per tenere insieme una macchina sarebbe il fattore decisivo (o addirittura lo sarebbe affatto) quando si acquista una macchina?

Il marketing basato sulla lingua potrebbe importare se il cliente eseguirà la programmazione di integrazione o eseguirà su una determinata piattaforma.

Se il cliente vuole comprare un programma che ha più LOC di un altro programma, va bene, anche se non ha molto senso.

La questione di "è morale / etica?" ... Vantarsi di LOC è una metrica inutile e prede ai clienti che non conosce meglio e pensa "più LOC = > Programma migliore ", quindi direi NO .

Dipende dal tipo di software .

Per un ambiente di sviluppo integrato (IDE) o altro strumento software, la lingua è fondamentale.

Per una libreria di terze parti, il numero di righe di codice può entrare in gioco se l'ingombro della distribuzione è un problema. Anche la lingua è importante in quanto potrebbe limitare l'interoperabilità.

Per il software applicativo su richiesta o su richiesta, sembrerebbe strano che la lingua o il numero di righe di codice siano parte della funzione che determina il costo del prodotto. Dal punto di vista del cliente, il valore che il software fornisce a loro viene valutato rispetto al costo di eseguire l'attività manualmente (o con una soluzione più economica). Il cliente non si preoccuperà di quante linee di codice ci sono o quale lingua viene usata, se ha il compito di farle.

Se gli sviluppatori sono i consumatori (diretti o indiretti) di un software, l'implementazione (lingua, sistema operativo, linee di codice, ecc.) può apparire nell'equazione dei prezzi. Supponendo che non ci siano problemi di prestazioni con le scelte di implementazione, ad altri tipi di clienti non interessa.

Nel caso dell'applicazione di inventario del tuo amico, mi sembra stupido a me pubblicizzarlo in quel modo.

La conoscenza della lingua è utile per il cliente che desidera estendere l'applicazione. Preferirei un sistema che usasse C # e un database MSSQL su uno che usava Java e Oracle, semplicemente perché ci sono più sviluppatori .Net che sviluppatori Java nella mia regione, e ottengono un premio inferiore. A prescindere dalle applicazioni che consentono lo sviluppo personalizzato, l'affermazione linguistica non è immorale, è solo un marketing scadente, poiché nessuno a cui non interessano interessa la lingua in cui è scritto. Ricorda, la maggior parte degli utenti non conosce la differenza tra VB e binario, e loro davvero non si preoccupano di.

Per quanto riguarda LoC, la maggior parte delle aziende probabilmente usa questo come un punto in cui il loro prodotto è "super potente", ma sarei molto più impressionato da un sistema ERP scritto in 500 LoC rispetto a uno scritto in 500.000, perché il 500 la versione della linea è esponenzialmente più facile da mantenere ed estendere. Ancora una volta, non è proprio non etico, soprattutto perché è qualcosa che non si troverà da nessuna parte sul radar per gli utenti, e potrebbe effettivamente dissuadere gli sviluppatori dall'acquistare.

In breve, no, non basano il tuo schema tariffario su qualcosa che è al 90% arbitrario e il cliente non associa alcun valore. Non è tanto una questione etica, ma più di un cosa di business di base. Sarebbe come se ti venissero addebitati i biglietti aerei in base alla pesantezza dell'aereo e alla marca di noccioline che ottieni sul volo.

Ho appena trascorso 5 minuti a refactoring di 30 righe di codice, in 10 righe di codice facendo la stessa cosa. Se è stato utilizzato il framework corretto, queste righe di codice potrebbero essere ridotte a una riga o a una configurazione per l'associazione e la convalida dei dati.

Ho appena ridotto il valore del codice a un terzo del suo originale?

Certianly, le tecnologie utilizzate, l'architettura e il database sono considerazioni valide quando si sceglie una soluzione per la propria azienda. Il numero di linee di codice sembra essere uno slogan per lo più irrilevante, anche se forse interessante. Anche se in C # potrebbe essere fuorviante perché posso mettere tutte le istruzioni su una riga per metodo e fare molto e far sembrare che abbia meno linee o spazio e farlo sembrare più. Questo non dice nulla sulla qualità o l'efficacia del prodotto.

Il prezzo è una questione di mercato. Se riesci a vendere un prodotto che ti ha portato 20 minuti a guadagnare 8 miliardi di dollari per un'azienda che ne farà di più, allora ti dico bene. Il prezzo per riga di codice non è probabilmente un modello di business di successo, direi.