Security & Architecture : Metodologie

Acceptance Test Engineering Guide – BETA 2

mfontana — Wed, 01 Jul 2009 17:31:10 GMT

Questa nuova guida di P&P parla dell’ acceptance testing ovvero (in due parole) della disciplina che racchiude tutte le scelte che devono essere fatte per verificare se un particolare software è compliant ai requisiti richiesti e quindi può essere considerato valido per sè o per i propri clienti.

E’ una disciplina non comunemente adottata nei progetti e quindi ne consiglio una lettura, in modo da capire come eventualmente adattarla al proprio ciclo di sviluppo del software.

Questa guida copre vari temi del acceptance testing analizzandoli da diversi punti di vista fornendo un aiuto alla pianificazione, alla creazione ed esecuzione di questi test. Di particolare interesse la descrizione di cosa debba significare “software accettato” e come giustificare l’introduzione del Acceptance Testing all’interno della propria organizzazione.

Inoltre, questa guida sarà la prima di 3 pubblicazioni sul tema:

Acceptance test engineering guide (questa)
Acceptance test automation guide.
Tool support for acceptance test-driven development

Buona lettura

--Mario

Parte l'iniziativa italiana MSDN Talks

mfontana — Mon, 31 Mar 2008 11:25:00 GMT

3..2..1..Pronti via...Parte ufficialmente: MSDN Talks !! Sull'onda dei feedback delle prime interviste estendiamo lo scope anche ai numerosi esperti presenti all'interno di Microsoft italia (e non solo) al fine di condividere esperienze e passioni maturate durante la realizzazioni di progetti reali. Per l'occasione abbiamo anche un LOGO disegnato dal nostro creativo di fiducia :-)

Non solo tecnologia quindi, ma anche best practices e consigli pratici frutto di mesi di lavoro sul campo... Queste interviste, come avrete modo di constatare sono molto "naturali" ovvero non ci sono prove di registrazione o backstage particolari :-) (nel bene e nel male). L'idea è semplicemente quella di condividere le "chiacchierate" che spesso facciamo nelle varie riunioni interne oppure, perchè no, alla macchina del caffè... (infatti non vi nascondo che un nome proposto ai video era Microsoft Cafè... ma era troppo simile ad una nota trasmissione di cui io sono un fan sfegatato :-)

Iniziamo l'avventura con un'intervista ad Alessandro Huber, CTO di Microsoft Services, il quale ci parla del ruolo di CTO, del modo di approcciare i progetti da parte di Microsoft Consulting e soprattutto dell'esperienza e le sfide incontrate durante i lunghi mesi di lavoro che hanno portato alla creazione di uno dei maggiori progetti in italia : CFF (Connected Financial Foundation) per soluzioni bancarie che Microsoft Corporation sta trasformando in una solution da distribuire su tutti i mercati world-wide.

Vista anche la parte introduttiva dei servizi questo video dura un po' di più (circa una mezzoretta) di quello che sarà la durata media dei video MSDN Talks (10-20 minuti). I video di MSDN Talks saranno di due tipi : architetturali e di sviluppo. I primi, come quello presentato oggi, parleranno di esperienze nel disegno di soluzioni complesse mentre quelli relaviti allo sviluppo daranno la voce ai senior developers che hanno implementato e portato in produzione le soluzioni.

Alla linea "classica" di MSDN Talks si aggiungerà anche la versione "LIVE" dove verranno intervistate persone riconosciute particolarmente esperte di tecnologie Microsoft durante i vari eventi in giro per l'italia (e non solo).

Non mi resta che augurarvi buona visione...

Il progetto CFF

Il CFF permette di realizzare una serie di moduli funzionali a livello infrastrutturale che consentano di realizzare una piattaforma finanziaria a livello enterprise e che al contempo contenga l’approccio architetturale service-oriented in modo da rendere flessibile e semplice ogni tipo di integrazione.

Il CFF è quindi un’infrastruttura applicativa modulare con le seguenti caratteristiche :

Piattaforma per la realizzazione di Smart Client e Web Client.
Piattaforma Multicanale a supporto dei diversi devices che potranno essere utilizzati oggi e in futuro.
Infrastruttura Modulare basata su SOA
Contenitore delle diverse applicazioni con condivisione del contesto
Supporto di servizi applicativi quali: transazioni, messaging, deployment e aggregazione di servizi.
Autenticazione, Autorizzazione e sicurezza in generale.
Ambiente per l’Orchestrazione dei processi di business.
Servizi di integrazione tecnologici ed applicativi.
Supporto all’analisi dei processi di business: Business Activity Monitoring.
Supporto per la realizzazione di applicazioni instrumentate, gestite e affidabili.
Metodologie basate su MSF (Microsoft Solutions Framework) implementato via Team System.
Sicurezza e affidabilità verificate durante tutto il ciclo di sviluppo della soluzione.

