|
|
|||||||||||||||||||||||||||||||||||||||||
|
METODOLOGIE E STRUMENTI ESSENZIALI PER IL MIGLIORAMENTO DEI PROCESSI DI PROGETTAZIONE | |||||||||||||||||||||||||||||||||||||||||
| STANDARD DI QUALITÀ: LA (R)EVOLUZIONE NECESSARIA | Durante l'ultimo quarto del Ventesimo Secolo, il mondo industriale ha effettuato cospicui investimenti in qualità, prevalentemente sui processi produttivi. Il risultato di tali investimenti è molto controverso, soprattutto a causa della complicazione, della ridondanza e della eccessiva proliferazione degli standard, differenti nei titoli, ma molto simili nei contenuti. Nella seconda metà degli anni 90, e nella prima decade del Ventunesimo Secolo, assistiamo ad un vero cambio di paradigma, e diversi concetti nuovi ed evolutivi hanno visto la luce. Ed, in particolare, l'attenzione si è sempre più focalizzata sui processi di progettazione, oltre che sui processi produttivi. |
||||||||||||||||||||||||||||||||||||||||
Il concetto di maturità (Capability Maturity Model, SEI, Massachusetts) è più appropriato, per un migliore approccio alla gestione del ciclo di vita del progetto. | |||||||||||||||||||||||||||||||||||||||||
|
Qualità meccanica vs. qualità elettronica - Gli standard metodologici sono nati in era industriale, per l'industria meccanica, e sono orientati a processi di produzione serializzata. L'elettronica e l'informatica hanno portato a gradi di libertà e flessibilità enormemente maggiori. Il punto critico si è spostato dai processi produttivi ai processi di progettazione. Qualità pubblica e qualità privata - Sviluppate principalmente nel settore pubblico (Aerospazio e Difesa) le metodologie sono care e non efficienti. Gli standard come prodotto di mercato - E' nato un vero e proprio mercato degli standard, molti standard simili sono stati immessi sul mercato, aumentando la confusione. Questo è concettualmente contrario alla stessa filosofia base degli standard di qualità, che prescrivono l'unicità di ogni requisito, fino a prova contraria. Un ritardo culturale nell'uso di strumenti a supporto delle metodologie - Le metodologie non sono sostenibili, in mancanza di appropriati strumenti software. |
|||||||||||||||||||||||||||||||||||||||||
|
Alcuni standard recenti sono in contro-corrente, riguardo alla proliferazione continua di standard:
| |||||||||||||||||||||||||||||||||||||||||
Le capacità più prioritarie, in questo nuovo scenario, comprendono:
| |||||||||||||||||||||||||||||||||||||||||
| Gli strumenti software, di supporto alle metodologie essenziale ad elevata redditività, assumono una grande importanza per gli obiettivi delineati, per aiutare i gruppi di progetto a crescere in maturità. | |||||||||||||||||||||||||||||||||||||||||
| LA NOSTRA PROPOSTA |
Noi proponiamo di gestire il ciclo di vita dell'intero progetto mediante una suite di strumenti software, in modo molto efficiente e riducendo i costi. Come? Di seguito una breve presentazione dei punti principali. | ||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||
|
Il Project Life Cycle classico, sebbene teoricamente corretto, è applicato pienamente solo in pochi casi: in progetti normali, la documentazione di requisiti e di disegno del sistema diventa rapidamente troppo pesante per seguire il progetto alla velocità richiesta. La necessità di modificare i requisiti utente si verifica dopo ogni milestone di progetto (design review, test in simulazione in laboratorio, test integrati, collaudo di accettazione). Una corretta gestione delle modifiche richiederebbe ogni volta una revisione della documentazione. Ma le milestone di consegna/fatturazione spesso costringono a rimandare l'aggiornamento della documentazione. Il risultato è che la documentazione spesso rimane indietro, rispetto al sistema sviluppato: la documentazione è costata molto, ma è inutile per la successiva manutenzione del prodotto. Molte aziende non hanno mai veramente effettuato la transizione dal modello waterfall a modelli di tipo life cycle. | |||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||
|
Il Reiterative Project Life Cycle non è diverso, in linea di principio, dal Project Life Cycle classico: le fasi sono le stesse, così come i documenti previsti e le attività. L'unica differenza è che il RPLC prevede esplicitamente di riciclare sulla fase di disegno-prototipazione, fino alla piena soddisfazione del cliente. | |||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||
|
L'esperienza, e le metodologie standard più avanzate (es. il Capability Maturity Model), hanno dimostrato che lavorare secondo modelli reiterativi è possibile solo se si utilizzano strumenti software adeguati. Andromeda possiede una notevole esperienza nel campo dei sistemi di controllo di processo, nei settori aerospaziale ed infrastrutturale, per sistemi di supporto alla vita umana, dove l'affidabilità e la sicurezza sono requisiti primari. PTESY è una suite di strumenti per gestire l'intero ciclo di vita del progetto, in modo reiterativo, su database relazionale: dalla definizione dei requisiti, alla definizione delle procedure di test, all'esecuzione dei test e annotazione dei problemi riscontrati, fino al collaudo finale di accettazione, tracciando tutti i livelli intermedi. Il sistema produce una matrice di tracciabilità totale on-line, e (ri)produce automaticamente tutta la documentaziona, già formattata in MSWord. Grazie alla potenza del database relazionale di quarta generazione, tale sistema permette di analizzare e gestire le modifiche con estrema facilità e rapidità, mantenendo aggiornata la documentazione di progetto e le matrici di tracciabilità, con grande efficienza e risparmio di tempo, fino alla fine del progetto.
PTESY produce automaticamente i seguenti documenti, già formattati in MSWord: | |||||||||||||||||||||||||||||||||||||||||
|
REQUISITI |
Documenti dei Requisiti, matrici di tracciabilità Requisiti Figli - Requisiti Padri; Requisiti Orfani e Requisiti senza figli. | ||||||||||||||||||||||||||||||||||||||||
|
RISKS DOCUMENT |
Documento dei Rischi associati ai requisiti. Azioni di mitigazione, valutazione prima e dopo la mitigazione. | ||||||||||||||||||||||||||||||||||||||||
|
PROCEDURE DI TEST |
Documenti di Procedure di Test complete, Matrici di Tracciabilità Test Case - Requisiti coperti, Requisiti non coperti da alcun Test Case. | ||||||||||||||||||||||||||||||||||||||||
|
PROBLEMI |
Report dei Problemi (in forma compatta ed estesa); Report Note ed Eventi; tracciamento di Problemi verso Test Case e Requisiti violati. | ||||||||||||||||||||||||||||||||||||||||
|
TEST REPORT |
Composti dalle Procedure di Test compilate, le note di esecuzione, il rapporto dei problemi riscontrati, sommario dei test passati/non passati. | ||||||||||||||||||||||||||||||||||||||||
|
DOCUMENTI |
Albero della documentazione, Tabelle dei Documenti Applicabili, Tabelle dei Documenti Riferiti. | ||||||||||||||||||||||||||||||||||||||||
|
SIGNALI DI I/O |
Liste di I/O e liste di morsettiere | ||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||
|
L'ARCHITETTURA CLIENT-SERVER |
| ||||||||||||||||||||||||||||||||||||||||
|
GLI
STRUMENTI CHE COMPONGONO PTESY |
| ||||||||||||||||||||||||||||||||||||||||
|
PTESY VS. ALTRI PRODOTTI COMMERCIALI |
| ||||||||||||||||||||||||||||||||||||||||
| STANDARD: | PTESY è conforme ai seguenti standard internazionali: ESA ECSS (ed il precedente PSS05) ISO12207 (ed il precedente MIL498), ISO9001, CMMi livello 3, ISO27001, ISO17779. |
||||||||||||||||||||||||||||||||||||||||
| CONTATTI: | Punti
di vendita & consulenza
scrivete un'email ad Adriano Autino |
||||||||||||||||||||||||||||||||||||||||