Prova legale di quando una funzionalità è stata implementata [chiusa]

È una domanda legale quindi è necessario definire chiaramente i termini, altrimenti la risposta è, come in ogni domanda legale, "dipende".

La prima cosa che devi definire è quale "caratteristica" di cui sta parlando. Immagino che qualsiasi cosa si sia evoluta nel tempo, quindi è necessario concordare quale sia la funzionalità minima che comprende la "caratteristica" in questione. Può darsi che la funzione (o almeno le parti a cui si preoccupa l'avvocato) siano state completate molto prima (o più tardi) di quanto pensi. Sospetto che dovrai parlargli del suo ciclo di vita e delle modifiche apportate fino a quando non sarà in grado di stabilire il set di funzionalità che è rilevante.

In secondo luogo, cosa intendi con "completo"? In cima alla mia testa posso pensare a tre definizioni:

a) Codice completo: lo sviluppatore ha codificato tutto in una forma approssimativa di lavoro, ha eseguito alcuni test di base e lo ha controllato nel controllo del codice sorgente. Funziona bene come una definizione, in quanto il controllo del codice sorgente ti dà non solo una data, ma la possibilità di produrre una copia esatta di ciò che esisteva in quel momento.

b) Testato - il punto in cui qualcun altro ha verificato che funzioni. Penso che questo sia probabilmente il meno probabile in quanto il test di solito è solo un processo interno e dubito che abbia molto significato legalmente.

c) Rilasciato - il punto in cui è stato reso disponibile agli utenti. Potenzialmente significativo come potrebbe essere il punto in cui altri potrebbero essere stati in grado di scoprirlo e copiarlo.

Immagino che l'avvocato andrà con (a) perché sarà il primo dei tre e probabilmente è quello che sta cercando.

Se questo è il caso, stai cercando la prima versione nel controllo del codice sorgente in cui tutte la funzionalità riconosciuta come significativa era disponibile e funzionante: sarebbero stati gli algoritmi, l'interfaccia utente, il lotto.

Sebbene questo non possa contenere una "prova" rigorosa, poiché si tratta di un caso civile, è probabile che sia sufficiente a meno che non vi sia una buona ragione per dubitarne. In un caso civile l'onere non è "ragionevole dubbio", come in un caso criminale, è molto più basso. Ciò significa che se generi prove ragionevoli su qualcosa, dovranno produrre qualcosa per metterlo in discussione o sarà accettato.

Se è (b) o (c) la misurazione è ovvia ma probabilmente più difficile da stabilire in quanto si baserà su documentazione ed e-mail che non saranno altrettanto ordinate come controllo del codice sorgente, ma probabilmente sono dimostrabili con abbastanza lavoro sulle gambe .

Idealmente, naturalmente, produci le prove di tutti e tre - ciascuno rafforzando il precedente. Dopotutto, la data di rilascio è molto più credibile se è possibile mostrare una verifica di prova poco prima e il codice completo prima.

Ma prima di tutto - parla con lui e ottieni una definizione rigorosa dei termini.

Dato che stai utilizzando il controllo del codice sorgente, perché non verificare una versione del codice da o prima della data di scadenza, costruirla ed eseguirla e dimostrare che la funzione funziona?

Hai qualche email che indica che il cliente o gli utenti finali hanno, a un certo punto, utilizzato con successo quella funzione?

In caso contrario, forse se hai un processo di controllo qualità, potrebbe esserci un ingegnere di QA che avrebbe fatto delle note in un dato momento e "spuntato" una funzionalità come implementata, che potrebbe firmare una dichiarazione giurata.

Se questo fa parte della conformità, qualcuno fa una richiesta / diventa proprietario di una funzione e poi firma per approvazione. C'è documentazione e il codice associato, ma è difficile fornire la prova di una funzionalità solo con il codice. Questo potrebbe funzionare se sei controllato da un altro programmatore.

Tornando indietro, guarda il tuo codice e qualsiasi corrispondenza scritta che puoi trovare per indicare l'approvazione del proprietario. Una traccia email può essere un vantaggio maggiore.

Questa domanda non è particolarmente chiara. Ma se si desidera una "prova" del funzionamento di una funzione, è probabile che il cliente abbia bisogno di firmare che tale funzione è stata consegnata e ha funzionato correttamente. Altrimenti, non si può dire che la funzionalità sia stata consegnata e che ha funzionato.

Esegui un contratto in cui si afferma che la funzionalità è completata quando il cliente firma i test di accettazione per la funzione. Quando il cliente si disconnette, costituisce accettazione legale il completamento della funzionalità.

Se c'è un problema con gli intervalli di tempo, o il client sta trascinando i piedi al momento della firma delle funzioni, ci dovrebbe essere qualcosa nel contratto che ti consente specificamente di firmare la funzione da solo dimostrando che la funzione funziona in accordo con i requisiti di funzionalità dichiarati.

Inutile dire che i requisiti devono essere chiari e non ambigui.

Dato che hai usato il controllo del codice sorgente. Mi aspetterei che la soluzione più semplice sarebbe quella di trovare il check-in che ha implementato la funzionalità.

Questi dovrebbero essere datati e dovrebbe essere una prova sufficiente. Tuttavia, non sono un avvocato quindi non so se i registri informatici contano come prova sufficiente.

Se hai altra documentazione - specifiche dei requisiti ecc. queste dovrebbero essere datate e ti aiuteranno.

Se il tuo software è in qualche modo reso pubblico (come fornito ad altre società, rilasciato in un sito, ecc.) potresti dare quell'informazione, che la funzione era pubblica disponibile in quella release, che è stata resa pubblica in un sito / è stata consegnata ad alcuni clienti in una data.

Siamo in una situazione simile come un appaltatore. Per soddisfare la richiesta del cliente produciamo un documento che dettaglia l'implementazione del progetto o del miglioramento. Questo di solito è una raccolta di schermate. Questo è in bundle con il codice sorgente diff per la modifica specifica. Il cliente viene fatturato sulla base di una revisione del pacchetto.

Il cliente richiede carta. Le e-mail e il codice sorgente stesso non sono accettabili. Abbiamo una grande stanza piena della documentazione nel caso in cui veniamo controllati per il lavoro che abbiamo svolto. Sembra lavoro del governo? Ci puoi scommettere!

Direi che una funzionalità è stata implementata nella data in cui è stata rilasciata la finale (prima delle correzioni di bug). Se l'algoritmo è stato creato il 3/3/2001, ma l'interfaccia utente non è stata completata fino al 26/10/2001; la funzionalità sarebbe stata implementata il 26/10/2001. Quella data è la data di implementazione indipendentemente dalle correzioni di bug che si sono verificate successivamente.

La linea di fondo: la data di implementazione non è la data in cui il codice è stato archiviato, è la data in cui il codice è stato congelato per il rilascio.

Spero di non aver frainteso la tua domanda, e spero che questo aiuti.