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

La situazione garantisce un approccio analitico alla decisione. La linea di fondo sarà "Lo strumento CASE fornisce un valore al business?" Spesso, il management vorrebbe che gli sviluppatori adottassero una metodologia o uno strumento perché ne hanno sentito parlare bene, indipendentemente da come si adatti bene agli attuali processi e alla cultura dell'organizzazione.

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

• Per quali dei tuoi processi ci sono strumenti CASE disponibili,
• Una stima di quante ore-persona sarebbero necessarie per adottare i nuovi strumenti,
• Come cambierebbe il / i processo / i con l'adozione dei nuovi strumenti,
• o Che tipo di impatto positivo (o negativo) sarebbe misurabile dall'adozione del nuovo strumento (s)

Consideralo un'opportunità per aggiornare il tuo ambiente di sviluppo e i tuoi processi. Potrebbe essere che i tuoi attuali processi siano perfettamente compatibili con la cultura della tua organizzazione, ma devi al tuo datore di lavoro e al tuo team fare la ricerca appropriata.

Sì, dovresti iniziare a cercare gli strumenti CASE.

1. Perché hai bisogno delle prove per sostenere la tua affermazione che non saranno di aiuto. Non si sa mai, potresti trovare che ti aiuteranno.
2. Perché il tuo datore di lavoro te l'ha detto.

Non ripeterò i punti presentati da David Kaczynski nella sua risposta eccellente in quanto sono esattamente il passi da seguire.

Sembra un grande cambiamento di paradigma, in effetti, da Agile a sviluppo orientato a 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 da una prospettiva di "artigianalità del software" - significa meno controllo sul codice prodotto, codice generato che sarà probabilmente illeggibile, rigido, 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:

• Una migliore documentazione per evitare perdite di conoscenza se uno sviluppatore dovesse lasciare il team.
• Un processo di sviluppo più rapido.

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

Ecco un interessante articolo sugli strumenti CASE in un ambiente Agile e i loro possibili vantaggi / svantaggi: link

My employer (Not a Developer) thinks that CASE tools will help us improve our development process and documentation."

Se avessi intenzione di agire come consulente per il tuo datore di lavoro, sarei obbligato a cercare di dissuaderli da questo genere di cose. Prima di tutto, è un grave errore di gestione avere persone che non sono coinvolte nel lavoro scelgono strumenti per gli sviluppatori. Questo quasi mai va bene. È almeno il doppio quando le persone che fanno la scelta non hanno un strong background tecnico. E se non hanno alcuna esperienza con gli strumenti che stanno spingendo, è probabile che questa sia una debacle totale.

La ragione più probabile per cui questo tipo di cose viene suggerito da una gestione non tecnica è perché qualcuno sta cercando di vendergli qualcosa. Una delle principali società che vende questo tipo di cose ha ricavi che stanno cadendo come uno zeppelin di piombo in aria rarefatta. I venditori (a.k.a rivenditori, consulenti) che non sono passati a qualcos'altro stanno cercando rabbiosamente di trovare nuovi marchi, e ... clienti. Uno dei motivi principali per cui queste aziende stanno lottando è che non c'è più molta richiesta di questo tipo di strumenti. Con "questi tipi di strumenti" intendo strumenti che promettono di "eliminare il codice di scrittura". 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ì pessimo di gestire lo sviluppo è che ridurrà drasticamente il pool di persone che è possibile portare dallo staff al proprio staff. 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 campo attorno a questi tipi di strumenti è che non hai davvero bisogno di buoni sviluppatori perché questi strumenti fanno la maggior parte del lavoro pesante. Questo è completamente falso. È l'opposto. Fanno tutte le cose che sono banali e spesso rendono più difficili le parti non banali. Inoltre, non eliminano mai la necessità di scrivere codice.

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

1. Il modello è stato accuratamente progettato nello strumento. Ci è voluto molto più del normale e non sono stati prodotti risultati utili fino a molto tardi.
2. Il modello doveva essere integrato 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 il codice erano così cost-proibitivi che lo strumento CASE è stato accantonato, mai più utilizzato.

In poche parole, è stato un fallimento totale del 100% e uno spreco di denaro in ogni caso. Quando ho parlato con altre persone che hanno utilizzato 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 un insieme di competenze più redditizio per il futuro impiego. Penso che molte delle vostre preoccupazioni siano degne di nota, ma, come sottolineato da David Kaczynski, questa non è una domanda di programmazione tanto quanto una questione di rapporto datore di lavoro / dipendente. Un altro vantaggio degli strumenti CASE è che una volta appreso, la vostra azienda sarà in grado di affrontare una gamma più ampia di progetti di maggiore complessità. Potrebbe anche essere che un contratto che il tuo datore di lavoro sta cercando di ottenere richiede una preferenza per l'utilizzo degli strumenti CASE.

Stai mescolando il problema e la soluzione e il tuo capo sta cercando di aiutare, 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 interessati 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.

