Alta Velocità controllata

White paper
Alta Velocità controllata
Sviluppo ad alta velocità del software
nelle aziende con normative complesse
Greg Hughes, CEO di Serena Software
1
White paper: Alta velocità controllataPiù velocità senza inutili rischi
Sommario
L’esigenza di maggiore velocità .................................................................................................................... 3
Perché più velocità può significare più danni: conflitti tra procedure da una parte e policy e sistemi
dall’altra ......................................................................................................................................................... 4
Rischi per la sicurezza .................................................................................................................................. 5
Rischi per la conformità................................................................................................................................. 7
Rischi per la prestazioni ................................................................................................................................ 8
Più velocità senza inutili rischi: best practice per le aziende ........................................................................ 8
Perché Serena? .......................................................................................................................................... 10
Conclusioni e riepilogo ................................................................................................................................ 17
Riferimenti ................................................................................................................................................... 20
Informazioni sull’autore
Greg Hughes è CEO di Serena Software e fa parte del consiglio di
amministrazione. Da 35 anni Serena è impegnata nell’aiutare le
grandi aziende caratterizzate da normative complesse a migliorare il
ciclo di vita dello sviluppo del software, accelerando la distribuzione
del software stesso con meno rischi.
Greg ha iniziato come ingegnere e sviluppatore di software,
scrivendo applicazioni in più linguaggi e persino esercitando l’arte
perduta della programmazione Assembly.
Prima di entrare in Serena, ha lavorato per Silver Lake Partners, Symantec, VERITAS
Software e McKinsey & Company. Si è laureato presso il Dipartimento di Ingegneria
elettrica e di Scienze informatiche del Massachusetts Institute of Technology e presso
la Graduate School of Business di Stanford.
4
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi
Oggi le aziende subiscono pressioni incredibili affinché venga accelerata l’innovazione
del software a causa della concorrenza e venga colta l’opportunità di sfruttare tecnologie
rivoluzionarie come quella del “mobile”. Tali pressioni stanno spingendo le aziende che si
occupano dello sviluppo di applicazioni ad adottare una serie di procedure moderne, elaborate
presso società Web di dimensioni più ridotte, per il ciclo di vita dello sviluppo del software
(SDLC, software development lifecycle).
Nel tentativo di accelerare la distribuzione del software, le piccole imprese possono
permettersi di aderire al motto sfoggiato da Facebook agli albori: “Move Fast and Break
Things” (Muoviti, cambia le cose e non avere paura di romperle). Tuttavia, se vogliono
aumentare la propria velocità e implementare procedure di sviluppo moderne, le aziende più
grandi devono evitare i crescenti rischi in termini di sicurezza, conformità e prestazioni che
caratterizzano il ciclo di vita dello sviluppo del software. La gestione del rischio associato
all’SDLC è particolarmente vitale in settori sensibili ad alta regolamentazione quali servizi
finanziari, pubblica amministrazione, sanità, industria automobilistica e difesa.
In molte imprese caratterizzate da normative complesse, alla base di processi aziendali
differenziati, di prodotti esclusivi e di servizi ad alto valore si trova software proprietario.
I rischi propri del ciclo di vita dello sviluppo del software possono pregiudicare preziose
risorse aziendali, tra cui:
 Proprietà intellettuale
 Reputazione dei clienti
 Posizione giuridica e normativa
 Capitale finanziario
Come devono agire i vertici aziendali in settori a forte regolamentazione per fare in modo che i
team per lo sviluppo delle applicazioni adottino procedure di sviluppo moderne, gestendo nel
contempo i rischi in termini di sicurezza, conformità e prestazioni? In altre parole, in che modo
le aziende possono “muoversi velocemente senza inutili rischi”?
L’esigenza di maggiore velocità
Viviamo in un’era di trasformazioni straordinarie e incessanti basate sull’innovazione del
software.
Lo sviluppo del software non è mai stato così strategico e cruciale, comportando enormi
pressioni affinché vengano compressi i tempi dei cicli di sviluppo. Di conseguenza, i team
che si occupano dello sviluppo di applicazioni in tutti i settori stanno adottando procedure
moderne, tra cui:
3

Sviluppo agile: pone l’accento sulla necessità di distribuire software funzionante
con una frequenza elevata al fine di soddisfare i clienti e accoglie requisiti in
trasformazione anche nelle fasi più avanzate dello sviluppo (Kent Beck 2001).

Sviluppo parallelo: consente a più sviluppatori di lavorare alle funzioni in parallelo,
facendo confluire le modifiche in un’unica “linea principale” (Appleton 2003).
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi

Continuous integration promuove frequenti build automatizzate e test di integrazione
di linee di sviluppo parallele per individuare eventuali difetti fin dalle prime fasi e
ridurre così le operazioni di rielaborazione (Fowler 2006).

Continuous Delivery si basa sull’utilizzo dell’automazione, di rigide procedure per il
controllo delle versioni e della collaborazione per accelerare le modifiche del software
lungo il ciclo di sviluppo che porta alla produzione (Farley 2011).

Lean: adatta i principi del sistema di produzione Toyota, tra cui Kanban board, allo
sviluppo del software, eliminando gli sprechi (cioè le attività che non contribuiscono al
valore per i clienti) e le batch di piccole dimensioni (Jez Humble 2014) (Vodde 2009).

DevOps: mira a migliorare la collaborazione e gli obiettivi condivisi tra sviluppo e
operations al fine di risolvere i conflitti tra questi due team (Gene Kim 2015).
Uno sviluppo innovativo del software è decisivo per sbloccare il potenziale di tecnologie
che possono risultare rivoluzionarie. Secondo uno studio condotto da McKinsey & Co., le
tecnologie innovative sono “potenzialmente in grado di avere un impatto economico compreso
tra 14 e 33 trilioni di dollari all’anno nel 2025” (James Manyika 2013). Di seguito vengono
indicate alcune di queste tecnologie:

Dispositivi mobili: l’iPhone 4 (costo: 400 dollari) ha prestazioni analoghe al
supercomputer più veloce esistente nel 1975, che costava 5 milioni di dollari.

Intelligenza artificiale: dai tempi di Deep Blue di IBM (campione di scacchi nel 1997) a
Watson (vincitore di Jeopardy nel 2011), si è registrato un incremento di 100 volte
delle prestazioni in termini di potenza di elaborazione.

Internet of Things: negli ultimi cinque anni, il numero di dispositivi M2M (machine-tomachine) connessi è aumentato del 300%.

