<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:wx="http://ilps.science.uva.nl/WikiXML/wx" xml:lang="it" lang="it">
<head>
<title>Progettazione (ingegneria del software)</title>
<meta name="wx_namespace" content="0"/>
<meta name="wx_pagename" content="Progettazione_(ingegneria_del_software)"/>
<meta name="wx_page_id" content="13191"/>
</head>
<body>
<div id="wx_article">
<wx:section level="1" title="Progettazione (ingegneria del software)" id="wxsec1"><h1 class="pagetitle" id="wx1">Progettazione (ingegneria del software)</h1>

<p id="wx2">In <a href="/wit/Ingegneria_del_software" title="Ingegneria del software" wx:linktype="known" wx:pagename="Ingegneria_del_software" wx:page_id="64993" id="wx3">ingegneria del software</a>, la <b id="wx4">progettazione</b> (talvolta detta anche <b id="wx5">progetto</b> o <b id="wx6">disegno</b>, dall'inglese <i id="wx7">design</i>) è una fase del <a href="/wit/Ciclo_di_vita_del_software" title="Ciclo di vita del software" wx:linktype="known" wx:pagename="Ciclo_di_vita_del_software" wx:page_id="74260" id="wx8">ciclo di vita del software</a>. Sulla base della <a href="/wit/Specifica_dei_requisiti" title="Specifica dei requisiti" wx:linktype="known" wx:pagename="Specifica_dei_requisiti" wx:page_id="593564" id="wx9">specifica dei requisiti</a> prodotta dall'<a href="/wit/Analisi_dei_requisiti" title="Analisi dei requisiti" wx:linktype="known" wx:pagename="Analisi_dei_requisiti" wx:page_id="106963" id="wx10">analisi</a>, il progetto definisce <i id="wx11">come</i> tali requisiti saranno soddisfatti, entrando nel merito della struttura che dovrà essere data al sistema <a href="/wit/Software" title="Software" wx:linktype="known" wx:pagename="Software" wx:page_id="3889" id="wx12">software</a> che deve essere realizzato.</p>

<p id="wx13">La progettazione rimane comunque una fase distinta dalla <a href="/wit/Programmazione" title="Programmazione" wx:linktype="known" wx:pagename="Programmazione" wx:page_id="791962" id="wx14">programmazione</a> o codifica, che corrisponde alla traduzione in un particolare <a href="/wit/Linguaggio_di_programmazione" title="Linguaggio di programmazione" wx:linktype="known" wx:pagename="Linguaggio_di_programmazione" wx:page_id="2573" id="wx15">linguaggio di programmazione</a> delle decisioni prese in sede di progettazione.</p>

<p id="wx16">Le distinzioni fra le attività fin qui menzionate non sono sempre chiare come vorrebbero le teorie classiche dell'ingegneria del software. La progettazione, in particolare, può descrivere il funzionamento interno di un sistema a diversi livelli di dettaglio, ciascuno dei quali si colloca in una posizione intermedia fra analisi e codifica.</p>

<p id="wx17">Normalmente si intende con <i id="wx18">progettazione dell'architettura</i> (o progettazione <i id="wx19">architetturale</i>) la progettazione "ad altissimo livello", in cui si definisce solo la struttura complessiva del sistema in termini dei principali <a href="/wit/Modulo_software" class="new" title="Modulo software" wx:linktype="unknown" wx:pagename="Modulo_software" id="wx20">moduli</a> di cui esso è composto e delle relazioni macroscopiche fra di essi. A questo livello di progettazione appartengono formule come <a href="/wit/Client-server" title="Client-server" wx:linktype="known" wx:pagename="Client-server" wx:page_id="14987" id="wx21">client-server</a> o <a href="/wit/Three-tier" class="new" title="Three-tier" wx:linktype="unknown" wx:pagename="Three-tier" id="wx22">three-tier</a>, o più in generale decisioni sull'uso di particolari <a href="/wit/Architettura_hardware" class="new" title="Architettura hardware" wx:linktype="unknown" wx:pagename="Architettura_hardware" id="wx23">architetture hardware</a>, <a href="/wit/Sistema_operativo" title="Sistema operativo" wx:linktype="known" wx:pagename="Sistema_operativo" wx:page_id="3917" id="wx24">sistemi operativi</a>, <a href="/wit/DBMS" title="DBMS" wx:linktype="known" wx:pagename="DBMS" wx:page_id="50031" id="wx25">DBMS</a>, <a href="/wit/Protocollo_di_rete" title="Protocollo di rete" wx:linktype="known" wx:pagename="Protocollo_di_rete" wx:page_id="27403" id="wx26">protocolli di rete</a>, e così via.</p>

<p id="wx27">Una livello intermedio di dettaglio definisce ancora la scomposizione del sistema in moduli, ma questa volta con riferimento più o meno esplicito alle modalità di scomposizione offerte dal particolare <a href="/wit/Linguaggio_di_programmazione" title="Linguaggio di programmazione" wx:linktype="known" wx:pagename="Linguaggio_di_programmazione" wx:page_id="2573" id="wx28">linguaggio di programmazione</a> con cui avverrà lo sviluppo; per esempio, in una progettazione condotta con tecnologie <a href="/wit/Programmazione_orientata_agli_oggetti" title="Programmazione orientata agli oggetti" wx:linktype="known" wx:pagename="Programmazione_orientata_agli_oggetti" wx:page_id="23026" id="wx29">a oggetti</a>, il progetto potrebbe descrivere il sistema in termini delle principali <a href="/wit/Classe_%28informatica%29" title="Classe (informatica)" wx:linktype="known" wx:pagename="Classe_(informatica)" wx:page_id="67016" id="wx30">classi</a> e delle loro interrelazioni.</p>

<p id="wx31">Il <i id="wx32">progetto di dettaglio</i>, infine, rappresenta una descrizione del sistema <i id="wx33">molto vicina</i> alla codifica, ovvero che la vincola in maniera sostanziale (per esempio, descrivendo non solo le classi in astratto ma anche i loro attributi e metodi, con relativi tipi e "<a href="/wit/Firma_%28programmazione%29" title="Firma (programmazione)" wx:linktype="known" wx:pagename="Firma_(programmazione)" wx:page_id="109033" id="wx34">firma</a>").</p>

<p id="wx35">A causa della natura "impalpabile" del software, e a seconda degli strumenti che si utilizzano nel processo, il confine fra progettazione e codifica può essere anche praticamente impossibile da identificare. Per esempio, alcuni strumenti <a href="/wit/Computer_Aided_Software_Engineering" title="Computer Aided Software Engineering" wx:linktype="known" wx:pagename="Computer_Aided_Software_Engineering" wx:page_id="299751" id="wx36">CASE</a> sono in grado di <a href="/wit/Generazione_automatica_del_codice" class="new" title="Generazione automatica del codice" wx:linktype="unknown" wx:pagename="Generazione_automatica_del_codice" id="wx37">generare codice</a> a partire da diagrammi <a href="/wit/Unified_Modeling_Language" title="Unified Modeling Language" wx:linktype="known" wx:pagename="Unified_Modeling_Language" wx:page_id="77450" id="wx38">UML</a> che descrivano graficamente la struttura di un sistema software.</p>

<a id="Cenni_Storici" name="Cenni_Storici"/>
<wx:section level="2" title="Cenni Storici" id="wxsec2"><h2 id="wx39">Cenni Storici</h2>

<p id="wx40">L'esigenza di comprendere le difficoltà del realizzare software nasce alla fine degli anni '60 con la consapevolezza che una base di buona programmazione non voleva dire avere a disposizione dei buoni sistemi.</p>

<p id="wx41">Lo sviluppo si ebbe negli anni '50 e '60 quando il problema era l'attività di programmazione tramite altri studi riferiti a algoritmi, strutture Dati, programmazione Strutturata, linguaggi di Programmazione. La programmazione veniva vista come come "mettere assieme" una sequenza d'istruzioni. Negli anni anni '50 fece la sua comparsa <a href="/wit/Assembler" title="Assembler" wx:linktype="known" wx:pagename="Assembler" wx:page_id="348" id="wx42">Assembler</a>, linguaggio a basso livello, e alla fine Anni '50 comparvero i primi linguaggi di "alto" livello (<a href="/wit/Cobol" title="Cobol" wx:linktype="known" wx:pagename="Cobol" wx:page_id="12867" id="wx43">Cobol</a>, <a href="/wit/Fortran" title="Fortran" wx:linktype="known" wx:pagename="Fortran" wx:page_id="1897" id="wx44">Fortran</a>). In questo periodo la programmazione si basava sull'abilità dei programmatori, sullo sviluppo di applicazioni di dimensioni piccole o medie (calcolo centralizzato) e sulla metodologia "prova e correggi" ("code and fix"). Ma con la crescita della complessità, la comparsa delle reti e applicazioni client-server si avverte la necessità di una metodologia per guidare il processo di sviluppo.</p>

<p id="wx45">A questo punto si assistette all'introduzione dei nuovi linguaggi che rese più semplice la programmazione e la diffusione dei pc permise di far nascere la figura professionale di programmatore, non come utente finale dell'applicazione, ma come realizzatore dell'applicazione.</p>

<p id="wx46">Verso la fine degli anni '60 nacquero i primi progetti software a fini commerciali, ma le buone tecniche di programmazione acquisite fino a quei tempi non bastavano per l'evoluzione di un software potente. I progetti erano più costosi del previsto e sempre in ritardo con i tempi di sviluppo. In una conferenza del 1968 si inizio a parlare del Software Crisis dove si sottolinea che il problema non era più "scrivere sequenze d'istruzioni" ma era comunicare con le persone coinvolte nello sviluppo. Le cause della crisi sono da rapportare al cambio dei requisiti durante lo sviluppo, ai cambiamento che coinvolgo tutto il sistema, al turn over del personale.</p>

<p id="wx47">Dalla conferenza emerse un nuovo scenario, che prevedeva un approccio diverso allo sviluppo, con la conseguente introduzione di Management, Organizzazione, Teorie e Tecniche, Strumenti e Metodologie appropriate. Si iniziò a parlare di <a href="/wit/Ciclo_di_vita_del_software" title="Ciclo di vita del software" wx:linktype="known" wx:pagename="Ciclo_di_vita_del_software" wx:page_id="74260" id="wx48">ciclo di vita del software</a>, inteso come descrizione delle delle attività che portano alla realizzazione e alla gestione di un sistema.</p>

<p id="wx49">Nel 1984 <a href="/wit/James_Martin" title="James Martin" wx:linktype="known" wx:pagename="James_Martin" wx:page_id="794926" id="wx50">James Martin</a> esperto di <a href="/wit/Software_engineering" title="Software engineering" wx:linktype="known" wx:pagename="Software_engineering" wx:page_id="340479" id="wx51">software engineering</a> pubblica "An Information Systems MANIFESTO" (sic), un vero e proprio provocatorio manifesto destinato a scuotere la letargia e scarsa propensione del management di allora a vedere rischi e opportunità nella tecnologia informatica. Il <a href="/wit/Leitmotiv" title="Leitmotiv" wx:linktype="known" wx:pagename="Leitmotiv" wx:page_id="1072490" id="wx52">leitmotiv</a> dell'opera, si può riassumere ne "<i id="wx53">l'informatica non è un dettaglio tecnico demandato agli specialisti EDP, ma una risorsa strategica che merita l'attenzione continua dell'alta direzione</i>". Nel contempo James Martin pone le basi di nuove tecniche di sviluppo quali il <a href="/wit/Computer_Aided_Software_Engineering" title="Computer Aided Software Engineering" wx:linktype="known" wx:pagename="Computer_Aided_Software_Engineering" wx:page_id="299751" id="wx54">CASE</a> e il <a href="/wit/Rapid_Application_Development" title="Rapid Application Development" wx:linktype="known" wx:pagename="Rapid_Application_Development" wx:page_id="1150051" id="wx55">RAD</a>.</p>

<p id="wx56">Nel 1994 la "Standish Group International", nell’ambito di un progetto di ricerca, ha cercato di dare delle risposte nell’ambito dei fallimenti dei progetti software.</p>

<p id="wx57">I progetti sono stati classificati in tre categorie distinte:</p>

<ol id="wx58">
<li id="wx59">
<p id="wx60">Progetti di successo: completati nei tempi stabiliti e senza sforare il budget stabilito e con tutte le caratteristiche e funzioni stabilite nelle specifiche iniziali.</p>
</li>

<li id="wx61">
<p id="wx62">Progetti in ritardo: il progetto è completato ed operativo ma ha richiesto più tempo e denaro rispetto a quanto stimato, ed offre un minor numero di funzioni</p>
</li>

<li id="wx63">
<p id="wx64">Progetti cancellati: il progetto è stato cancellato durante il ciclo di sviluppo, prima di essere terminato.</p>
</li>
</ol>

<p id="wx65">Sebbene differenti progetti falliscano in modi differenti, la causa principale per la maggior parte dei fallimenti nello sviluppo del software risulta essere l’inadeguatezza della metodologia.</p>

<p id="wx66">Altre cause risultano essere:</p>

<ul id="wx67">
<li id="wx68">
<p id="wx69">una eccessiva burocratizzazione dello sviluppo</p>
</li>

<li id="wx70">
<p id="wx71">difficoltà nel tenere conto dei cambiamento nei requisiti</p>
</li>

<li id="wx72">
<p id="wx73">software difficile da mantenere o da fare evolvere</p>
</li>

<li id="wx74">
<p id="wx75">scoperta tardiva dei gravi errori di progetto</p>
</li>

<li id="wx76">
<p id="wx77">test insufficienti</p>
</li>

<li id="wx78">
<p id="wx79">scarsa qualità del software</p>
</li>

<li id="wx80">
<p id="wx81">prestazioni inaccettabili del software</p>
</li>
</ul>

<p id="wx82">Per questo motivo vennero introdotte varie tipologie di sviluppo del software che servirono a migliorare i limiti riscontrati.</p>
</wx:section></wx:section></div>
<div id="wx_categorylinks">
<a href="/wit/index.php?title=Speciale:Categories&amp;article=Progettazione_%28ingegneria_del_software%29" title="Speciale:Categories" wx:linktype="known" wx:pagename="Speciale:Categories" id="wx83">Categoria</a>: <span dir="ltr" id="wx84"><a href="/wit/Categoria:Attivit%C3%A0_di_sviluppo" title="Categoria:Attività di sviluppo" wx:linktype="known" wx:pagename="Categoria:Attività_di_sviluppo" wx:page_id="1015783" id="wx85">Attività di sviluppo</a></span></div>
<div id="wx_languagelinks">
</div>
</body>
</html>