Alcuni link informativi sul CFF

http://www.key4biz.it/News/2007/06/01/Tecnologie/Finanza_e_IT_Microsoft_Italia_presenta_la_nuova_stategia_e_la_piattaforma_modulare_CFF.html

http://www.cwi.it/showPage.php?template=articoli&id=17739

--Mario

PS: un saluto particolare a Sandro che per anni ha avuto la pazienza di essere il mio capo e che da quando non lo è più è tornato ad essere sereno :-) :-) :-)

Evoluzione dell' ALM nelle nuove architetture applicative

mfontana — Sun, 16 Mar 2008 12:36:08 GMT

Giovedì 20 Marzo sarò presente a Milano all'evento di ItWare dal titolo "SOA, Web 2.0 e SaaS : un percorso strutturato verso l'IT del futuro" con l'intervento : Evoluzione dell' ALM nelle nuove architetture applicative.

Un evento importante per capire le esperienze delle principali società che lavorano nelle architetture applicative nelle nell'ambito Enterprise.
L'evento è rivolto a :

CIO, Direttori Sistemi Informativi, Organizzazione e Pianificazione di aziende di medie e grandi dimensioni

Responsabili delle architetture, delle infrastrutture, dello sviluppo e della conduzione dei sistemi

Project Manager e sviluppatori di applicazioni, prodotti e servizi software

Abstract del convegno:

"Le SOA (Services Oriented Architectures) non si comprano: si progettano e si allestiscono.
Ma alle SOA si arriva solo se ben preparati, se ne sono stati rispettati i prerequisiti e se si hanno le idee chiare.
E una volta arrivati alle SOA, si è pronti per partire verso traguardi ben più ambiziosi. A patto di sapere in che direzione andare, non solo sul piano tecnico, ma soprattutto su quello Manageriale, confrontandosi con il Business su fatti concreti quali l'erogazione dei servizi, il loro contributo alla creazione di valore, il ritorno degli investimenti per l'impresa.

Le esperienze di chi dalle SOA sta già traendo i benefici attesi dimostrano che si tratta di affrontare un percorso con molti ostacoli, ma con ben maggiori soddisfazioni, nel quale si coniugano elementi quali il Computing on Demand, la Virtualizzazione, l'impiego del software come servizio (Software as a Service - SaaS) ed il Business Process Outsourcing. Mete alle quali si arriva passando dallo Stack di componenti specifici delle SOA (ESB, Registry, Services Server,..), in abbinamento alle dirompenti tecnologie del Web 2.0, tipo Ajax ed il Mashup."

--Mario

Web Service Software Factory: Modeling Edition

mfontana — Sun, 02 Mar 2008 15:30:27 GMT

E' uscita da poco la versione per Visual Studio 2008 della Service Factory con relativi link agli Hands-on Labs.

Questa service factory è un insieme di risorse per architetti e developers per realizzare soluzioni a servizi seguendo una serie di design patterns e architectural best practices ben definiti. La soluzione comprende principalmente della documentazione con relativo codice sorgente e tre DSL (Domain Specific Language) per la modellazione della soluzione : Service Contract Model, Data Contract Model, ed l' Host Model.

L'architettura della software factory è completamente estendibile ed adattabile alle proprie esigenze di progetto. Personalmente quando ero in Microsoft Consulting le ho usate spesso, magari anche solo come riferimento e aiuto nell'impostazione di alcune parti di progetto. Rappresentano comunque materiale importantissimo per chiunque debba progettare delle soluzioni di classe Enterprise.

Dietro le quinte la Service Factory utilizza le estensioni del GAX/GAT e del DSL Toolkit oltre a varie tecniche per il model validation e il code generation.Nella figura sottostante è rappresentata la dipendenza delle varie tecnologie utilizzate nella Service Factory

</Mario>

Due chiacchiere su SOA e EDA...

mfontana — Thu, 14 Feb 2008 00:17:06 GMT