Tecnologia cloud: il rapporto prezzo/prestazioni di un server nel cloud pubblico
raddoppia ogni 18 mesi.
È necessario adottare procedure di sviluppo moderne. È diventata una questione di
sopravvivenza.
Perché più velocità può significare più danni: conflitti tra procedure da una
parte e policy e sistemi dall’altra
Gli sviluppatori di software devono essere liberi di adottare procedure moderne per rendere
più efficiente la propria attività.
Tuttavia, sebbene tali procedure comportino vantaggi, spesso i sistemi e le policy che si
basano su di esse sono deboli e introducono nel ciclo di vita dello sviluppo del software
vulnerabilità che possono risultare particolarmente problematiche per le grandi aziende in
settori con normative complesse.
Di seguito vengono riportate alcune di queste vulnerabilità:
4

Consentire il proliferare di numerosi repository di codice open source (ad es. GIT
ed SVN).

Consentire agli sviluppatori di configurare e gestire i propri repository di codice
sorgente senza tutele adeguate e senza un quadro strategico generale.
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi

Controlli degli accessi, protezione delle password e meccanismi di autenticazione di
qualità scadente per un team di sviluppo distribuito a livello globale.

Controlli e misure di applicazione dei processi scarsamente efficaci, ad esempio:

Gestione delle modifiche

Test e QA automatizzati

Ciclo di vita sicuro dello sviluppo/analisi statica della sicurezza

Controllo sull’uso del modulo per il codice open source

Gestione dell’onboarding per dipendenti e consulenti

Processi altamente manuali

Mancanza di registri degli eventi dettagliati e carenza di tracciabilità, con un
conseguente livello insufficiente di supporto per gliaudit

Inadeguate separazioni dei compiti e procedure di approvazioni dei carichi di lavoro
Mentre le piccole imprese possono adottare il motto di Facebook “Move Fast and Break
Things”, quelle più grandi, in particolare in settori ad alta regolamentazione, devono muoversi
velocemente senza inutili rischi.
Man mano che gli sviluppatori di software implementano nuove procedure per accelerare la
commercializzazione, dirigenti e azionisti devono avere la certezza che i rischi relativi
all’SDLC vengano gestiti in maniera efficace.
Per trovare un equilibrio tra questi principi in conflitto, è opportuno che i dirigenti applichino
all’SDLC la filosofia dell’ERM (Enterprise Risk Management, gestione del rischio aziendale).
A tale scopo, è necessario che i team che si occupano di sviluppo delle applicazioni, gestione
delle modifiche, sicurezza/rischi IT e verifiche operino in stretta collaborazione con esperti
del settore.
Il primo passo di questo approccio consiste nell’identificazione dei rischi in termini di
sicurezza, conformità e prestazioni che caratterizzano lo sviluppo del software.
Rischi per la sicurezza
Il 12 gennaio 2010 Google ha dichiarato in un post pubblico sul proprio blog di essere
stata vittima di un attacco informatico estremamente sofisticato nei confronti della sua
proprietà intellettuale più preziosa: il suo codice sorgente (Drummond 2010). L’attacco,
successivamente denominato “Operazione Aurora”, proveniva dalla Cina e aveva come
obiettivo la sottrazione (o forse la modifica) del codice sorgente di decine di società
statunitensi di numerosi settori sensibili, tra cui software, difesa e servizi finanziari.
L’attacco è stato uno dei primi esempi di “minaccia persistente avanzata”, un sistema di
malware che agisce furtivamente penetrando nelle reti alla ricerca di proprietà intellettuale
di valore per poi, non appena le condizioni lo consentono, appropriarsene indebitamente
prima di essere rilevato.
5
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi
Secondo Dmitri Alperovitch, vicepresidente di McAfee Labs, “[i] sistemi SCM (Source Code
Management, gestione del codice sorgente) erano assolutamente accessibili. Nessuno aveva
mai pensato di proteggerli, nonostante sotto molti aspetti rappresentassero il patrimonio più
prezioso di gran parte di queste aziende. Molto più di qualsiasi dato finanziario o che consenta
l’identificazione personale di qualcuno, risorse nella cui difesa le società investono una
quantità enorme di tempo ed energie” (Zetter 2010).
Le minacce informatiche costituiscono un problema crescente in settori caratterizzati da
normative complesse, come testimonia la dichiarazione del CEO di JP Morgan Chase,
secondo il quale la banca raddoppierà la propria spesa destinata alla sicurezza informatica
da 250 a 500 milioni di dollari all’anno dopo una recente violazione salita agli onori della
cronaca (Tracy 2014).
Queste minacce informatiche hanno due diverse origini, entrambe mosse da forti motivazioni:
una all’interno e una all’esterno all’azienda:
Origine interna: dopo la vicenda che ha visto protagonista Edward Snowden, le
aziende si stanno rendendo conto degli enormi danni che possono essere provocati
da persone autorizzate ad accedere alle informazioni, ad esempio dipendenti,
consulenti e team all’estero. La minaccia interna non è sempre riconducibile a
soggetti malintenzionati; più spesso, la causa è da ricercarsi nella “scarsa
competenza” di persone che operano in azienda. Di recente chi scrive ha avuto
notizia di un cliente del settore dei servizi finanziari a cui è capitato che uno
sviluppatore abbia inviato codice sorgente al proprio indirizzo e-mail privato.
Origine esterna: le minacce esterne sono quelle che presentano i livelli più elevati di
finanziamento, sofisticatezza e organizzazione e in genere vengono suddivise nelle
seguenti quattro categorie: 1. sponsorizzate da un governo nazionale, 2. criminalità
organizzata, 3. hacktivist e 4. terroristi.
Esiste una vasta gamma di minacce per la sicurezza dell’SDLC, tra cui:
6

Furto di proprietà intellettuale: è possibile che il codice sorgente rappresenti
la proprietà intellettuale più importante generata da un’azienda. Nell’ambito
dell’”Operazione Aurora”, Google, Adobe, Juniper Networks e Rackspace hanno
tutte confermato di aver subito attacchi ai propri sistemi. Stando alle notizie riportate
dai media, anche decine di altre società di primo piano sono entrate nel mirino dei
criminali informatici.

Modifiche non autorizzate alla sorgente (“backdoor”): gli autori degli attacchi che
riescono ad accedere al codice sorgente possono installare backdoor, dando loro
istruzioni “command & control” su funzioni chiave.

Utilizzo del codice sorgente per individuare le vulnerabilità: esaminando il codice
sorgente sottratto, gli autori degli attacchi possono ricavare informazioni sufficienti
per trovare nuove vulnerabilità nei sistemi colpiti.
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi

Danneggiamento prima dell’arrivo in produzione: nella maggior parte delle aziende,
il percorso del codice completo dal team di sviluppo a quello del reparto operation
è un processo non controllato altamente manuale, limitato alle ore notturne o ai fine
settimana. Le applicazioni multilivello richiedono modifiche coordinate che coinvolgono
un gran numero di persone, piattaforme e ambienti (ad es. mainframe, livello Web,
cloud, database, ecc.). Se tali modifiche non vengono apportate correttamente, i
sistemi possono essere esposti a vulnerabilità durante ogni operazione manuale.
Rischi per la conformità
Da quando, nel 2002, è stato approvato il Sarbanes-Oxley Act (SOX), la gestione della
conformità normativa costituisce un onere crescente nell’ambito dell’SDLC. Alla luce della
natura sempre più variegata delle norme a diversi livelli (statale, federale e internazionale),
è difficile stare al passo con le modifiche all’SDLC necessarie, in particolare per settori
altamente regolamentati quali:

Servizi finanziari: Gramm-Leach-Bliley Privacy Act (GLBA), Dodd-Frank, Basel III

Assicurazioni: Model Audit Rule

Pagamenti: Payment Card Industry Data Security Standard (PCI DSS)

Sanità: Health Insurance Portability and Accountability Act (HIPAA), Affordable
Care Act

Industria automobilistica: ISO26262

Pubblica amministrazione: Federal Information Processing Standards/Federal
Information Security Management Act (FIPS/FISMA)

Settore aerospaziale/difesa: Export Control Act
Attenersi a nuove normative presenta costi non irrilevanti. Ad esempio, si prevede che la
Regulation SCI (Systems Compliance and Integrity) della Securities and Exchange Commission
statunitense, che riguarda 44 organismi, avrà un costo complessivo iniziale pari a 242 milioni
di dollari, più altri 191 all’anno.
Il rischio di non conformità è un grave problema per i dirigenti di settori caratterizzati da
normative complesse. Il tempo, le risorse e i costi causati dalle controversie legali sono
onerosi per i team dirigenziali e le penali imposte dalle istituzioni governative possono
essere ingenti.
Il ciclo di vita dello sviluppo del software per i sistemi chiave rappresenta uno degli
ambiti principali cui si rivolgono queste normative (Epps and Norris 2012) (MSDN 2006).
La conformità richiede l’adozione di procedure di sviluppo sicure e la gestione rigorosa di
processi quali autorizzazione, separazione dei compiti, controllo delle modifiche e supporto
delle verifiche (ad es. creazione di registri e report).
7
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi
Oltre alla conformità normativa, quella legale costituisce un ulteriore problema per
l’SDLC. Sempre più spesso gli sviluppatori di software usano codice sorgente disponibile
gratuitamente online per far fronte a scadenze urgenti. In che modo viene monitorato tutto
questo codice sorgente? Come fanno le aziende ad accertarsi che vengano rispettate le
restrizioni in materia di licenze? Infine, in che modo le imprese verificano che al software
vengano applicate le patch adeguate e che il software stesso venga aggiornato in caso di
necessità?
Rischi per la prestazioni
In questa sede, il concetto di prestazioni ha un’accezione vasta, ossia il fatto che il software
svolga il compito per il quale è pensato. Nell’ambito dell’SDLC si presentano rischi in termini
di prestazioni quando non vengono portati a termine i test opportuni o quando questi ultimi
possono essere elusi prima che il codice vada in produzione. Il processo di rilascio, ossia
la promozione del codice dallo sviluppo alla produzione, è una delle fasi più rischiose
dell’SDLC.
Uno dei casi più catastrofici di rischio in termini di prestazioni è la vicenda di Knight Capital
(Heusser 2012), una società di high-frequency trading tra i principali operatori nel campo
delle azioni statunitensi. Nel giugno 2012 la borsa di New York è stata autorizzata a lanciare
il proprio Retail Liquidity Program (RLP) e ha informato le società di trading (tra cui Knight
Capital) che tale programma sarebbe diventato operativo il 1° agosto.
Nella fretta di approntare il proprio software di trading entro quella data, Knight Capital ha
commesso un grave errore che le ha causato perdite vicine ai 440 milioni di dollari nei primi
30 minuti di contrattazioni. La società ha subito danni talmente gravi da dover essere acquisita
da una concorrente (Getco LLC).
Secondo un articolo pubblicato sul New York Times con il titolo “Trying to Be Nimble, Knight
Capital Stumbles” (“Knight Capital cade dopo aver cercato lo scatto), la concorrenza ha
sollevato dubbi sull’approccio aggressivo di Knight Capital (Silver-Greenberg 2012). “Il tempo
intercorso tra l’approvazione del software e la sua implementazione è stato incredibilmente
breve” ha dichiarato un responsabile degli scambi azionari di un’altra società.
Da un’analisi dettagliata è emerso come Knight Capital abbia implementato per errore nella
produzione un modulo software di prova che ha eseguito le proprie contrattazioni anziché
reagire a quelle di entità esterne (Nanex Research 2012). Questo modulo software di prova
non avrebbe mai dovuto essere implementato in produzione. È stato inserito accidentalmente
nel pacchetto di rilascio e attivato nel sistema in tempo reale della borsa di New York.
Alta velocità controllata: best practice per le aziende
Man mano che implementano nuove procedure per accelerare lo sviluppo delle applicazioni,
le aziende che operano in settori caratterizzati da normative complesse devono adottare
un approccio disciplinato e programmatico alla sicurezza, alla conformità e alle prestazioni
dell’SDLC. Nei paragrafi che seguono vengono illustrate cinque best practice da prendere in
considerazione in tal senso.
8
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi
1. Adottare strumenti intuitivi per gli sviluppatori: non è un caso se questa regola viene
indicata per prima. Se gli sviluppatori non si trovano bene con gli strumenti che hanno
a disposizione, cercheranno di evitarli. Senza eccezioni. La tecnologia di gestione del
rischio deve fungere da protezione invisibile per gli sviluppatori. Il team di sviluppo
delle applicazioni boicotterà i sistemi forniti dall’IT se questi ultimi non supportano le
procedure avanzate auspicate dal team stesso o se risultano eccessivamente difficili
da usare. Gli strumenti devono adottare procedure di sviluppo moderne e supportare
interfacce utente all’avanguardia.
2. Potenziare il livello di controllo dei processi lungo l’intero SDLC: in molte aziende
l’SDLC consta di numerosi prodotti distinti privi di una solida base in termini di
gestione dei flussi di lavoro tra i diversi prodotti. Soluzioni efficaci per la gestione
dei processi semplificano il coordinamento delle attività e delle informazioni tra i
vari strumenti, garantendo le funzioni di monitoraggio degli eventi e di controllo
degli accessi necessarie per la gestione del rischio. Di seguito vengono evidenziate
alcune delle principali aree relative ai processi che riguardano i diversi prodotti su cui
concentrarsi:

Imposizione dell’utilizzo di procedure sicure per il ciclo di vita dello sviluppo, ad
esempio sicurezza e analisi open source.

Solida gestione delle modifiche, ad esempio richiesta di modifica per l’integrità
del codice sorgente dalla sua creazione
al caricamento.

Gestione dei rilasci, ad esempio verificando che vengano seguite tutte le
procedure appropriate, tra cui l’approvazione da parte del Change Advisory
Board (CAB).

Onboarding e offboarding di consulenti/dipendenti
3. Implementare l’automazione ogniqualvolta è possibile: la sostituzione di procedure
manuali con l’automazione garantisce ripetibilità, limita i costi e riduce il rischio
di errori (intenzionali o meno che siano). In alcuni casi l’automazione comporta
vantaggi accessori, aumentando la velocità dei processi operativi, contenendo
i costi e assicurando al tempo stesso controllo e tracciabilità. Ad esempio, nella
maggior parte delle aziende, la distribuzione delle applicazioni è un processo a
elevato coinvolgimento di risorse che vede la partecipazione di molte persone
nelle ore notturne e nei fine settimana. I prodotti per l’automazione di questa
operazione possono eliminare centinaia di attività manuali, sostituendole con
un processo standardizzato, verificabile e automatizzato.
4. Tenere a freno la proliferazione dei repository e creare un solido sistema centralizzato
per la gestione del codice sorgente: questo è il corollario alla prima regola. Troppe
aziende si lasciano sfuggire di mano il numero di repository di codice sorgente perché
gli sviluppatori possono facilmente elaborare i propri sistemi basati su open source,
ad esempio GIT e Subversion. La gestione delle modifiche e della configurazione del
software (Software Change and Configuration Management, SCCM) va centralizzata
e consolidata, ad esempio configurata in sicurezza, gestita correttamente e installata
su un altro server protetto (McAfee Labs 2010). La scelta dei fornitori è fondamentale:
non tutti i prodotti SCCM, infatti, supportano un livello sufficiente di sicurezza e
controllo, ad es. controlli granulari e integrati degli accessi, funzioni dettagliate di
verifica e di creazione di registri (per individuare comportamenti anomali, garantire
9
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi
la verificabilità e favorire l’analisi forense dopo il verificarsi di un evento), analisi
integrata da parte dei colleghi, configurazioni base. Le aziende con le prestazioni
migliori si concentrano su solide procedure di controllo delle versioni (Puppet Labs
2014). Ad esempio, Google ha un unico repository di codice che supporta 15.000
ingegneri e 5.500 tra commit di codice e test automatici al giorno. Se i dirigenti di
Google riescono a contenere la proliferazione dei repository, chiunque può farlo!
5. Continuare a usare il mainframe per i sistemi transazionali principali: molte aziende
continuano ad ampliare la capacità del proprio mainframe, tra le altre cose per la
sicurezza senza eguali garantita da questi sistemi. Le vulnerabilità del mainframe
(secondo NIST e US-CERT) si contano sulle dita di una mano rispetto alle centinaia
che caratterizzano Windows, Linux e UNIX.
Perché Serena?
Da 35 anni Serena è impegnata ad aiutare le grandi aziende caratterizzate da normative
complesse a migliorare il ciclo di vita dello sviluppo del software, accelerando la distribuzione
del software stesso con meno rischi.
Serena conosce i problemi specifici delle grandi imprese ad elevata regolamentazione,
fornendo i propri servizi a più della metà delle società della classifica Fortune 100 quali
assicurazioni, banche commerciali, gestori dei pagamenti, gestori dei patrimoni, enti della
pubblica amministrazione, ospedali e fondi previdenziali , enti per la sicurezza
nazionale/difesa e telco. Ad esempio, negli Stati Uniti, tra i clienti di Serena figurano:

Otto delle10 banche principali

Le cinque società più importanti del settore aerospaziale e della difesa

Sei delle 10 compagnie leader di assicurazione sulla vita.

Le tre società più importanti nel campo delle assicurazioni sanitarie e fondi
previdenziali
Per soddisfare le notevoli esigenze di queste aziende di primo piano, Serena offre un
pluripremiato servizio clienti di livello eccezionale, con un personale che vanta un’esperienza
straordinaria, avendo prestato servizio in media per più di 11 anni. Il fatto che l’attenzione
venga posta sul cliente dà impulso alla fidelizzazione (in media, i 100 clienti principali di
Serena collaborano con quest’azienda da 18 anni).
I quattro prodotti più importanti della gamma di Serena accelerano l’adozione di best practice
per l’SDLC:

Serena Business Manager: una piattaforma per i flussi di lavoro che consente di
potenziare il livello di controllo dei processi lungo l’intero SDLC.

Serena Deployment Automation: per l’automazione della fase di distribuzione delle
applicazioni.

Dimensions CM: un sistema SCM (Software Change Management, gestione delle
modifiche del software) intuitivo per gli sviluppatori, scalabile, tracciabile e sicuro per
tenere sotto controllo il proliferare dei repository.
10
Serena Software
White paper: Alta velocità controllataPiù velocità senza inutili rischi

ChangeMan ZMF: lo strumento SCM mainframe leader per le applicazioni
transazionali mission critical.
Serena si attiene con dedizione alla prima regola definita dalle best practice, facendo in modo
che tutti i prodotti siano intuitivi per gli sviluppatori. Gli sviluppatori di software di Serena
utilizzano i prodotti dell’azienda per l’SDLC, sfruttando forum di consulenza per i clienti, gruppi
virtuali di utenti ed eventi per ottenere feedback dai clienti.
Le soluzioni Serena riflettono la complessità dell’SDLC aziendale, integrandosi con prodotti
di terze parti (open source, proprietarie, mainframe) e adattandosi facilmente a processi
personalizzati.
Serena Business Manager
In una grande azienda, il ciclo di vita dello sviluppo del software consta di flussi di lavoro
trasversali a team specializzati che si occupano di diverse aree funzionali, ognuno utilizzando
strumenti differenti per il proprio lavoro. In fase di rilascio del software, ad esempio, entrano in
scena sviluppo, QA e operation, mentre gli strumenti impiegati includono gestione del codice
sorgente, database dei difetti e gestione dei test. Altri flussi di lavoro comprendono gestione
delle modifiche, monitoraggio di problemi e difetti, gestione dei consulenti e onboarding del
personale.
In molte aziende questi flussi di lavoro non sono gestiti e i dipendenti usano una serie di
tecnologie ad hoc (ad es. e-mail, fogli di calcolo, ecc.) per promuovere il coordinamento
necessario per svolgere la propria attività. Tuttavia, se apparentemente permette di
risparmiare qualcosa, questo approccio non gestito presenta svariati costi e problemi
nascosti.
È opportuno che le aziende di dimensioni maggiori passino da flussi di lavoro non gestiti a
quelli gestiti nel loro SDLC, utilizzando un’applicazione per processi per ottenere i seguenti
vantaggi:





Promuovere un processo standard uniforme
Tenere traccia delle operazioni necessarie per ottemperare a policy e normative e per
supportare le verifiche
Garantire trasparenza e responsabilità, evidenziando chi fa cosa e chi no
Concentrarsi sui colli di bottiglia a livello di processi e risolverli a supporto di un
continuo miglioramento dei processi stessi
Automatizzare e orchestrare le procedure per ridurre il tempo dedicato ad attività che
non forniscono valore aggiunto
Storicamente, le applicazioni basate su processi nell’SDLC sono state sviluppate mediante
due possibili approcci: (1) se disponibile, acquistando un’applicazione pacchettizzata o un
servizio SaaS, oppure (2) sviluppando internamente soluzioni . Questi ultimi vengono
elaborati in una miriade di modi: applicazioni appositamente sviluppate in linguaggi di
programmazione moderni, inserendo scriptnon standard in sovrascrittura ai singoli prodotti o
persino utilizzando Lotus Notes e SharePoint.
11
Serena Software
White paper: Più velocità senza inutili rischi
Spesso le applicazioni pacchettizzate sono caratterizzate da scarsa flessibilità, risultando
difficili da personalizzare o da adattare a cambiamenti futuri. Di frequente i sistemi sviluppati
internamente sono complessi da gestire e possono non disporre di funzioni base condivisibili
aziendalmente quali il controllo della sicurezza e degli accessi.
Serena offre una “terza via” per sviluppare applicazioni basate su processi per la gestione
dei flussi di lavoro nell’SDLC: usando la piattaforma Serena Business Manager (SBM) per
l’automazione dei processi. SBM è una piattaforma BPM (Business Process Management,
gestione dei processi aziendali) per l’IT progettata da zero per automatizzare i processi chiave
che caratterizzano le diverse esigenze in termini di gestione dello sviluppo delle applicazioni e
dei rilasci, di processi operativi IT e, più in generale, di manutenzione dell’IT.
Di solito i clienti Serena applicano la piattaforma SBM in tre fasi diluite nel tempo: 1. ottenimento
di risultati rapidi nell’SDLC, 2. implementazione di SBM per gestire processi IT di più ampia
portata, 3. estensione di SBM a processi aziendali che si intersecano con l’IT (Tabella 1).
Tabella 1.
Fase
1.
2.
3.
12
Ottenimento di risultati
rapidi nell’SDLC. In genere,
potenziare il livello di controllo
dei processi nell’SDLC
rappresenta un’opportunità
ricca di obiettivi per SBM.
Implementazione di SBM per
gestire processi IT di più ampia
portata. SBM è una piattaforma
eccellente per la gestione dei
processi IT.
Estensione di SBM a processi
aziendali che si intersecano con
l’IT. Gli utenti più aggressivi di
SBM ne ampliano il raggio di
azione per gestire una vasta
gamma di processi aziendali.
Esempi

Serena offre modelli di processi per una serie di flussi di lavoro
dell’SDLC, tra cui:

Gestione di problemi e difetti

Gestione delle richieste di modifica

Gestione del lavoro e dei progetti

Gestione dei casi di test

Gestione del codice open source

Gestione dei rilasci: Serena offre un’applicazione basata sulla
piattaforma SBM per la gestione dei rilasci. Serena Release
Control favorisce la maturazione del processo di gestione dei
rilasci, migliorando trasparenza, tracciabilità e controllo.

Gestione dei servizi IT, ad es. Serena Service Manager,
un’applicazione supportata dalla piattaforma SBM che
promuove il passaggio alla gestione dei processi basata
su ITIL per incidenti, modifiche e problemi

Gestione della sicurezza, ad esempio gestione degli incidenti
di sicurezza e dei certificati

Gestione e monitoraggio delle risorse

Provisioning dei server

Analisi delle cause profonde

Risorse umane: onboarding/offboarding dei dipendenti,
gestione dei consulenti, provisioning di nuove assunzioni

Vendite: processo di definizione dei preventivi, approvazione
degli sconti, riferimenti dei clienti

Finanza: rimborso delle spese, approvazione delle richieste di
viaggio, richieste di acquisto, richieste di spese in conto capitale

Reparto legale: approvazione dei testi, conservazione ai fini di
contenziosi

Aspetti specifici del settore: elaborazione delle richieste di
risarcimento, gestione delle sperimentazioni cliniche
Serena Software
White paper: Più velocità senza inutili rischi
SBM offre i seguenti vantaggi come piattaforma per la gestione dei flussi di lavoro legati ai
processi:

Creazione rapida di applicazioni basate su processi: è possibile iniziare con uno
dei modelli di processo base per poi utilizzare Composer, uno strumento unificato
per la progettazione di applicazioni basate su processi, per perfezionare il risultato.
Composer è una soluzione completamente visiva che modella tutti gli aspetti di
un’applicazione, compresi flussi di lavoro umani, flussi di lavoro dei sistemi, integrazioni,
form dinamici e interazione tra gli utenti, regole aziendali, ruoli, privilegi, report e
dipendenze.

Facilità di personalizzazione e adattamento: gli analisti aziendali possono facilmente
modificare flussi di lavoro, form, dati, integrazioni, regole, privilegi e altri elementi
tassonomici utilizzando SBM Composer, per poi implementarli senza perdere dati
(anche cronologici) o pregiudicare l’integrità dei processi. Se necessario, è possibile
apportare modifiche anche a elementi dei processi dinamici. Tutte le modifiche
apportate ai processi vengono automaticamente sottoposte al controllo della versione
sia a design time che a run time e possono essere facilmente annullate.

Integrazione con altri sistemi: è possibile utilizzare il motore di orchestrazione
integrato per gestire integrazioni sofisticate con altri sistemi attraverso servizi Web e
API basate su REST, acquisire informazioni da più fonti e metterle a disposizione
degli utenti in tempo reale, nonché automatizzare le procedure che in precedenza
richiedevano un intervento manuale.

