Devo ascoltare il mio datore di lavoro e utilizzare gli strumenti CASE?

Il mio datore di lavoro (non uno sviluppatore) ritiene che gli strumenti CASE ci aiuteranno a migliorare il nostro processo di sviluppo e la nostra documentazione. Non ne sono sicuro, siamo un piccolo team di 5 sviluppatori che sviluppa soluzioni di mobile banking per clienti locali. Penso che gli strumenti CASE saranno una perdita di tempo e denaro in quanto devono essere acquistati e avremo bisogno di un po 'di tempo prima di abituarci a loro ed essere efficienti lavorando con loro per la modellazione e roba. La generazione del codice è un altro problema, penso davvero che il codice generato da CASE non sarà buono come il codice scritto da buoni sviluppatori.

Penso che se ci atteniamo ai principi agili, ai modelli di progettazione, utilizziamo TDD e manteniamo pulito il nostro codice. dovremmo essere buoni. E per quanto riguarda Analisi e Design, penso che i semplici diagrammi UML sulla lavagna dovrebbero fare il trucco. La documentazione è buona e importante, ma dovrebbe essere fatta il meno possibile e non dovremmo concentrarci su Documenti e dimenticare il codice. Questo è quello che penso.

Ho ragione? o dovrei ascoltare il mio datore di lavoro e iniziare a cercare uno strumento CASE appropriato?

La situazione merita un approccio analitico alla decisione. La linea di fondo sarà "Lo strumento CASE fornisce un valore per l'azienda?" Spesso, il management vorrà che gli sviluppatori adottino una metodologia o uno strumento perché ne hanno sentito parlare bene, indipendentemente da quanto bene si adatti ai processi e alla cultura attuali dell'organizzazione.

Se il tuo datore di lavoro ti ha chiesto di esaminare gli strumenti CASE, come sottolinea ChrisF, dovresti obbligarlo (questo è un problema sul posto di lavoro, non di programmazione). Alcuni fattori che potrebbero influenzare l'adozione di uno strumento CASE includono:

• Per quali processi sono disponibili gli strumenti CASE,
• Una stima di quante ore-persona sarebbero necessarie per adottare i nuovi strumenti,
• Come cambieranno i processi con l'adozione dei nuovi strumenti,
• o Che tipo di impatto positivo (o negativo) sarebbe misurabile dall'adozione dei nuovi strumenti

Pensa a questa come un'opportunità per aggiornare l'ambiente e i processi di sviluppo. È possibile che i tuoi processi attuali siano una corrispondenza perfetta per la cultura della tua organizzazione, ma devi al tuo datore di lavoro e al tuo team di fare le ricerche appropriate.

Sì, dovresti iniziare a cercare strumenti CASE.

1. Perché hai bisogno di prove a sostegno della tua affermazione che non aiuteranno. Non si sa mai, potresti scoprire che ti aiuteranno.
2. Perché te l'ha detto il tuo datore di lavoro.

Non ripeterò i punti indicati da David Kaczynski nella sua eccellente risposta in quanto sono esattamente i passi che dovresti seguire.

Sembra davvero un grande cambiamento di paradigma da Agile a sviluppo orientato CASE / MDA con generazione di codice. Non necessariamente dal punto di vista della gestione del progetto (un approccio CASE non entrerà in conflitto con i concetti di iterazioni, user story, feedback rapido o miglioramento continuo), ma sicuramente dal punto di vista dell '"artigianato del software" - significa meno controllo sul codice prodotto, generato codice che sarà probabilmente illeggibile, rigido, più difficile da testare, costantemente bisognoso di sincronizzazione con il modello e così via.

Da ciò che descrivi, ciò di cui il tuo datore di lavoro ha bisogno è facilmente comprensibile:

• Migliore documentazione per evitare la perdita di conoscenza se uno sviluppatore dovesse lasciare il team.
• Un processo di sviluppo più veloce.

Come professionista del software, puoi sicuramente (e dovresti) parlargli dei tuoi dubbi sulla capacità dell'approccio CASE di soddisfare queste aspettative. È anche tuo dovere iniziare a guardare gli strumenti CASE se lo richiede. Provarne uno non significa 1 / che i risultati saranno soddisfacenti (sto pensando in particolare al sovraccarico di generazione di codice potenzialmente grande che tipo di conflitti con la necessità di sviluppare più velocemente) e 2 / che non puoi trovare un compromesso in cui verranno utilizzate alcune funzionalità dello strumento CASE (diagrammi, generazione di documentazione) preservando il contesto agile esistente.

