Software Methodologies, Software Engineering and Reverse Engineering
Le informazioni, prodotti, marchi referenziate nelle pagine seguenti rimangono di proprieta' dei rispettivi produttori, a norma delle leggi internazionali sui © copyright © non e' consentito l'uso delle stesse a scopo di lucro e/o la riproduzione senza consenso scritto
All info trademarks or product names mentioned herein are the property of their respective owners
 
Informazioni, chiarimenti, discussioni at Contact point Giovanni.Secondulfo@inwind.it  
Ritorno all'Indice SW Enginnering Ritorno alla Home Page

L'intento del documento‚ sostanzialmente quello di operare una sintesi di esperienze, delle metodologie consolidate e dei trend internazionale di approccio alla problematica SE. Le pagine che seguono non hanno intenzione alcuna di traumatizzare il lettore con proposte rivoluzionarie.
Gli obiettivi che ci si prefigge sono essenzialmente due: La struttura del documento‚ quella seguente:
L'orientarsi verso metodologie standard di analisi e sviluppo di applicazioni e/o sistemi, sia general purpouse che in tempo reale, ha come obiettivo quello di fornire uno strumento integrato, asservito alle fasi di: documentazione, analisi, progetto, realizzazione e manutenzione di un sistema od applicazione. In particolare l'adozione di una metodologia assicura la produzione della documentazione a priori ed a posteriori nel senso che durate la fase di progetto la si utilizza come strumento per il trattamento e la fluizione delle informazioni fra i varii team di progetto, ed a realizzazione ultimata del sistema e/o applicazione ne consente la gestione ed il supporto.
L'adozione di una metodologia deve avere l'ambizione di coprire tutte le fasi della realizzazione di un progetto, cercando di automatizzarle il piu' possibile, nonche' enfatizzare le problematiche di integrazione e di coerenza con gli standard, e comunque costringere a lasciar traccia di quanto si e' fatto, in forma pianificata, controllata ed automatizzata.
L'adozione di procedure non rigidamente strutturate e/o mal controllate porta al verificarsi di fenomeni come quello citato in una  uno studio del DOD ( Department Of Defense ) statunitense che ha analizzato contratti per un ammontare di 7 milioni di US$
  La relazione tra i costi dello sviluppo per la prima release presenta la seguente statistica
  Sull'intero ciclo di vita si ha invece la seguente statistica:
  Gli errori e le cause di non gradevolezza sono invece cosi' allocabili: Sempre da tale studio scaturisce un costo di trattamento per linea di codice validata in fase di produzione pari a 75 US$ che sale vertiginosamente a 4000 US$ per linea di codice validato in fase di manutenzione.
Dai risultati non esaltanti proposti in precedenza nasce l'esigenza di darsi degli strumenti e modificare opportunamente il ciclo di vita del software tradizionale in modo da avere delle proiezioni rapide sia sulle funzionalita' che si vanno ad implementare sia sul gradimento da parte dell'utente sull'implementazione effettuata.
 

1. Analisi del contesto
Al fine di condurre una corretta acquisizione di un package o insieme di packages bisogna definire puntualmente le dipendenze  che questi hanno con l’hardware ed il software (System Calls, message passing e le interazioni con l’utente) all’ambiente nativo.
Per effettuare una corretta e completa operazione di acquisizione bisogna quindi disporre :
 

  1. Source CODE
  2. Documentazione di Top Level Analisys
  3. User Requirements
  4. Eventuali Raccomandazioni di Enti di Standardizzazione (ISO, CCITT, …)
  5. Internal Specifications
  6. External Specifications
  7. Dimestichezza end User sul sistema nativo
  8. Dimestichezza end User sul sistema target
  9. Test List (end user)
I passi da seguire sono:
  1. Analisi dei packages intesa come:
    1. Struttura SW
    2. Interfacce HW
    3. Interfacce con il S.O.
    4. Prestazioni
  2. Verifica di consistenza dei sorgenti acquisiti mediante rigenerazione di tutti i packages in ambiente nativo, e relativo testing (mediante dei manual test script).
  3. Attuazione di una politica di Source Control per il managing del codice
  4. Manutenzione Adattativa del codice acquisito
  5. Sviluppo di tools di supporto al SW manifacturing
  6. Ricompilazione su macchina target
  7. Testing su macchina target (manual test script)
 