Utilizzo delle ricche funzionalità di creazione di report e di verifica: è possibile
concentrarsi sui colli di bottiglia a livello di processi con una libreria integrata di report
e dashboard di elencazione, di distribuzione, sulle tendenze e di altro tipo. Gli utenti
finali possono creare report avanzati per gestire e valutare il lavoro automatizzato in
SBM con procedure guidate per la creazione e la modifica di report di facile utilizzo.
SBM presenta inoltre funzioni complete di verifica delle modifiche, con funzionalità
automatiche di acquisizione delle modifiche stesse e di creazione di report su di esse,
a supporto della governance normativa.

Vasto modello di privilegi basato sui ruoli completamente personalizzabile in SBM
Composer: chi si occupa di progettazione dei processi può definire sicurezza basata
sui ruoli a livello applicativo fino al livello dei dati/del campo e specifiche azioni relative
ai flussi di lavoro per soddisfare requisiti di conformità normativa e di sicurezza.
Inoltre, il motore SSO (Single Sign-On) di SBM fa in modo che l’identità dell’utente
che partecipa venga diffusa in sicurezza in tutti i flussi di lavoro di sistema attivati per
garantire l’integrità delle transazioni.

Supporto dell’intera gamma di dispositivi in dotazione agli utenti (cellulari, tablet
e PC): ivi incluse approvazioni preferenziali e notifiche istantanee in ogni luogo o
circostanza in cui vi siano utenti al lavoro.
Serena Business Manager e le sue applicazioni per processi costituiscono la base di una
strategia volta a migliorare il controllo dei processi lungo l’intero SDLC, applicando poi lo
stesso rigore all’IT e al resto dell’azienda.
13
Serena Software
White paper: Più velocità senza inutili rischi
Serena Deployment Automation
Come ricordato in precedenza, molte aziende stanno adottando un approccio al rilascio di
nuove applicazioni avanzate basato sullo sviluppo ad alta velocità del software, che dà
impulso ai profitti in quanto “il software non rende dal punto di vista economico finché non
arriva agli utenti”.
Attualmente, tuttavia, la maggior parte delle aziende utilizza un processo di distribuzione
delle applicazioni altamente manuale, che prevede script personalizzati dettagliati per ciascun
livello dell’applicazione (ad es. database, Web, server) e può coinvolgere decine di persone
(se non di più) alla volta al telefono per ore.
Questo processo di distribuzione a elevato utilizzo di risorse non riesce a gestire i rilasci
di software a frequenza più elevata senza aggravare notevolmente il rischio di prestazioni
insufficienti o di vulnerabilità per la sicurezza. Inoltre, le aziende caratterizzate da normative
complesse devono supportare le funzioni di monitoraggio dettagliato e separazione dei
compiti necessarie per ragioni di conformità, uno scenario difficile in presenza di un
processo manuale.
La soluzione di Serena prevede l’automazione della distribuzione delle applicazioni mediante
Serena Deployment Automation.
Serena Deployment Automation offre i seguenti vantaggi:




Semplifica, standardizza e automatizza la distribuzione delle applicazioni multilivello
più complesse in tutti gli ambienti
Consente di distribuire in modo ottimale le applicazioni in ambienti eterogenei fisici
distribuiti, virtuali e cloud
Aiuta a ridurre anche del 90% gli errori delle applicazioni nelle operazioni di
produzione dei data center
Taglia anche dell’80% i tempi e i costi associati alla gestione delle distribuzioni
Di seguito vengono riportate alcune funzioni di Serena Deployment Automation:







Editor grafico di facile utilizzo per l’automazione di processi e distribuzioni
Distribuzioni basate su modelli mediante istantanee delle applicazioni
Repository di artefatti per archiviazione e tracciabilità sicure
Massima visibilità, report di verifica e di conformità pronti per l’uso
Architettura plug-in con supporto immediato dei principali ambienti applicativi
Sicurezza, approvazioni e supporto delle notifiche basati sui ruoli
Integrazione ottimale con strumenti di terze parti: SCCM, build e rilascio, QA, help
desk e ticket di assistenza
Serena Deployment Automation è il componente chiave di una strategia volta ad
automatizzare l’SDLC ogniqualvolta è possibile.
14
Serena Software
White paper: Più velocità senza inutili rischi
Dimensions CM
Dimensions CM di Serena vanta una storia di tutto rispetto, essendo uno
dei sistemi leader per la gestione delle modifiche e della configurazione del
software, con una solida presenza nelle aziende altamente regolamentate
dove il controllo assoluto sul processo e sugli artefatti di sviluppo del
software è un requisito imprescindibile.
Tuttavia, negli ultimi 5-10 anni, con l’adozione delle procedure moderne
elaborate da piccole imprese anche da parte dei team di sviluppo delle
grandi aziende, si sono diffuse rapidamente sacche indipendenti di
Subversion e GIT, popolari strumenti open source per il controllo delle
versioni.
La conseguente “proliferazione dei repository” ha provocato numerosi
problemi per le aziende caratterizzate da normative complesse:





Repository multipli di codice sorgente e altri artefatti stanno creando
potenziali problemi di sicurezza, di accesso e di perdita di dati.
Il controllo sulle policy che regolano l’accesso al codice sorgente è
per sua stessa natura debole.
L’ottemperanza a un processo di sviluppo documentato (ad
esempio controlli di sicurezza statici) viene compromessa.
La gestione della configurazione e delle modifiche viene eseguita
manualmente mediante labeling e/o la gestione delle differenze in
fase di check-in/merging negli strumenti open source.
Gli strumenti open source tengono traccia delle modifiche per
mezzo di file di registro, non database completi come un vero
strumento SCCM, limitando le funzionalità di verificabilità e di
monitoraggio.
Molti anni fa Serena ha riconosciuto questa situazione e ha effettuato
ingenti investimenti di carattere tecnico nello sviluppo di un vero strumento
SCCM facile
da usare e potente per gli sviluppatori, assicurandosi che non si scendesse
a compromessi nell’ambito del controllo dei processi e degli artefatti,
aspetto assolutamente cruciale per le aziende ad alta regolamentazione. Il
risultato,
il prodotto Serena più importante commercializzato negli ultimi sette anni,
è Dimensions CM 14.
Un cliente Serena
Una delle banche di
credito cooperativopiù
grandi e in più rapida
crescita degli Stati Uniti ha
collaborato con Serena a
supporto delle proprie
applicazioni per dispositivi
mobili, sempre più diffuse.
Il team di sviluppo usa
procedure moderne per
accelerare l'innovazione e
i tempi di risposta dei
clienti. I team addetti
alle verifiche e alla conformità, però, necessitano
di tracciabilità e sicurezza.
La banca di credito
cooperativ usa
ChangeMan ZMF per
supportare le applicazioni
nel sistema transazionale
back-end, Dimensions CM
per tutti gli altri ambienti
ed SBM a supporto del
controllo dei processi.
Dimensions CM 14 dispone di numerose funzioni apprezzate dagli sviluppatori:





15
Potente funzionalità di branching e merging a livello visivo.
Processo di analisi da parte dei colleghi ottimizzato e integrato.
Accesso ad alta velocità via WAN attraverso una cache di libreria locale.
Integrazione con i principali IDE (Integrated Development Environment, ambiente di
sviluppo integrato) come Eclipse e Visual Studio e con la moderna catena di strumenti
di distribuzione continua (Jenkins, Hudson, Chef, Puppet, ecc.).
Supporto dello sviluppo “mobile”.
Serena Software
White paper: Più velocità senza inutili rischi
Dimensions CM 14 presenta anche funzioni gradite ai team operation, QA e addetti
alle verifiche:




Controllo granulare degli accessi per stabilire chi può fare cosa, a quali oggetti,
quando e perché.
Analisi retrospettiva completa per le attività di sviluppo a supporto della conformità a
standard quali ISO9000, Capability Maturity Model Integration (CMMI), ecc.
Gestione integrata delle richieste di modifica con livelli di controllo configurabili.
Scalabilità fino a migliaia di utenti contemporaneamente, centinaia di terabyte di
archiviazione e milioni di versioni di file. Dimensions supporta il bilanciamento dei
carichi per una disponibilità elevata e il failover per il ripristino di emergenza.
Dimensions CM funge da hub aziendale sicuro e conforme per la gestione del codice sorgente
al di fuori dell’ambiente mainframe. Spostando tutto il codice sorgente (compreso quello
memorizzato in appositi repository come GIT e Subversion) nel centralizzato e sicuro
repository di Dimensions CM, si consolida il livello di sicurezza e conformità delle aziende in
termini di riservatezza, integrità e verificabilità:

Riservatezza: Dimensions supporta numerosi meccanismi di autenticazione con
controllo granulare degli accessi basato sui ruoli. GIT e Subversion garantiscono
un supporto minimo per il controllo granulare degli accessi basato sui ruoli,
l’autenticazione è limitata e difficile e il livello di autorizzazione è rudimentale
(ad es. interi repository per GIT).

Integrità: Dimensions dispone di solidi controlli antimanomissione per i dati in
movimento e quelli stabili, oltre a processi integrati stage-gate, di approvazione e di
revisione. In GIT e Subversion questo richiede una livello elevato di consolidamento,
personalizzazioni e strumenti di terze parti. Dimensions utilizza un’architettura
centralizzata ad alta velocità per garantire l’integrità dei dati.

”Auditabilità”: Dimensions offre un’analisi retrospettiva completa di chi ha fatto cosa,
quando e perché, con registrazione di tutte le transazioni in un sistema RDBMS
(Relational DataBase Management System). GIT e Subversion forniscono solo
un’analisi retrospettiva base sotto forma di registro dei commit e, in assenza di
strumenti di terze parti, non tengono traccia dei motivi delle modifiche.
Dimensions CM è la soluzione ideale per tenere a freno la proliferazione dei repository.
ChangeMan ZMF
Il mainframe, presente fin dagli anni ‘60, continua ad avere successo, soprattutto per i clienti
di grandi dimensioni che lo usano per complesse applicazioni transazionali. In base a uno
studio condotto da BMC, il 90% dei mainframe shop di grandi dimensioni prevede un uso
stabile o crescente di MIPS nei prossimi due anni (BMC 2014). I due motivi principali addotti
a giustificazione del protrarsi degli investimenti nel mainframe sono stati i vantaggi della
piattaforma mainframe in termini di disponibilità e i punti di forza per quanto riguarda la
sicurezza.
Nell’era della connettività Internet attiva 24 ore su 24 sette giorni su sette, le caratteristiche
di disponibilità (ad es. virtualizzazione hardware/software, ridondanza, funzionalità hot swap,
ecc.) e le tecnologie di sicurezza (ad es. coprocessori crittografici hardware) del mainframe
ne fanno il server dati centralizzato di elezione per settori ad alta regolamentazione quali
pagamenti, operazioni bancarie, assicurazioni e telecomunicazioni.
16
Serena Software
White paper: Più velocità senza inutili rischi
Le APPstanno facendo crescere il volume di transazioni nel mainframe.
Ad esempio, i clienti delle banche controllano più spesso i propri conti se sono facilmente
accessibili. Molti team che si occupano di mainframe si stanno rendendo conto che sviluppare
nuove APP e supportare quelle esistenti rientrano tra le priorità.
Serena ChangeMan ZMF è la soluzione più completa e totalmente integrata per la gestione
delle modifiche, della configurazione e del rilascio a livello di software in ambiente z/OS.
Da quasi 20 anni, grandi aziende con normative complesse si affidano a ChangeMan ZMF per
gestire e automatizzare il processo di migrazione delle modifiche del software dall’ambiente di
sviluppo a quello di testing e, in ultimo, di produzione.
ChangeMan ZMF è pensato per sviluppatori, addetti ai test e alla gestione dei rilasci:

Gli sviluppatori possono scegliere tra diverse interfacce utente, tra cui un ambiente
ISPF tradizionale o un client Windows. Gli utenti dell’IDE di RDZ, basato su Eclipse,
possono accedere alle funzionalità di ZMF senza abbandonare il proprio IDE. L’analisi
su vasta scala dell’impatto e lo sviluppo parallelo sicuro migliorano la produttività.

Gli addetti ai test apprezzano le ricche funzionalità integrate di approvazione e notifica,
nonché quelle che garantiscono la completezza e la stabilità della distribuzione del
codice. La promozione attraverso aree di test è sottoposta a rigidi controlli.

Gli addetti alla gestione dei rilasci usano le funzionalità integrate di calendario dei
rilasci, di pianificazione automatica degli stessi, di distribuzione automatica alle
fasi di testing e produzione e di annullamento completo al fine di ridurre il rischio.
La verificabilità è garantita imponendo l’integrità del codice sorgente da quando
viene creato al suo caricamento.
Uno dei punti di forza più significativi di Serena per le aziende caratterizzate da normative
complesse è la linea di prodotti per più piattaforme che supporta il ciclo di vita dello sviluppo
del software dal mainframe alle applicazioni per dispositivi mobili. Vista la crescente
importanza del mainframe per nuove applicazioni come quelle mobili, per molte aziende
sta diventando sempre più essenziale coordinare il proprio SDLC in aree chiave quali la
gestione dei rilasci. Serena è un partner tecnologico ideale per queste imprese.
Conclusioni e riepilogo
Le aziende di grandi dimensioni adottano moderne procedure per lo sviluppo ad alta velocità
del software, tra cui:




17
Sviluppo agile
Integrazione/distribuzione continua
DevOps
Lean
Serena Software
White paper: Più velocità senza inutili rischi
Domanda: quali procedure di sviluppo moderne sta adottando la tua azienda per
aumentare la velocità dello sviluppo del software?
Tuttavia, parallelamente all’implementazione di queste procedure moderne, le aziende a
elevata regolamentazione devono gestire tre rischi fondamentali nel ciclo di vita dello sviluppo
del software:



Sicurezza
Conformità
Prestazioni
Domanda: quali sono i rischi principali nel ciclo di vita dello sviluppo del software della
tua azienda? In che modo vengono individuati e affrontati?
I dirigenti possono prendere in considerazione cinque best practice per accelerare la
distribuzione del software e gestire il rischio. È opportuno che nello sviluppo della soluzione
vengano coinvolti rappresentanti dei team di sviluppo delle applicazioni, di sicurezza e verifica
e di gestione delle modifiche IT.
Di seguito vengono indicate le cinque best practice:
1. Adottare strumenti intuitivi per gli sviluppatori
2. Potenziare il livello di controllo dei processi lungo l’intero SDLC
3. Implementare l’automazione ogniqualvolta è possibile
4. Tenere a freno la “proliferazione dei repository” con un solido sistema centralizzato
per la gestione del codice sorgente
5. Continuare a usare il mainframe per i sistemi transazionali principali
Domande: la tua azienda ha predisposto un’iniziativa basata su una o più di queste best
practice? Sta procedendo velocemente e con urgenza? Chi si occupa della promozione di
queste iniziative?
Serena è un partner tecnologico ideale per i dirigenti di aziende con normative complesse che
desiderano incrementare la velocità dell’innovazione del software.
18

Serena è consapevole delle specifiche sfide dell’SDLC nelle imprese altamente
regolamentate.

I quattro prodotti più importanti della gamma di Serena accelerano l’adozione di best
practice per l’SDLC:

Serena Business Manager per potenziare il controllo dei processi lungo l’intero
SDLC

Serena Deployment Automation per automatizzare la distribuzione delle
applicazioni
Serena Software
White paper: Più velocità senza inutili rischi

Dimensions CM per tenere a freno la proliferazione dei repository

ChangeMan ZMF per supportare i principali sistemi transazionali mainframe

Serena si integra con sistemi di terze parti e spazia dal mainframe ai dispositivi mobili
lungo l’intero SDLC.

Serena offre un servizio clienti best-in-class mirato all’SDLC.
Domanda: in che modo Serena può aiutare la tua azienda a muoversi velocemente
senza inutili rischi?
19
Serena Software
White paper: Più velocità senza inutili rischi
Riferimenti
Appleton, Stephen Berczuk e Brad. 2003. Software Configuration Management Patterns: Effective
Teamwork, Practical Integration. Addison-Wesley.
BMC. 2014. 2014 Annual Mainframe Research Results. Risultati della ricerca, BMC Software, Inc.
Drummond, David. 2010. google.com. 12 gennaio.
http://googleblog.blogspot.com/2010/01/new-approach-to-china.html.
Epps, Cindy Van e Nick Norris. 2012. Software Development Compliance - Overview. 28 settembre.
https://jazz.net/library/article/856.
Farley, Jez Humble e David. 2011. Continuous Delivery: Reliable Software Releases through Build, Test,
and Deployment Automation. Pearson Education, Inc.
Fowler, Martin. 2006. Continuous Integration, maggio.
www.martinfowler.com.
Gene Kim, Patrick Debois, John Willis, Jez Humble, Damon Edwards, John Allspaw. 2015. The DevOps
Cookbook. Pubblicazione prevista nel 2015, l’autore ha rivisto la prima bozza.
Heusser, Matthew. 2012. Software Testing Lessons Learned from Knight Capital Fiasco. 14 agosto.
http://www.cio.com/article/2393212/agile-development/software-testing-lessons-learned-from-knightcapital-fiasco.html.
James Manyika, Michael Chui et al. 2013. Disruptive technologies: Advances that will transform life,
business, and the global economy. McKinsey & Co.
Jez Humble, Joanne Molesky e Barry O’Reilly. 2014. Lean Enterprise: How High Performance
Organizations Innovate at Scale. O’Reilly Media.
Kent Beck, et al. 2001. Manifesto for Agile Software.
http://agilemanifesto.org/.
McAfee Labs. 2010. Protecting Your Critical Assets: Lessons Learned from “Operation Aurora”. McAfee.
MSDN. 2006. Regulatory Compliance Demystified: An Introduction to Compliance for Developers.
Marzo.
http://msdn.microsoft.com/en-us/library/aa480484.aspx.
Nanex Research. 2012. The Knightmare Explained. 3 agosto. http://www.nanex.net/aqck2/3525.html.
Puppet Labs. 2014. “2014 State of DevOps Report”.
Silver-Greenberg, Jessica. 2012. Trying to Be Nimble, Knight Capital Stumbles. 2 agosto.
http://dealbook.nytimes.com/2012/08/02/trying-to-be-nimble-knight-capital-stumbles/?_r=2.
Tracy, Ryan. 2014. wsj.com. 10 ottobre.
http://www.wsj.com/articles/j-p-morgans-dimon-to-speak-at-financial-conference-1412944976.
Vodde, Craig Larman e Bas. 2009. Scaling Lean & Agile Development. Pearson Education.
Zetter, Kim. 2010. Report: Google Hackers Stole Source Code of Global Password System. 20 aprile.
http://www.wired.com/2010/04/google-hackers/.
20
Serena Software
Informazioni su Serena
Sito Web: www.serena.com
Telefono: 1-800-457-3736
E-mail: [email protected]
Serena Software fornisce alle aziende Global 2000 soluzioni per lo sviluppo orchestrato
delle applicazioni e la gestione orchestrata dei rilasci. I nostri 2.500 clienti aziendali attivi,
tra cui la maggior parte delle società della classifica Fortune 100, hanno fatto di Serena
il più grande fornitore ALM (Application Lifecycle Management, gestione del ciclo di vita
delle applicazioni) indipendente e l'unico a orchestrare DevOps, i processi che integrano
sviluppo applicativo e operations. Serena, con sede nella Silicon Valley, è una società
partecipata di HGGC, una media impresa di private equity leader del settore.
Copyright © 2015 Serena Software, Inc. Tutti i diritti riservati. Serena è un marchio registrato di
Serena Software, Inc. Tutti gli altri nomi di prodotti o società vengono utilizzati esclusivamente a
scopi identificativi e potrebbero essere marchi dei rispettivi titolari. Febbraio 2015. ID documento:
WP-151019
21
Serena Software