Ecco un articolo interessante sugli strumenti CASE in un ambiente Agile e sui loro possibili vantaggi / svantaggi: http://www.agilemodeling.com/essays/simpleTools.htm

Il mio datore di lavoro (non uno sviluppatore) ritiene che gli strumenti CASE ci aiuteranno a migliorare il nostro processo di sviluppo e la nostra documentazione ".

Se avessi agito come consulente per il tuo datore di lavoro, sarei obbligato a tentare di dissuaderli da questo genere di cose. Prima di tutto, è un grave errore di gestione far sì che le persone che non sono coinvolte nel lavoro scelgano strumenti per gli sviluppatori. Questo non va quasi mai bene. È almeno due volte meno grave quando le persone che fanno la scelta non hanno un forte background tecnico. E se non hanno alcuna esperienza con gli strumenti che stanno spingendo, questa sarà probabilmente una debacle totale.

Il motivo più probabile per cui questo tipo di cose viene suggerito da una gestione non tecnica è perché qualcuno sta cercando di vendergli qualcosa. Una grande azienda che vende questo tipo di cose ha entrate che cadono come uno zeppelin di piombo nell'aria rarefatta. I venditori (ovvero rivenditori, consulenti) che non sono passati a qualcos'altro stanno cercando rabbiosamente di trovare nuovi marchi, ehm ... clienti. Uno dei motivi principali per cui queste aziende stanno lottando è che non c'è più molta domanda per questo tipo di strumenti. Per "questo tipo di strumenti" intendo strumenti che promettono di "eliminare la scrittura del codice". Non c'è niente di sbagliato nel codice, a seconda della lingua. Il codice scritto ha astrazioni molto più potenti di quelle offerte da questi strumenti.

Uno dei motivi principali per cui questo è un modo così scarso di gestire lo sviluppo è che ridurrà drasticamente il pool di persone disponibili per attirare il personale del team. Per uno, hanno bisogno di imparare questi strumenti non comuni e, in secondo luogo, gli sviluppatori più esperti non vogliono lavorare con queste cose. Spesso il tono intorno a questo tipo di strumenti è che non hai davvero bisogno di buoni sviluppatori perché questi strumenti fanno la maggior parte del lavoro pesante. Questo è completamente falso. È il contrario. Fanno tutte le cose che sono banali e spesso rendono più difficile fare le parti non banali. Inoltre, non eliminano mai realmente la necessità di scrivere codice.

In particolare con gli strumenti CASE, ho lavorato in tre diversi luoghi che possedevano questi pacchetti. In ognuno, è andato così:

1. Il modello è stato accuratamente progettato nello strumento. Ci è voluto molto più tempo del normale e nessun prodotto utilizzabile è stato prodotto fino a tardi nello sforzo.
2. Il modello doveva essere ampliato con la logica aziendale. Il modello era sbagliato e doveva essere modificato manualmente durante le fasi finali del progetto perché lo sforzo era tardivo.
3. La risincronizzazione del modello e del codice era così proibitiva in termini di costi che lo strumento CASE è stato accantonato, per non essere più utilizzato.

In breve, si è trattato di un fallimento totale del 100% e di uno spreco di denaro in ogni caso. Quando ho parlato con altre persone che hanno utilizzato gli strumenti CASE in altre organizzazioni, la storia è sempre la stessa. Non ho usato tutti questi strumenti ed è possibile che alcune persone ne abbiano fatto buon uso ma sono abbastanza certo che la maggior parte dei team che li hanno usati hanno smesso di usarli molto tempo fa.

Uno dei vantaggi che otterresti dall'investigare / implementare gli strumenti CASE è che avrai acquisito una serie di competenze più commerciabili per un impiego futuro. Penso che molte delle tue preoccupazioni siano degne di nota, ma, come sottolineato da David Kaczynski, questa non è una domanda di programmazione, ma una questione di rapporto datore di lavoro / dipendente. Un altro vantaggio degli strumenti CASE è che, una volta appresa, la tua azienda sarà in grado di affrontare una gamma più ampia di progetti di maggiore complessità. Potrebbe benissimo essere che un contratto che il tuo datore di lavoro sta cercando di ottenere richieda o preferisca l'uso degli strumenti CASE.