Laddove manchi qualche elemento documentativo necessitera’ effettuare un’operazione di estrazione e/o astrazione delle informazioni.

Torna all'Indice Generale


2. Ciclo di Vita
2.1 Generalita’
L'obiettivo di questo paragrafo e’ quello di analizzare un ciclo di vita del software che consenta di gestire correttamente sia il forward che il reverse engineering delsoftware.
Viene proposto un ciclo completo al fine di mostrare il contesto al quale si fa’ riferimento per la produzione del software; daltronde la definizione di un ciclo di reverse engineering richiede che sia stato formalizzato completamente un ciclo di forward engineering.
Ogni fase dovra’ concludersi con l'emissione di una documentazione completa ed esaustiva in modo tale che la fase successiva possa procedere autonomamente e senza ambiguita' a partire da questi documenti. La produzione di una documentazione costituisce l'output della fase, il suo rilascio ad entita’ esterne costituisce una milestone per l'intero progetto, tale milestone costituisce in generale l'inizio di una fase successiva. Da quanto precede gli output vanno sottoposti, prima del rilascio, ad una review ovvero, ad un riesame critico e validazione. L'obiettivo della review ‚ quello di individuare eventuali errori prima che questi possano filtrare verso altre fasi del ciclo di vita, nel qual caso la rimozione di questi avrebbe un costo sicuramente maggiore; pertanto la review puo’ comportare un riciclo immediato sulla fase precedente. Tale attivita’ va’ intesa come di supporto nella fase di verifica e non come interferenza di gruppi esterni sul lavoro del producer. Tale attivita’ va’ affidata ad un team costituito da:
producer
sceglie il review leader, invia la documentazione ai partecipanti alla review, per un'analisi preventiva
review leader
il cui compito ‚ quello di ottenere una buona review, ovvero ottenere un report esaustivo su quanto emerso nella review
reviewers
hanno il compito di supportare il producer nell'analisi critica dell'output, e proporre soluzioni ad eventuali errori
recorder
ha il compito di annotare quanto emerge nella review, e redigere il report finale

La review deve essere informale quanto basta onde consentire una disamina serena, ma nel contempo necessariamente critica per l'individuazione di eventuali errori.

Torna all'Indice Generale

2.2 Ciclo di Vita
Il ciclo di vita cui si fara’ riferimento e’ riportato in Fig. 1 Nei paragrafi  successivi verranno descritte in dettaglio tali fasi
Le singole fasi andranno opportunamente pianificate mediante strumenti oggettivi ( Gant, Pert, ...) sia all'interno del singolo ente/gruppo sia attraverso milestone verso altri enti aziendali/ gruppi .
Il processo di elaborazione di ogni fase si concludera’ con un output costituito da documenti formalizzati secondo modelli standard.
Il modello proposto e' una variante al modello comunemente detto waterfall.

Torna all'Indice Generale