Service Oriented credo sia uno dei termini più blasonati e "overlodati" (scusate il riferimento Object Oriented, ma non è a caso) degli ultimi anni in ambito architetture applicative. L’architettura orientata ai servizi o service-oriented può essere considerata una derivazione del concetto object oriented presente nella letteratura dell'ingegneria del software visto con un 'ottica più di business che tecnologica. Infatti, questa architettura si basa sull'ipotesi che processi complessi possano essere ricondotti a componenti o unità di dimensioni limitate e compiute chiamati servizi. Questi servizi possono essere composti da un motore di composizione/orchestrazione per formare le applicazioni di business.

I tre elementi base presenti in una SOA sono :

Service Consumer : colui che utilizza i servizi. (a sua volta può essere un servizio o una applicazione).

Service Provider : colui che eroga il servizio (che è in ascolto di incoming messages).

Service Broker o Directory : registrazione dei servizi ed eroga funzionalità di ricerca.

tra questi attori sono possibili molte modalità di comunicazione chiamate anche Message Exchange Patterns (MEP)-

L’architettura a servizi SOA (Service Oriented Architecture) nasce con l’obiettivo di realizzare servizi, chiamati anche processi di business, disponibili a un qualsiasi richiedente o consumer. Il modello SOA consente una conversazione semplice basata sul paradigma consumer/provider tramite interfacce e protocolli standard e l’integrazione di servizi composti.

SOA è un paradigma che prevede lo sviluppo e l’impiego di servizi in accordo con i seguenti principi (o tenets):

• I boundary sono espliciti.
• I servizi sono autonomi.
• I servizi si scambiano schemi e contratti, non classi.
• La compatibilità tra servizi è stabilita via Policy.

L' architettura SOA non richiede la presenza di server centrali o funzioni amministrative centralizzate, ma consente la comunicazione fra trust diversi e fra entità indipendenti. I moduli e i protocolli non presuppongono la presenza di alcuna tecnologia di implementazione specifica presso l'endpoint applicativo. Inoltre, il paradigma SOA ha ridefinito anche il concetto di applicazione. Un’applicazione non è più semplicemente un’implementazione procedurale locale o distribuita ma al contrario una sequenza di messaggi orchestrati, dinamicamente instradati e trasformati.

L’obiettivo primario di un’Architettura Applicativa definita secondo il modello SOA deve essere quello di abilitare e gestire i processi di business. Infatti, tali processi svolgono un ruolo fondamentale nel determinare il valore effettivo di un'organizzazione. Processi di business ben strutturati consentono alle organizzazioni di creare del valore utilizzando in modo efficiente persone e prodotti. La piattaforma applicativa deve quindi integrare in modo efficace sistemi dipendenti e partner commerciali attraverso processi di business facilmente gestibili al fine di automatizzare e organizzare al meglio le interazioni. Inoltre deve essere garantita un’elevata flessibilità riducendo al minimo la necessità di intervento umano. Queste potenzialità derivano direttamente dalle caratteristiche peculiari di un’architettura SOA. Gli sviluppatori potranno continuare a lavorare nell'ambiente di sviluppo a loro familiare ed in aggiunta avranno l'opportunità di utilizzare servizi basati su standard per garantire maggiore protezione ed affidabilità nell'automazione dei processi di business interni ed esterni all'azienda.

Adottare un modello SOA significa creare un ecosistema infrastrutturale, capace di dare dei benefici a tutti i diversi livelli presenti nell’azienda.

La definizione di una nuova architettura è collegata principalmente alle seguenti macro esigenze strategiche:

Migliorare la maintenance dei sistemi consolidando le tecnologie.
Centralizzare le attività comuni a tutte le applicazioni.
Interoperabilità tra diverse tecnologie in modo nativo.
Facilitare la definizione e la realizzazione di nuovi processi produttivi.
Aumentare la disponibilità dei servizi aziendali a tutta l’organizzazione.
Permettere una migliore sinergia tra aree aziendali separate.
Aumentare la semplicità d’uso da parte degli utenti.

The Big Picture

Nella definizione di una infrastruttura applicativa basata sui principi di SOA e di EDA è necessario definire un "ecosistema applicativo" che comprenda tutte queste macro aree:

ovvero:

Event Driven Architecture (EDA)

Negli ultimi anni, insieme all’architettura SOA, è emerso anche un secondo modello chiamato Event Driven Architecture (EDA).

EDA è un’architettura che permette ai servizi di reagire dinamicamente agli stimoli “esterni”. Questi stimoli possono essere generati da diverse fonti: sistemi, persone, processi di business oppure eventi di natura tecnica predeterminati o non previsti. Gartner fornisce una definizione precisa di evento:

Evento Ordinario: gli eventi ordinari sono semplicemente qualche cosa che è accaduto.
Evento Software: Un evento Software è la registrazione automatica di quanto accaduto. Gli eventi software sono oggetti, spesso codificati in forma di messaggi, che rappresentano un evento ordinario.

In EDA gli end-point sono fortemente slegati e gestisce le notifiche con modello PUSH.

Il routing in EDA riveste un aspetto molto importante:

Due tipi di message routing:

Definito a design-time
- client<->server
- flow based (Biztalk, batch,...)
Definito a run-time
- content based.
- eventi

Relazioni tra SOA e EDA

Come si può notare nella figura sottostante SOA e EDA possono coesistere ed hanno molti punti in comune, ma non sono la stessa cosa !!!

infatti possiamo riassumere la relazione in 4 casi:

anche in relazione alla scalabilità dei modelli disconnessi

Da un punto di vista pratico vorrei riassumere la realzione in questi termini:

Riguardano differenti aspetti dello stesso problema (architettura applicativa).
EDA è un componente “core” di un sistema (anche SOA) che descrive un particolare “message routing” tra i servizi.
EDA trasforma il concetto di “loosely coupled”, definito in SOA, in “decoupled”
- SOA: il producer e il consumer condividono il “Service contranct”
- EDA : nessuna condivisione
EDA da per scontato la presenza di un “message bus”. SOA NO !!!!!!!!! (so che alcuni di voi stanno storcendo il naso :-)
SOA può contenere al suo interno un routing dinamico completamente “decoupled” (EDA).
Le due architetture definiscono il messaggio in XML trasportato tramite SOAP.
SOAP supporta gli “interaction patterns” sia per SOA che per EDA.

Tassonomia degli scenari Event Driven

Gartner inoltre suddivide la tassonomia degli scenari Event Driven in quattro categorie:

Simple Event Driven Applications.
- Gestione diretta, ogni sorgente contatta direttamente gli opportuni sink.
- Nessuna ipotesi di accoppiamento sorgente-sink se non la comune comprensione del formato degli eventi(messaggi) scambiati.
Brokers-Mediated Applications.
- Viene implementato tramite un intermediario: il broker.
- Il broker può effettuare content based routine dinamico dei messaggi.
- Il broker può applicare regole applicative.
BPM (Business Process Management) directed Applications
- Gestione di processi long running contattando gli endpoint anche a seconda dei loro ruoli legati all’istanza della business activity stessa.
- Può essere configurata in due modalità:
  - Broker
  - Può gestire messaggi che iniziano o terminano business activities.
Complex Event processing Applications
- Sistema di gestione centralizzato.
- Filtra gli eventi instradandoli secondo regole anche complesse.
- Può aggregare insiemi di eventi in messaggi di ordine superiore riconoscendo dei pattern codificati.

Concludendo l'architettura SOA e EDA sono complementari ed entrambe molto importanti per l’evoluzione nell’ambito IT.

Criteri di valutazione SOA

Microsoft per la valutazione di una Service Oriented Architecture utilizza un modello chiamato ESOMM (Enterprise Service Orientation Maturity Model).

Questo modello deriva dal SW-CMM (Capability Maturity Model for Software) di Watts Humphrey successivamente gestito dal Software Engineering Institute (SEI) della Carnegie Mellon University (CMU) di Pittsburgh (USA). SW-SMM rappresenta lo standard per la valutazione e il continuo miglioramento dei processi di sviluppo del software.

ESOMM applica lo standard definito da SW-CMM al modello SOA ed evidenzia gli aspetti di valutazione.

ESOMM si basa su quattro aree funzionali per l’azienda:

Extensible : L’azienda deve essere in grado di aggregare i servizi e di estenderne il loro utilizzo
Supportable : L’azienda deve poter gestire facilmente un incremento nell’uso dei servizi per garantire gli SLA definiti.
Repeatable : L’azienda implementa,consuma e riutilizza i servizi in modo efficiente e consistente.
Usable : L’azienda è in grado di scrivere e consumare servizi tramite protocolli standard senza fatica.

Queste quattro aree vengono valutate rispetto a tre fattori : Implementation, Consumption e Administration formando la seguente griglia:

Questa griglia deve essere di riferimento durante la definizione e l’implementazione di una architettura SOA in ambiente enterprise.

--Mario