Stai mescolando il problema e la soluzione e il tuo capo sta cercando di aiutarti, con più o meno successo. Per sfidare il tuo capo devi avere chiaro qual è il tuo ruolo nell'organizzazione. Se è l'amministratore delegato e tu sei il CTO, la decisione è tua e l'amministratore delegato dovrebbe semplicemente indicare quali aspetti aziendali sono influenzati dalla mancanza di documentazione. Il tuo obbligo sarà quindi quello di risolvere il problema aziendale, con uno strumento CASE o qualsiasi altra soluzione con cui esci.

Per quanto riguarda il suggerimento specifico di utilizzare gli strumenti CASE, penso che tu debba sceglierlo correttamente in modo da raggiungere il tuo obiettivo senza sovraccaricare la tua squadra di lavoro extra. Se la documentazione è ciò che vuoi migliorare, potresti averne abbastanza con uno strumento in grado di generare diagrammi dal codice, non necessariamente per generare il codice dal diagramma grafico. Un esempio di tale strumento è Codelogic . Ho usato alcuni anni fa per assicurarmi che i nostri progetti fossero chiari e chiari da capire ed era abbastanza facile da usare. Se mentre esprimi il denaro è un'altra preoccupazione, puoi probabilmente guardare all'open source (non posso fare a meno di qui, ma sarei interessato al risultato di qualsiasi ricerca).

L'alternativa agli strumenti CASE può anche aiutare. Misurare cose come le misure ciclomatiche o altre complessità manterrà il tuo progetto ben strutturato e gli sviluppatori focalizzati sul codice. Anche commenti migliori sul tuo codice, simili a Javacode, possono aiutare a migliorare la documentazione.

Onestamente, penso che se consideri che gli strumenti CASE non aiutano il tuo capo, devi saperlo. Se è un buon capo, apprezzerà la tua opinione. Non mi è mai piaciuto un dipendente che fa solo ciò che gli viene detto senza analisi critica. Ma naturalmente, come suggerisce David, qualsiasi discussione dovrebbe essere sostenuta da argomenti forti e oggettivi.

Proverei a far capire al tuo datore di lavoro che ha ottenuto le cose al contrario. Se c'è spazio per investimenti per il team del software, è necessario identificare quali sono i colli di bottiglia o i problemi di qualità. Se si scopre che hai più margini di miglioramento nelle aree della documentazione e del processo di sviluppo, dovresti identificare quali cambiamenti hanno il ROI maggiore in termini di miglioramento di queste aree. Ciò potrebbe o non potrebbe iniziare a utilizzare gli strumenti CASE.

Aiuta il tuo capo, aiuta te stesso

Puoi reagire o agire su questa richiesta.

Ricordi tutte le domande "Sposta il monte Fuji"? Se fossi in un'intervista per un lavoro che volevi davvero, non diresti all'intervistatore quanto fosse stupida la domanda, ma continueresti a fare domande ed esprimere le tue idee migliori per risolverlo. In alcune culture, non diresti mai di no a un boss che ti ha effettivamente chiesto di spostare il Monte Fuji, ma troveresti un modo per salvare entrambi la faccia.

Rinominare la domanda

Se dovessi riformulare la domanda in qualcosa del genere,

"Posso acquistare o altrimenti acquistare una suite di strumenti che automatizzano il maggior numero possibile di attività a bassa produttività legate al software?"

questo incarico diventa molto più appetibile. Aiuta il tuo capo (e te stesso) dandogli un'opzione con chiara tracciabilità a CASE e una o due opzioni Agile / open source / basate su cloud.

CASO rivisitato

Negli anni '90, gli strumenti CASE potrebbero assumere la forma di una suite di strumenti di Rational che probabilmente includeva Requisite Pro, Rational Rose, Clear Case, Rational Robot (un test runner), Purify, Pure Coverage e Quantify e molti altri strumenti che sono stati integrati insieme. Se fossi un negozio MAD (medico, avionico, difesa) potresti utilizzare versioni aggiornate di questi strumenti per produrre documentazione e manufatti estesi e tracciabili che sono spesso richiesti dai clienti in quei mercati.

