Abbiamo bisogno di adottare un asset black-box che il nostro progetto sta ereditando dal suo predecessore?

3

Il nostro cliente ha un sito eCommerce sviluppato da un team interno e che ora mostra la sua età. Lavoro per una ditta portata avanti come appaltatori esterni per costruire un sostituto. Parte del sito corrente è un'applet di visualizzazione Flash che visualizza i contenuti multimediali del prodotto: immagini zoomabili, visualizzazioni a 360 gradi, filmati e così via. Dobbiamo mostrare gli stessi media del sito attuale, quindi stiamo semplicemente riutilizzando il visualizzatore.

Il visualizzatore è incorporato in una pagina nel solito modo e ha detto quali media mostrare per mezzo di un File XML caricato dal nostro server, che è piuttosto semplice da generare. Abbiamo questo lavoro; è stato piuttosto semplice.

Ma che altro dobbiamo fare?

Il fatto è che, per quanto ci riguarda, il visualizzatore è un blob binario che viene servito dalla rete di distribuzione del contenuto del client. Lo incorporiamo, lo alimentiamo dell'XML e fa il suo lavoro, ma non abbiamo alcun potere sui suoi interni. È completamente opaco per noi - una scatola nera. Possiamo usarlo per fare quello che fa, ma non possiamo cambiarlo, quindi se mai dovessimo fare qualcosa di diverso, siamo impagliati.

Stiamo costruendo questo sito per il cliente, e quando avremo finito, lo consegneremo per loro da mantenere. Non faremo la manutenzione da soli. C'è una piccola squadra all'interno del cliente che lavora come parte del nostro team e chi sarà il responsabile della manutenzione. Quella squadra include solo una persona del team che ha costruito il vecchio sito e non è qualcuno che conosce il visualizzatore di immagini. Le persone che conoscono il visualizzatore di immagini non hanno l'intenzione di unirsi al nostro team quando il nostro sistema sostituisce il loro: verranno spostati in altri progetti. La documentazione sul visualizzatore è estremamente sottile e, per quanto ne so, non copre affatto l'interno.

La mia preoccupazione è che se qualcuno non intraprende alcuna azione positiva, tutta la conoscenza del funzionamento interno dello spettatore, persino fino al punto in cui si trova il codice sorgente, verrà persa. È possibile che lo sia già stato.

È qualcosa di cui preoccuparsi? Se sì, di chi è il compito di preoccuparsene? Cosa dovrebbero fare a riguardo una volta che si sono preoccupati?

    
posta Tom Anderson 07.01.2011 - 20:10
fonte

3 risposte

1

Come vedo io hai una scelta tra due problemi. Le scatole nere raramente hanno funzionato per me e sono difficili da nutrire e curare. Tuttavia, hai capito quella parte - qualcosa che funziona per ora. D'altra parte, mentre esiste la tecnologia per sostituire la scatola nera, devi determinare se è che vale sostituire.

Pro per mantenere la scatola nera

  • È attivo.
  • Fa tutto ciò di cui il tuo cliente ha bisogno in questo momento.

Contro per mantenere la scatola nera

  • È sconosciuto, sia per quanto riguarda la stabilità che la sicurezza
  • L'integrazione è un kludge e probabilmente fragile

Pro per la sostituzione della scatola nera

  • Hai il controllo sul funzionamento interno
  • Puoi estenderlo per fare cose nuove a cui il tuo cliente non ha ancora pensato.

Contro per la sostituzione della scatola nera

  • Se lo costruisci, devi supportarlo
  • Potrebbe essere un progetto più grande del previsto (questo è un grosso rischio potenziale)

Dovrai fare la tua due diligence per arricchire questi tavoli pro / contro con le informazioni che hai. Se fossi nei tuoi panni, sapendo che la soluzione funziona, e sapendo che la relazione non intende essere una relazione continua, sceglierei di tenere la scatola nera. Documenta la tua decisione e il processo di integrazione e lascia che chi arriva dopo si preoccupi di ciò. Se la relazione dovesse essere a lungo termine in cui abbiamo pianificato una serie di nuove funzionalità nel tempo, darei un'occhiata seria alla sostituzione della scatola nera.

Considerare il tempo, il budget e le potenziali entrate future prima di prendere la decisione finale. Non c'è alcun motivo tecnico per mantenere la scatola nera. L'unica motivazione potrebbe essere contrattuale o semplicemente perché il costo di opportunità è troppo elevato (ad esempio, non sarà possibile fornire altre funzionalità per sostituirlo).

Spero che questo aiuti.

    
risposta data 07.01.2011 - 21:43
fonte
5

Tratterei questo come un rischio per il progetto, almeno per quanto riguarda la manutenibilità a lungo termine.

Pertanto, considererei il minimo indispensabile per documentare e consigliare la tua gestione (in questo caso, la società che ti ha assunto come consulente) che questa situazione esiste.

Quello che non vuoi (dal punto di vista del CYA), è per il membro del team che è lo staff di quell'azienda per - alcuni mesi / anni da oggi - dire che qualcosa è impossibile a causa di questa cosa crufty che è stata creata da qualche società di consulenza (anche se l'hai ereditata anche).

Come parte della strategia di mitigazione del rischio, è possibile delineare alternative, incluse alternative open source o commerciali. È anche possibile che la società abbia effettivamente il codice sorgente e i manutentori appropriati per il componente, solo che non sono stati assegnati a questo particolare progetto, quindi non esagerare nel caso, solo i fatti come li vedi.

Good Luck

    
risposta data 07.01.2011 - 20:21
fonte
0

the [component] is a binary blob .... We embed it, feed it some XML, and it does its job, but we have no power over its internals. It's completely opaque to us - a black box. We can use it to do what it does, but we can't change it, so if we ever need to do something different, we're stuffed.

Stai parlando del sistema operativo? Il database? Il server web? Il server LDAP? Il motore Javascript nel browser?

Quando inserisco [component] ho visto che il tuo commento è vero per un gran numero di elementi del tuo stack tecnologico.

Perché preoccuparsi di uno solo? Perché non ti preoccupare di tutti loro?

Oppure, al contrario, perché preoccuparsi di qualcuno di loro?

    
risposta data 07.01.2011 - 21:47
fonte