Riguardo al suggerimento specifico di utilizzare gli strumenti CASE, penso che devi sceglierlo correttamente in modo da raggiungere il tuo obiettivo senza sovraccaricare il tuo team con un lavoro extra. Se la documentazione è ciò che vuoi migliorare, potresti avere abbastanza con uno strumento in grado di generare diagrammi dal codice, non necessariamente 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 e fossero abbastanza facili da usare. Se mentre esprimi denaro è un'altra preoccupazione, probabilmente puoi guardare nell'open source (non posso aiutarti qui ma sarei interessato ai risultati di qualsiasi ricerca).

L'alternativa agli strumenti CASE può anche aiutare. Misurare cose come misure ciclomatiche o di altra complessità manterrà il tuo design ben strutturato e gli sviluppatori si concentreranno sul codice. I commenti migliori sul tuo codice, come Javacode, possono anche aiutare a migliorare la documentazione.

Onestamente, penso che se consideri che gli strumenti CASE non aiutano il tuo capo deve 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, ogni discussione dovrebbe essere tenuta su argomenti forti e obiettivi.

Cercherò di far capire al tuo datore di lavoro che ha fatto delle cose indietro. Se c'è spazio per l'investimento per il team del software, è necessario identificare quali sono i colli di bottiglia oi problemi di qualità. SE si scopre che ci sono margini di miglioramento nella documentazione e nelle aree del processo di sviluppo, dovresti identificare quali cambiamenti hanno il ROI più grande per quanto riguarda il miglioramento di queste aree. Potrebbe non essere possibile iniziare a utilizzare gli strumenti CASE.

Aiuta il tuo capo, aiutaci

Puoi rispondere o agire su questa richiesta.

Ricorda tutte le domande "Sposta il Monte Fuji"? Se tu fossi in un'intervista per un lavoro che volevi davvero, non diresti all'intervistatore quanto fosse stupida la domanda, ma continuerai a fare domande e ad esprimere le tue migliori idee per risolverlo. In alcune culture, non diresti mai di no a un capo che in realtà ti ha chiesto di spostare il Monte Fuji, ma troveresti un modo per farti salvare la faccia.

Riformulazione della domanda

Se dovessi riformulare la domanda in qualcosa di simile,

"Can I buy or otherwise acquire a suite of tools that automate as many of the low productivity tasks related to software as possible?"

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

CASE Revisited

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

Contattare IBM e ottenere un venditore per fornire un preventivo per cinque licenze (o una sola licenza mobile). Aggiungi anche un po 'di allenamento. La condivisione di questa citazione con il tuo manager può interrompere la discussione sugli strumenti CASE. Ma non fraintendermi. Mi piacciono i Rational, i loro principali scienziati ei loro prodotti, ma li ho principalmente consultati tramite le licenze dei siti universitari perché il loro prezzo era troppo alto per le aziende in cui ho lavorato. Se sei stato approvato, almeno dalla mia esperienza, tratteranno il tuo diritto con un buon supporto, un allenamento di qualità (di solito in un resort di vertice con ottimo cibo).

Strumenti per la vendita

Hai ancora una grande opportunità per fare shopping con gli attrezzi. Anche gli sviluppatori agili hanno bisogno di strumenti. Potresti acquistare una suite che ti offre supporto per la documentazione di schede di storie 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 task e il bug tracking, Green Hopper per quello che descrivono come la gestione del progetto Agile, Confluence per una wiki intranet, Crucible per la revisione del codice online e Bamboo per un server di integrazione continua. Ci sono 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 quelli creati da Rational. Hanno una serie di software di round-trip, generazione di unità di test unitarie da classi, integrazione con sistemi di controllo sorgente e una serie di strumenti per la collaborazione di gruppo.

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 che Eclipse Modeling Framework sia maturo o se ci sono altri strumenti che forniscono un valido software engineer round-trip, ma l'ultima volta che ho guardato, non sembra molto facile da ottenere. L'ambiente Qt Creator si integra con il controllo del codice sorgente e offre alcune funzionalità che consentono di verificare con punti la copertura del codice delle modifiche mentre si è nell'editor.

Adozione strumento incrementale iterativa

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

Soluzioni per gli strumenti cloud

Molte delle soluzioni elencate potrebbero richiedere server e impostazioni relativamente complesse. Ci sono molte opzioni in arrivo sul mercato che sono basate sul cloud e forniscono software come servizio ospitato da un fornitore per una tariffa mensile. Questo può avere senso per la tua squadra, sia a breve che a lungo termine. Alcuni possono avere una soluzione ospitata che è possibile utilizzare per un avvio rapido, con l'opzione di acquistare le licenze in seguito.

Nessuno di questi suggerimenti è un modo economico e facile per migliorare la produttività istantanea, ma se si riesce a trovare alcuni degli strumenti indispensabili dopo averli provati.

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

La travolgente tendenza negli 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 il software di qualità fuori dalla porta il più rapidamente possibile.

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

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

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