Codice sorgente e requisiti della documentazione del progetto per un accordo legale [chiuso]

0

Domanda

Che tipo di documentazione e altri artefatti ti aspetteresti di ottenere in caso di rilevare la webapp Java esistente (probabilmente usa il framework JBoss Seam) resa in-house ?

Mi aspetto di ottenere:

  • Codice sorgente nel modulo pronto per l'apertura nell'IDE specificato.
  • Tutti gli elementi esterni (ovvero lo schema DB come script SQL, script di installazione).
  • File di configurazione (sia per gli ambienti di sviluppo, test e di produzione).
  • Tutte le librerie esterne necessarie per progetto.
  • Tutti gli strumenti esterni utilizzati nel progetto o almeno la loro descrizione (ad esempio, crea programma, software di controllo della versione).
  • Informazioni dettagliate su:

    • Come compilare il progetto (IDE, librerie, loro versioni, compilatori, sistema operativo),
    • Come configurare l'ambiente di sviluppo (versione del database, sistema operativo, schema DB),
    • Come installare ed eseguire applicazioni - specifiche del server (sistema operativo, database, versioni, hardware minimo, configurazione sia dell'app che del DB),

Probabilmente sarebbe bello avere:

  • Archivio dell'intero sistema di controllo della versione (per rendere possibile il controllo delle modifiche rispetto al passato).
  • Diagrammi UML o altra forma di immagine grande del design dell'applicazione.
  • schema DB.

Cosa mi manca?

Alcuni dettagli sullo sfondo

L'amico lavora come avvocato per un'azienda che ha bisogno di accordi legali con persone che sviluppano applicazioni per loro. Nel caso qualcosa vada storto.

In generale, la società desidera che il codice sorgente venga depositato da qualche parte. Ma il codice sorgente non è sufficiente per mantenere o anche compilare ed eseguire webapp, quindi hanno anche bisogno di una documentazione che aiuti a mantenere l'app.

Non ho mai preso il progetto di qualcun altro in un caso simile (nessun accesso agli sviluppatori precedenti), e io non sono uno sviluppatore Java, quindi mi aspetto che ci siano molte cose da perdere.

Ulteriori dettagli aggiunti dopo alcune risposte

I padroni della società (lo hanno chiamato A , piccola società), che ha ordinato e utilizza l'app e la società (lo ha chiamato B , poche persone) che scrive il app, sono amici.

Lo sviluppo è in-house . Nessuna specifica formale, nessuna specifica scritta. Tutte le funzionalità sono discusse per posta o in riunione.

Tutto, inclusa l'hosting dell'app, è gestito da B .

Amico (che è anche uno dei grossi utenti dell'app - diciamo che è product owner ) non si fida affatto degli sviluppatori di B .

Anche l'amico non crede alle competenze di B (credimi, non dovrebbe).

Quindi per proteggere Un amico d'affari vuole un accordo legale scritto con B nel caso in cui B vada via con A dati e app ...

Poiché MSalters ha scritto - non ridere - succede: (.

A già realizzato B per creare e fornire backup.

    
posta Grzegorz Gierlik 16.09.2011 - 12:39
fonte

5 risposte

3

Source code in form ready to open in specified IDE

sopra, sebbene piacevole da avere, si sente piuttosto scivoloso - lasciando troppo spazio per fare i conti con la versione IDE, i plug-in, la configurazione. "oh dal modo in cui funziona solo se installi e abiliti il plugin Habracadabra v 6.6.6. E, hey, nel caso in cui tu non lo sappia, questa versione di Habracadabra funziona solo con Netclipse 3.4.5 "

  • Al momento di assumere il controllo preferisco insistere sul fatto che il codice sorgente sia pronto per essere creato dalla riga di comando

  • Inoltre, nel caso in cui "loro" utilizzino il tracker dei problemi per il progetto, farei del mio meglio per spremere tutti i dati su questi problemi in qualche modo ( tutti i problemi nel tracker , non importa se sono fissi o meno) - prendendo completamente il tracker del problema o ottenendo un accesso di sola lettura ad esso o al almeno ottenendo una "istantanea" con qualsiasi mezzo.

    Le informazioni memorizzate in un tracker dei problemi potrebbero essere di grande aiuto per il maintainer

aggiornamento Non posso sapere se questo si qualifica come un artefatto ma dati i dettagli forniti in seguito, prenderei in considerazione una sorta di contratto di servizio-assistenza per "legare" in qualche modo i propri sviluppatori a rispondere a domande sull'applicazione.

  • "Per i primi 3 (4,5) mesi è il momento di rispondere entro 8 ore, supponendo 100 o meno domande a settimana. Per i prossimi 3-6 mesi è tempo di rispondere entro 24 ore, assumendo 10 o meno domande a settimana ... "
risposta data 16.09.2011 - 12:53
fonte
2

Devo gestire più di alcuni progetti di sviluppo in outsourcing. Un trucco per assicurarsi di ottenere un progetto eseguibile e realizzabile è assicurarsi di possedere e ospitare il server di controllo del codice sorgente e creare gli ambienti / qa. Per definizione avrai una copia eseguibile e eseguibile del progetto con una cronologia completa.

    
risposta data 16.09.2011 - 14:02
fonte
1

I seguenti punti potrebbero essere d'aiuto:

  • (JUnit) Test
  • JavaDoc (generato automaticamente dal codice sorgente, potrebbe dare un buon indizio sulla qualità)

Ma in generale, un trasferimento di conoscenze tra uno degli sviluppatori e i manutentori nuovi potrebbe essere "una buona cosa" (tm).

Visto che l'app web è stata ordinata dalla società, la società ha documenti / specifiche decenti su ciò che vogliono avere?

    
risposta data 16.09.2011 - 13:27
fonte
1

"docs / specs" (citato da Turbo) è davvero un ottimo punto. Si potrebbe voler aggiungere anche i requisiti originali e il database corrente del tracker dei problemi. Quando vengono gestiti tramite e-mail (non ridere, succede) preferiresti quelle e-mail e dovresti caricare il client per inserirle in un tracker dei problemi appropriato.

    
risposta data 16.09.2011 - 13:36
fonte
0

Tutti i documenti sono importanti ma ho un trucco che funziona abbastanza bene. Molti sviluppatori cambiano semplicemente il codice e talvolta l'architettura statica. Sono così coinvolti nel lavoro che di solito scrivono solo un javadoc veloce che rende quasi impossibile capire cosa è stato fatto.

Il mio trucco è chiedere allo sviluppatore di invertire il pacchetto in un diagramma di classe ogni volta che aggiunge / cambia qualcosa nell'architettura che è usata da altri oggetti. Non ho bisogno di molto solo un diagramma di classi visive che viene effettuato automaticamente dagli strumenti e da una nota grafica sulla classe e sui metodi. Se è necessario altro, chiedo una nota dettagliata direttamente nell'oggetto UML a livello di modello. Significa che se qualcun altro vuole aggiungere un nuovo codice a un codice esistente sarà in grado di aprire il pacchetto, vedere la struttura e i metodi commerciali nel profilo dell'IDE e navigare nel codice con la documentazione disponibile come diagrammi delle classi usando il mouse fare clic su ogni classe per avere questa documentazione specifica della classe. Intendo dire che lui / lei può navigare nel codice con il codice, il contorno, leggere javadoc e quindi navigare nell'architettura dell'oggetto usando i diagrammi e facendo clic sulla classe all'interno del diagramma che aprirà un menu di descrizione in cui le informazioni sono state salvato.

Il risultato è impressionante perché i diagrammi delle classi sono davvero facili da creare, la documentazione è di soli due minuti e il nuovo sviluppatore può iniziare a codificare quasi immediatamente nel progetto senza rompere il codice esistente. Questo trucco UML funziona solo con progetti java / jee per il diagramma delle classi. Non appena si introduce più di un diagramma, il progetto diventa pesante per gli sviluppatori che prima o poi rifiutano o dimenticano di creare diagrammi. I diagrammi di classe che hanno la stessa struttura di oggetti del codice sono facili, veloci da creare e leggere e davvero migliorare la produttività. Ho dimenticato di dire che è necessario riuscire a unire il codice esistente con il nuovo modello per avere un ciclo completo. Raccomanderei quindi il codice live e la sincronizzazione del modello quando il diagramma delle classi UML è aperto, ma dovresti anche essere in grado di chiudere i tuoi diagrammi per concentrarti sul codice e aprirlo quando ne hai bisogno. Questa è l'opzione di fusione.

Il mio trucco funziona solo a livello di codice con annotazioni java, anch'esse invertite e gestite dallo strumento. Di solito uso JBoss o Weblogic con database Oracle o MySQL.

    
risposta data 17.09.2011 - 19:44
fonte

Leggi altre domande sui tag