Contatta IBM e chiedi a un venditore di fornire un preventivo per cinque licenze (o solo una licenza mobile). Aggiungi anche un po 'di allenamento. La condivisione di questo preventivo con il proprio responsabile potrebbe interrompere la discussione sugli strumenti CASE. Ma non fraintendermi. Mi piacciono Rational, i loro principali scienziati e i loro prodotti, ma ho avuto accesso principalmente a loro attraverso le licenze dei siti universitari perché il loro prezzo era troppo alto per le aziende in cui ho lavorato. Se sei approvato, almeno dalla mia esperienza, tratteranno i tuoi diritti con un buon supporto, una formazione di qualità (di solito in un resort di alto livello con ottimo cibo).

Strumenti in vendita

Hai ancora una grande opportunità di fare shopping di strumenti. Anche gli sviluppatori agili hanno bisogno di strumenti. È possibile acquistare una suite che offra supporto alla documentazione per story card online, casi d'uso, casi d'uso e altri tipi di diagrammi UML. Atlassian ha quella che penso sia una bella suite di strumenti: Jira per il monitoraggio di attività e bug, Green Hopper per quello che descrivono come gestione dei progetti Agile, Confluence per un wiki intranet, Crucible per la revisione del codice online e Bamboo per un server di integrazione continua. Esistono software come licenze di servizio per queste e altre suite di strumenti mirate alle tue esigenze se sei Agile.

L'integrazione IDE è un'altra strada per ottenere un equivalente CASE del 2012. Se sei una casa di sviluppo Microsoft, Visual Team Studio ha strumenti di portata simile a ciò che Rational ha creato. Hanno un po 'di ingegneria del software di andata e ritorno, generazione di stub di test unitari da classi, integrazione con i sistemi di controllo del codice sorgente e un sacco di strumenti per la collaborazione in team.

Strumenti open source

Sul lato open source, Eclipse e i suoi numerosi plug-in cercano di integrare una serie di strumenti open source. Non sono sicuro se Eclipse Modeling Framework sia maturo o se ci sono altri strumenti che offrono un efficace ingegnere informatico di andata e ritorno, ma l'ultima volta che ho guardato, non sembrava molto facile da ottenere. L'ambiente Qt Creator si integra con il controllo del codice sorgente e ha alcune funzionalità per aiutare con il controllo a campione dalla copertura del codice delle modifiche mentre ci si trova nell'editor.

Adozione di strumento incrementale iterativo

Anche un approccio iterativo / incrementale alla selezione degli strumenti può essere molto efficace. I progetti open source spesso supportano ambienti singoli o multipli. Le scelte degli strumenti potrebbero essere influenzate dalle pile utilizzate. Non c'è mai un buon momento per interrompere completamente lo sviluppo, quindi aggiungere e addestrare il team con alcuni strumenti più piccoli per trimestre può essere migliore di un approccio big bang che cambia tutto in una volta.

Cloud Tool Solutions

Molte delle soluzioni elencate potrebbero richiedere server e un'installazione relativamente complessa. Esistono molte opzioni sul mercato basate sul cloud e che forniscono software come servizio ospitato da un fornitore a un canone mensile. Questo può avere senso per la tua squadra, sia a breve che a lungo termine. Alcuni potrebbero avere una soluzione ospitata che puoi utilizzare per un avvio rapido, con la possibilità di acquistare licenze in seguito.

Nessuno di questi suggerimenti è una strada economica e facile per il miglioramento istantaneo della produttività, ma se riesci a trovare alcuni degli strumenti indispensabili una volta provati.

Una cosa che aggiungerei alle eccellenti risposte qui è che potresti trarre beneficio dalla comprensione di come "migliorare il tuo processo di sviluppo".

La tendenza travolgente degli ultimi 20 anni è stata quella di ottimizzare lo sviluppo del software per il time to market. "Agile", "lean", DevOps, TDD, BDD: si tratta di ottenere software di qualità fuori dalla porta il più rapidamente possibile.

Gli strumenti CASE non riguardano il time to market. Si concentrano su tracciabilità, coerenza progettuale, completezza del modello, ecc. Questi sono tutti aspetti preziosi - specialmente nei sistemi bancari - ma sono a scapito del time to market.

Quindi, forse chiedi al tuo capo esattamente cosa sta cercando di ottimizzare.

Per esperienza, lavorare con gli strumenti CASE diventa rapidamente più difficile che lavorare con il codice, specialmente quando si lavora con domini problematici che sono mediamente più complessi. Il progetto smette di essere un progetto "bancario" e diventa invece un progetto "inserisci-nome-di-CASE-strumento-qui".