Quali linee guida per la consegna del software sono appropriate quando si esternalizzano?

3

Ho iniziato a lavorare in una piccola azienda che regolarmente (non troppo spesso) deve esternalizzare alcuni sviluppi del software. I fornitori esterni devono consegnare qualcosa. Come ho visto ora, i fornitori offrono una qualità molto variabile dei deliverable - questo copre a volte solo l'eseguibile binario (nessuna fonte), la documentazione mancante, nessuna descrizione dell'interfaccia, ...
Dato che non sono un esperto di software ora, voglio ancora fare una baseline e sto cercando un tipo di standard / best practice generiche che possano essere utilizzate per i contratti ecc. - contenente ciò che la consegna dovrebbe contenere come:

  • l'eseguibile
  • il codice sorgente
  • descrizione della toolchain (riferimento a come creare il codice)
  • documentazione
  • descrizione dell'interfaccia
  • standard di codifica generici (forse qualcosa che non è specifico come MISAR XY)

.. e quale è il minimo per quello (sui punti citati) - e cosa manca. Sono disponibili standard IEEE / RFC / ITF per questo tipo di linee guida per la consegna del software?
Nella mia ultima società, ci sono stati esperti che hanno lavorato su questo argomento che hanno creato questo tipo di documento (elenco di documenti / risultati richiesti) per contratto / fornitore.

    
posta m.weiloa 27.09.2018 - 00:31
fonte

2 risposte

2

Non sono a conoscenza di tali standard.

In definitiva, un subappaltatore dovrebbe consegnare tutto ciò che è stato incaricato di consegnare. Se vuoi documentazione, dovrebbe dirlo nel contratto. Lo stesso vale per il codice sorgente, i progetti o qualsiasi altra cosa.

Quindi, se non sei soddisfatto di ciò che viene consegnato, dai un'occhiata a ciò che hai contratto per consegnarlo e (come azienda) chiediti se il tuo processo di subappalto è sufficientemente solido.

Non è nell'interesse del subappaltatore consegnare qualcosa di più di un binario e qualche nota di rilascio. Se ti danno tutto, allora puoi fare gli aggiornamenti da solo, invece di pagare loro per miglioramenti.

    
risposta data 27.09.2018 - 11:31
fonte
1

Per quanto ne so, non esiste uno standard per questo, anche se dovresti sicuramente supportare una linea di base per il software per le esigenze della tua azienda.

Una buona idea sarebbe quella di stabilire una struttura di progetto di base, per organizzare al meglio il progetto e come sarà usato, qualcosa del tipo:

project root 
  \_ source
       \_ build.sh / build.bat
  \_ bin
      \_ project executable
      \_ resources
  \_ doc

Dove avviare build.sh o build.bat dovrebbe produrre project.exe nella cartella bin e l'eseguibile dovrebbe essere chiamato di conseguenza. Altri eseguibili possono essere presenti e necessari. La cartella di origine può essere organizzata in qualsiasi modo sia la più conveniente per il team di sviluppo. Allo stesso modo, la cartella bin può essere organizzata nel modo più conveniente per il team di sviluppo, resistendo all'esecuzione.

La cartella delle risorse ha lo scopo di fornire qualsiasi libreria aggiuntiva o file di riferimento necessari affinché l'eseguibile funzioni.

La cartella doc dovrebbe fornire l'utilizzo di base e come chiamare. È possibile aggiungere anche una documentazione tecnica aggiuntiva, ma l'utilizzo delle chiamate di base deve esistere (e deve riflettere la versione corrente della build). Se c'è un'interfaccia da implementare, allora dovrebbe esserci una documentazione completa di detta interfaccia e come sarà usata. Uno di questi documenti per ciascuna interfaccia API (per facilità di accesso).

Sei libero di cambiarlo un po ', ma qualcosa del genere sarebbe una buona base e sarebbe flessibile per lo sviluppatore.

Alcuni consigli per te, richiederei necessariamente che il codice sorgente fosse presente ogni volta. Se la tua azienda paga per la realizzazione del software, il codice del software ti consentirà di ricrearlo interamente da zero ed è tuo diritto chiederlo.

Su una nota più discreta, se non ti fidi di questa terza parte, dovresti anche insistere sul fatto che inizialmente non è presente alcun eseguibile e che è creato ogni volta. Questo richiede più tempo e potrebbero obiettare che è meno conveniente per te, ma è una garanzia che il programma corrisponda al codice sorgente che viene creato.

    
risposta data 27.09.2018 - 09:02
fonte