2.2.1 System Requirement Analysis
Questa fase viene attivata sulla base di un documento di Product Requirements prodotto dal Marketing, in cui sono descritte le caratteristiche del prodotto richieste dal mercato.
Sinteticamente si puo' dire che e' la fase in cui si comprendono e si rappresentano i bisogni ( requirements ) di utente e del sistema.
Il prodotto di questa fase dovra' essere un documento in cui le esigenze informative dell'utente vengono esposte in modo organico attraverso un linguaggio, il piu' formale possibile, che consenta ai due interlocutori di superare ambiguita' ed incomprensioni. Queste caratteristiche sono indispensabili, infatti questo documento rappresentera' l'input per la seconda fase (quindi strumento di lavoro per l'analista) ed inoltre dovra' essere comprensibile all'utente che dovra' approvarlo.
L'esigenza della produzione di un documento di questo tipo e' motivata dal fatto che i bisogni di utente sono il punto di partenza dello studio seguente, impegnativo e costoso, e pertanto dovranno assicurare una solida base per lo sviluppo dei passi successivi, saranno in realta' possibili variazioni ai requirements iniziali ma e' auspicabile che non modifichino nella sostanza le richieste originali.
La raccolta di queste informazioni necessarie alla stesura del documento avviene, attraverso acquisizioni di normative, interviste con utenti e management, questionari ecc.

Scopo di questa fase di analisi e' quello di produrre i seguenti documenti :

I documenti sopra elencati possono essere in questo ciclo sottoposti a raffinamenti successivi in virtu' delle indicazioni derivanti dalla attivita' di prototipazione.
Da un punto di vista della metodologia da applicare si va' consolidando l'utilizzo della " Facilitated Application Specification Techniques " (FAST), basato su incontri fra committente e progettisti sotto il controllo di un coordinatore, l'obiettivo di tali incontri ‚ e' la preparazione di :
  1. lista di :
    1. oggetti da produrre;
    2. attivita' ;
    3. limiti del sistema e dell'implementazione;
    4. pianificazione di massima dei tempi di rilascio;
    5. criteri di validazione;
  2. documento di minispecifiche.
Questa tecnica ‚ e'  basata su un approccio sufficientemente formale in modo da coprire tutti i punti importanti, ma nel contempo sufficientemente informale onde consentire il libero flusso di idee tra le figure coinvolte in questa fase.
I documenti prodotti in questa fase saranno il punto di partenza per l'analisi di sistema, nella cui sede si provvedera' a rielaborarli e dettagliarli opportunamente.

Torna all'Indice Generale

2.2.2 Prototyping
Da statistiche sui costi di manutenzione del software si ricava che un errore introdotto nella fase di Requirement Analysis risulta essere di almeno due ordini di grandezza piu' costoso di errori introdotti in altre fasi. Tale considerazione suggerisce l'uso della tecnica di Prototipazione al fine di oggettivare all'utente finale il risultato dell'analisi dei Requirements.
Si intendera' per Prototipazione quel processo atto a realizzare un modello delle funzionalita' del prodotto target, in modo da essere esercitato dall'utente finale, prima che questo sia stato progettato.
Se l'esercizio copre tutte le funzionalita' si realizza la Simulazione.
Questa fase e' assimilabile ad un processo di review della fase di Requirements Analysis, ed ha come input i documenti prodotti nella fase precedente il suo output sono i documenti stessi revisionati. Questa fase produce una milestone verso l'esterno costituita dall'accettazione formale delle specifiche da parte dell'utente e del gruppo di Progetto.
Il processo di prototipazione e' sintetizzabile come in Fig. 2.
La prototipazione affinche' sia significativa deve essere Rapida e deve essere in grado di combinare strumenti e tecnologie in modo tale che ( Fig. 4 ) partendo da specifiche informali si riesca ad ottenere, per trasformazioni successive, delle specifiche operazionali orientate al problema e poi all'ambiente target.

Torna all'Indice Generale

2.2.3 Top Level Design
In questa fase viene definita l'architettura del sistema ( HW, SW, FW ) in funzione dei requirements e delle opportunita' tecnologiche disponibili, e si ha la scomposizione in moduli del sistema con una valutazione in termini di pianificazione su cosa puo' essere sviluppato in modo proprietary e su cosa va' acquisito dall'esterno. La possibilita' di esternizzare o internizzare una produzione va' effettuata in funzione delle possibilita' di acquisisire Know How riutilizzabile, e dei costi della realizzazione. L'output di questa fase consiste in:

Da un punto di vista delle metodologie questa fase puo' essere supportata da diversi approcci e/o tecniche. Le Tecniche e gli approcci piu' comunemente in uso per gli sviluppi software sono:
Tecniche Process Oriented : Tecniche Data Oriented : Tecniche Object Oriented ( OOA )

Tecniche Formal Specification ( FST )

Torna all'Indice Generale

2.2.4 Top Level Design Review
La review di validazione della fase di Top Level Design condotta secondo quanto espresso in precedenza produrra' una o piu' proposte di modifica da apportare all'Architettura o ai Requirements in dipendenza del livello di inconsistenza rilevato; andra' inoltre verificata la consistenza degli Integration Test con le specifiche funzionali del sistema.
Mentre in generale si fa' riferimento al sistema inteso nella sua globalits' (HW, FW, SW, etc. ) le fasi di Detail Design, Coding, Module Test, OEM Choiche, Acceptance e Reverse Engineering sono orientate ai singoli moduli, ed in particolare nel seguito si fara' riferimento a moduli software .

Torna all'Indice Generale

2.2.5 Detail Design
In questa fase si effettua una microanalisi del singolo modulo o sottosistema, producendo un documento di Detail Design che descrive la struttura del singolo modulo; inoltre vanno specificati i Module Test da eseguire dopo la fase di codifica.
La fase di Design deve essere vista come il cuore della software engineering, in questa fase viene costruita la qualita' del software e solo un buon design consentira' una corretta manutenzione, inoltre una corretta rappresentazione e' l'unica a consentire una valutazione della qualita' del software prima della codifica; pertanto verra' definito anche lo standard di produzione del codice, in termini di linguaggio e di stile di codifica ( ad es. assenza di goto, uso dei commenti, etc.), inoltre dovranno essere esplicitati in chiaro tutti i processi di astrazione procedurale e di astrazione dei dati onde evitare il mascheramento di conoscenza.
In funzione delle metodologie e tecniche adottate nella fase di Top Level Design verra' scelta il metodo e la relativa tecnica di rappresentazione per la fase di Detail Design.
In particolare risultano consolidate da tempo:
Structured Design

Procedural Design

Object Oriented Design

Torna all'Indice Generale

2.2.6 Detail Design Review
La review di validazione della fase di Detail Design condotta secondo quanto espresso in precedenza produrra' una o piu' proposte di modifica da apportare alla struttura del modulo; andra' inoltre verificata la consistenza dei tests prodotti con le specifiche funzionali dei moduli.

Torna all'Indice Generale

2.2.7 Coding
Si intende per Coding la fase di Stesura del Codice, e' evidente che non esiste un netto confine con la fase di Detail Design; infatti spingendo agli estremi la fase di microanalisi ed adottando un formalismo spinto e rigoroso si riesce ad avere un dossier in termini di statement, facilmente convertibile nel linguaggio scelto per la codifica; cio' ‚ tanto piu' vero quanto piu' sono evoluti gli strumenti di CASE adottati in questa fase, l'estemizzazione di questo concetto e' la Produzione Automatica del codice.

Torna all'Indice Generale

2.2.8 Code Review
L'obiettivo di questa fase e' la verifica del rispetto delle specifiche di Detail Design, degli standard di codifica e di commento definiti dalla fase di Detail Design stessa, mediante tecniche di Code Inspection o Walk Trough.
Una review condotta con queste tecniche consente di ridurre drasticamente i tempi di debugging.

Torna all'Indice Generale

2.2.9 Module Test
La fase di testing ‚ essenzialmente rivolta alla scoperta degli errori tramite l'esecuzione del software.
Si ritiene opportuno precisare che per software di media complessita' puo' essere arduo se non impossibile esercitare tutti i percorsi, per cui andranno effettuati dei test basati su tecniche statistiche atte ad esercitare tutti gli statement del codice.
Sono allo stato attuale consolidate le tecniche seguenti:

Il Module Test si conclude con l'emissione di un report con la lista dei tests eseguiti e dei relativi risultati e/o la check list delle funzioni esercitate.

Torna all'Indice Generale

2.2.10 O.E.M. Choice
Avendo deciso, in fase di Top Level Design, di esternizzare la produzione di uno o piu' sottosistemi, in questa succesiva fase viene operata la scelta del prodotto e/o fornitore che meglio soddisfi i requirements precedentemente definiti; di fatto trattasi di un'indagine di mercato del particolare settore in cui l'applicazione si colloca.

Torna all'Indice Generale

2.2.11 Acceptance
Per l'accettazione del package O.E.M. verranno attivate le seguenti azioni:

Tale fase produce un report di accettazione del package, oppure un report di rigetto con le ragioni per cui il package viene rifiutato.

Torna all'Indice Generale

2.2.12 Reverse Engineering
Il termine REVERSE ENGINEERING si confonde comunemente, ma non propriamente, con termini quali: il REUSE del software, la CONVERSION del software, il RECYCLING del software, la RESTRUCTURING del software, la REENGINEERING del software; ma si puo' affermare senza ombra di smentita che la reverse engineering le ingloba tutte.
Si definisce processo di REVERSE ENGINEERING  "quel processo in grado di ricostruire, a partire dal codice, la conoscenza in essa implementata ed il suo uso nel ciclo di vita del software ".
Un esempio tipico puo' essere quello di estrarre dal codice l'high level design e low level design.
Reverse Engineering si tratta di eseguire un ciclo di produzione a ritroso, partendo dal codice.
Analizzare il codice per estrarre da esso tutte le informazioni utili a ripercorrere all'indietro una o piu' fasi del ciclo di vita del software ricostruendo o costruendo in uno o piu' passi, auspicabilmente in modo automatico e con l'aiuto di analizzatori, tutti i documenti ed i dati relativi a tali fasi, verificandone la congruenza con quelli eventualmente gia' esistenti .

Il processo di Reverse Engineering del software ‚ finalizzato alla manutenzione, riuso, o alla produzione, in modo da assicurare:

L'obiettivo primario puo'comunque essere la produzione di nuovo software basato sulla conoscenza estratta da vecchio codice che altrimenti sarebbe perduta.
Pertanto il Reverse Engineering ‚ un insieme di metodologie, teorie, tecniche, tecnologie in grado di supportare: Il processo di Reverse Engineering e la correlazione con il processo di Forward Engineering e' sintetizzato in Fig. 3.
Al termine del processo di estrazione ed astrazione e' possibile individuare un delta (D), ovvero l'insieme di eventuali modifiche da apportare al package acquisito e/o a quanto gia' prodotto affinche' questi siano integrabili nell'intero sistema. L'impatto del D e' cosi' caratterizzabile: Il Processo di Reverse Engineering deve essere in grado di assicurare un ambiente per:

MAINT-DB PRODUCTION:
Inteso come sottosistema che mette a disposizione tecnologie (tools) per la generazione di DATA-BASE usando i prodotti delle fasi del ciclo di vita del software. Tale sottosistema includera' :
 

MAINTENANCE IMPLEMENTATION:
E' un sottosistema che mette a disposizione tecnologie capaci di supportare la realizzazione delle fasi del processo di manutenzione, partendo dalla definizione dei cambiamenti da fare alla realizzazione degli stessi .
Questi tools usano ed aggiornano il DB e sono in grado di supportare: POST-MAINTENANCE TESTING
E' un sottosistema che mette a disposizione strumenti per il test di regressione attraverso l'uso e l'aggiornamento dei dati disponibili nel DATA-BASE.

Deve consentire:
 

Onde formalizzare il processo di Reverse Engineering si assuma per ragionamenti succesivi il seguente paradigma :
GOALS / MODELS / TOOLS

Vengono di seguito analizzati i costituenti del paradigma.

GOALS  : e' la fase in cui si comincia l'analisi delle ragioni per le quali si vuole allestire un processo di RE, si analizza il ciclo di sviluppo e manutenzione del software nel quale i prodotti della RE saranno usati.
L'obiettivo fondamentale di questa fase e' quello di definire i documenti caratteristici che si vogliono produrre in funzione delle metodologie di progetto adottate .
Gli obiettivi di RE possono essere :

LE CARTE Dl STRUTTURA : del sistema software (secondo le rappresentazioni di Jackson, Yourdon-Costantaine,
                                                    Mayers, Yourdon-De Marco, Gane-Sarson, Ward-Mellor etc),
DATA FLOW DIAGRAMS,
SADT FLOW DIAGRAMS,
JSD FLOW DIAGRAMS,
JSP FLOW DIAGRAMS,
NASSY-SCHNEIDERMAN,
WARNIER-ORR,
PDL RAPPRESENTATION,
.....

MODELS : e' la fase in cui viene effettuata l'analisi dei documenti che devono essere prodotti, in questa fase devono essere definiti e scelti i modelli di rappresentazione del software che mettano a disposizione le informazioni necessarie per la produzione dei documenti definiti in precedenza, deve essere effettuata l'analisi di fattibilita' delle produzione di questi modelli dal codice mediante opportuni tools.
I Modelli per RE; possono essere:

ALGEBRIC EXPRESSION MODULE,
D-GRAPHS ( control, data),
NESTING TREES,
CALL GRAPHS,
VARIABLE PROCEDURE MATRIX,
CALL REFERENCE MATRIX,
SYNTACTIC MODELS,
SEMANTICS MODEL,
.....

T O O L S : e'  la fase in cui vengono definiti acquisiti e/o progettati e/o costruiti i tools stessi; questi sono caratterizzabili come:
INFORMATION EXTRACTOR TOOLS : i quali sono capaci di produrre rappresentazioni del software corrispondenti ai models identificati; ovviamente questi sono language dependent.
I Tools Extractor possono essere: STATIC ANALYZER, DYNAMIC ANALIZER.

INFORMATION ABSTRACTOR TOOLS : i quali sono capaci di produrre documenti richiesti a partire dai risultati prodotti dalla fase di information extraction; ovviamente sono language independent, ma dipendenti dal tipo di documento di progetto che si vuole produrre.
I Tools Abstractor possono essere:
ALGEBRIC REPRESENTATION MANIPULATORS,
DATA FLOW ANALYZER,
GRAPH GENERATOR AND ANALYZER,
GRAPHIC TOOLS,
.....

Una rappresentazione grafica del paradigma illustrato e'  riportata in FIG. 6
 

Torna all'Indice Generale

2.2.13 D's PHASES
Le D's phases individuano i successivi step nello sviluppo dei delta quali sopra definiti; per queste fasi e' del tutto valido quanto gia' detto per il ramo individuato per lo sviluppo di SW proprietry.

Torna all'Indice Generale


2.2.14 Integration
In questa fase si provvede ad aggregare i vari moduli SW, FW e HW onde verificare il corretto funzionamento delle interfacce e dei moduli stessi nel contesto dell'architettura realizzata.
Una corretta attivita' di integrazione andra' basata su una esatta definizione dell'ambiente di test in termini di componenti HW, FW, SW, test specification, dati e strumenti di prova.
L'attivita' di integrazione, svolta sulla base dei tests approntati nella fase di Top Level Design, e' tesa all' individuazione delle cause di eventuali malfunzionamenti e relative soluzioni proponibili; il risultato di tali attivita' sara' concretizzato con l'emissione di: Per le finalita' dell'attivita' di integrazione, come sopra definite, l'output di questa fase provoca un riciclo sul Detail Design dei moduli.

Torna all'Indice Generale

2.2.15 System Test
L'obiettivo delle attivita' svolte per il System Test ‚ quello di verificare tutte le funzionalita' cosi come specificate dai System Requirements e secondo le modalita' indicate nelle System Test Specifications.
L'oggetto delle attivita' di System Test e' la Release ovvero l'insieme dei componenti HW, FW, SW, documentazione, System Requirements e tutto  quanto concorre alla completa definizione del sistema cosi come questo verra' poi rilasciato agli enti esterni a quelli di progetto.
Il risultato finale di questa fase sara' la validazione della release o il rilevamento di malfunzionamenti; in tal caso se ne analizzeranno le cause e le possibili soluzioni; il tutto andra' infine formalizzato con dei Fault Reports & Change Proposal che serviranno per il riciclo del Top Level Design .

Torna all'Indice Generale

2.2.16 Maintenance
In quest'ultima fase del ciclo di vita vengono gestiti tutti quegli interventi sul prodotto successivi alla fine dello sviluppo.
I tipi di interventi generalmente eseguiti sono

In generale l'attivita' di manutenzione consistera' nel ripercorrere il ciclo di vita del software a partire da una fase che sara' funzione della natura delle modifiche da effettuare; il risultato finale sara' quindi una revisione sia del codice che della documentazione relativa.

Le attivita' che si scatenano sono funzioni dello stimolo che la ha motivata, in particolare l'insorgere di stimoli interni porta ad una revisione del prodotto partendo dalle fasi piu' a valle via via verso l'alto fino all'individuazione del punto critico che ha indotto l'errore o l'origine della modifica, a partire da tale punto critico si ripercorrono tutte le fasi previste operando gli opportuni interventi. per quanto riguarda invece le richieste di manutenzione motivate da stimoli esterni si dovranno ripercorrere in toto tutte le fasi del ciclo di sviluppo, apportando in ogni documento le modifiche che consentano di ottenere un prodotto rispondente alle nuove esigenze.

Torna all'Indice Generale

3 Funzioni di Supporto al Sw Engineering
Da quanto fin qui esposto si evince che anche per progetti medio piccoli ci si ritrova con l'onere di gestire, oltre che produrre, una grossa mole di informazioni; in particolare vogliamo evidenziare due aspetti di questo problema: la memorizzazione di tutto quanto prodotto durante il processo di sviluppo (sources e documentazione), al fine di rendere riproducibile e riusabile il tutto;
la configurazione dei prodotti intermedi e finali, ovvero la definizione esatta delle preÄreleases e releases in termini di system requirements, specifiche funzionali, HW, FW, SW ecc.
Va notato che sia l'integrazione che il system test operano sull'insieme di oggetti che in generale sono prodotti da gruppi diversi e che hanno subito una certa evoluzione nelle fasi precedenti, pertanto in entrambi i casi si ha bisogno di un ambiente definito in modo puntuale ovvero controllato; va infine ricordato che anche per la gestione del progetto occorre una visione di tutto il processo di sviluppo e di quanto da esso prodotto.
Per la soluzione di tali problemi occorre quindi individuare le funzioni di Source Control e Configuration Control in modo chiaro e indipendentemente dalla loro allocazione in team specifici o "embedded" negli strumenti di sviluppo.

Torna all'Indice Generale

4 Finalita', Specifiche ed Effort Realizzativo Dei Tools C.A.S.E.
Nell'ottica della gestione di progetto ci si pone il problema di aumentare la qualita' e la produttivita':

Al fine di raggiungere gli obiettivi su esposti occorre dotarsi di strumenti che automatizzino alcune operazioni o addirittura una o piu' fasi, se non tutte le fasi, del ciclo di vita del software, ovvero di strumenti C.A.S.E. .
Un modello di riferimento per la definizione delle specifiche di un ambiente CASE ‚ il seguente:
Architettura dell' ambiente: mainframe e terminali oppure workstations e database server collegati in LAN;
Piattaforma Hardware: potenza di calcolo, memorie di massa,
tipo di terminali, capacita' di networking, prezzo, ecc.;
Sistema operativo: Unix,VMS ecc.;
Servizi per la portabilita': tools/packages di supporto per interfacciare in modo semplice il sistema operativo (X-Windows, SQL, ecc.);
Integration Framework: strumenti di supporto per la integrazione dei vari tool CASE, intesa come integrazione dei dati, interfacce e dei tools che coprono le varie fasi del ciclo di vita;
CASE tools.
In particolare la strategia di integrazione ‚ basata sulla disponibilita' di un repository, ovvero di un database, comune ai vari tools, in cui depositare gli outputs delle varie fasi del ciclo di vita.
Un tool CASE deve essere caratterizzato da una interfaccia uomo macchina friendly e, nel caso di piu' tools che coprano le varie fasi, le interfacce devono essere quanto pi— omogenee; ad esempio va affermandosi un tipo di interfaccia basata sull'uso di pop-up menus, windows, mouse, icone con grafica auto esplicativa.
Gli enti di standardizzazione stanno emettendo delle raccomandazioni cui far riferimento per lo sviluppo di tools CASE per i vari ambiti di applicazioni SW, si ricordano:
IEEE-CS Task force on professional tools Electronic design interchange format (EDIF), Atherton/DEC Tool Integration Standard (ATIS), Information Resource Dictionary Standard (IRTS) Common ADA Interface Standard (CAIS) Portable Common Tool Environment (PCTE)
Va evidenziato che le aziende devono produrre uno sforzo per l'adozione di strategie C.A.S.E., sia in termini di strumentazioni HW e SW sia in termini di risorse umane, che vanno impegnate per opportuni training su metodologie, tecniche, e strumenti affinch‚ si possa ottenere il massimo dell'efficacia e dell'efficienza.

Torna all'Indice Generale

5 Considerazioni
E' doveroso evidenziare che allo stato attuale non esiste un tool CASE in grado di rispondere a tutte le esigenze, project management, system analisys, re-engineering, ecc., ma esistono dei tools specifici che coprono al meglio una o pi— fasi, ed i costruttori a livello mondiale sono orientati alla realizzazione di sistemi di integrazione (IPSE) per la fornitura di ambienti di sviluppo completi sia in termini di interscambio dei dati, di gestione del cambio delle versioni e dei controlli. Va notato anche un forte trend verso l'utilizzo di metodologie di Intelligenza Artificiale in grado di offrire un'assistenza metodologica nelle fasi di Analisi e Design, prototipazione, e nel riuso intelligente della conoscenza implementata
E' evidente che oltre allo sforzo dei costruttori di tools ‚ necessario uno sforzo delle singole aziende per il rinnovo delle tecniche di produzione SW e per il conseguente addestramento; alcune statistiche indicano i seguenti dati sul periodo medio di training:
2/3 gg per introduzione di carattere generale,
3/5 gg sulle tecniche di analisi,
3/5 gg sulle tecniche di design;
il fruitore di questi corsi dovra' avere una buona conoscenza degli approcci metodologici, di linguaggi di programmazione di architetture di calcolatori; occorre infine una buona disposizione a diffondere le nuove conoscenze acquisite.

Torna all'Indice Generale

6 Bibliografia
Pressman, R. S., Software Engineering: A Practitioner's Approach, 2nd Edition McGrawÄHill 1987
Software Engineering Handbook, McGrawÄHill 1986
Sommerville, I., Software Engineering 3rd Edition Addison Wesley 1 g89
De Marco, T. Structured Analysis and Systems Specification, PrenticeÄHall 1 979
McMenamin, S and J. Palmer, Essential Systems Analysis, Yourdon Press 1 9 84
Ross, R.G. Entity Modeling: Techniques and Applications, Data Research Group Inc. Boston 1988
Yourdon E., Modern Structured Analysis, PrenticeÄHall 1 989
Linger, R., H. Mills and B. Witt, Structured Programming, AddisonÄWesley 1979
Marca, D.A. and C.L. McGowan, SADT, McGrawÄHill 1988
Martin, J. and C. McClure, Diagramming Techniques for Analysts and Programmers, PrenticeÄHall, 1985
Yourdon, E. and L. Costantine, Structured Design, PrenticeÄHall 1979
Shneiderman, B., Designing the User Interface, AddisonÄWesley 1987
Mayer, B. ObjectÄOriented Software Construction, PrenticeÄHall 1988
Hatley, D.J. and 1. A. Pirbhai, Strategies for Real Time Systems Specification, Dover House 1987
Kaisler, S.H., The Design of Operating Systems for Small Computer Systems, Wiley, 1983
Ward, P.T., and S.J. Mellor, Structured Development for Real Time, 3 volumes, Yourdon Press 1986
Beizer, B., Software Testing Techniques, Van NostrandÄReinhold, 1983
Freedman, D. and G. Weinberg, Handbook of Walktroughs, Inspections and Technical Reviews, 3rd edition, Little, Brown & Co. 1982
Musa, J.D., A. Iannino and K. Okumoto, Sofware Reliability, McGrawÄHill 1 987
Myers G., The Art of Software Testing, Wiley 1979
Schulmeyer, C.D. and J.l. McManus, Handbook of Software Quality Assurance, Van Nostrand 1987
Periodici e Riviste Specializzate
IEEE Transaction on Software Egineering
Computer (IEEE Computer Society)
IEEE Software (IEEE Computer Society)
Communications of the ACM
ACM Sigsoft Notes
CASE Outlook (mensile)
Computerworld (settimanale)
Software News (mensile)
Datamation (mensile)
Computer Decision (mensile)
BYTE (mensile)

Torna all'Indice Generale

Ritorno all'Indice SW Enginnering Ritorno alla Home Page
Le informazioni, prodotti, marchi referenziate nelle pagine seguenti rimangono di proprieta' dei rispettivi produttori, a norma delle leggi internazionali sui © copyright © non e' consentito l'uso delle stesse a scopo di lucro e/o la riproduzione senza consenso scritto
All info trademarks or product names mentioned herein are the property of their respective owners
 
Informazioni, chiarimenti, discussioni at Contact point Giovanni.Secondulfo@inwind.it  
This page hosted by GeoCities
 
  1