Perché un processo di sviluppo iterativo è meglio per il Cliente?

Tradizionalmente lo sviluppo del software viene suddiviso nelle seguenti fasi:

  1. Elicitazione dei requisiti;
  2. Stima di tempi e costi;
  3. Sviluppo;
  4. Rilascio;
  5. Supporto post-rilascio;

Questo approccio, nonstante sia ancora quello più utilizzato, soffre di evidenti limiti, primo fra tutti il fatto che la stima di tempi e costi avviene nelle prime fasi e resta immutata per tutta la fase dello sviluppo.

Esistono vari motivi per cui questo è un limite e dipendono tutti dalla discrepanza tra teoria e pratica:

  • nella realtà non è vero che si possono elicitare tutti i requisiti all’inizio del progetto;
  • nella realtà non è vero che i requisiti elicitati nella fase iniziale restano immutati fino alla fine dello sviluppo;

Queste considerazioni determinano di fatto un errore di valutazione per quanto riguarda la stima di tempi e costi.

L’errore che si può commettere in questo frangente è direttamente proporzionale alle dimensioni del software che si vuole realizzare.

Sottostimare la realizzazione di un software non sarebbe di per sé così grave se non venisse accompagnato dalla storica riluttanza dei committenti a non voler pagare le funzionalità non previste nelle fasi iniziali o addirittura non presenti nel contratto di sviluppo sottoscritto e anzi a pretenderle forti del fatto che pagheranno in un momento futuro.

Stanti le cose, molti sviluppatori cercano di porre rimedio a questo scenario con pagamenti anticipati di quote del progetto e gonfiando le stime iniziali.

Le possibili conseguenze di questa “soluzione” possono essere:

  • il rifiuto del cliente a causa di tempi e cifre fuori mercato;
  • la sovrastima del progetto: il cliente pagherà di più di quello che sarebbe stato il giusto.

In sintesi, utilizzando questo tipo di approccio, in 2 casi su 3 una delle due parti reseterà insoddisfatta: lo sviluppatore se ha sottostimato (caso più probabile), il committente se lo sviluppatore ha sovrastimato.

Consapevoli di tutto ciò, su progetti di grandi dimensioni, è più saggio accettare l’impossibilità di effettuare stime ragionevolmente precise e cambiare tipo di approccio.

Lo sviluppo a iterazioni non soffre di questi limiti poiché non è necessario elicitare dettagliatamente i requisiti e non è necessario effettuare una stima a priori.

Secondo questo metodo infatti le uniche cose che si definiscono sono:

  • la durata delle iterazioni: in genere un mese;
  • il costo di ogni iterazione;

In questo modo il Cliente ha i seguenti vantaggi:

  • non pagherà più del necessario;
  • avrà un feedback sullo stato di avanzamento dei lavori al completamento di ogni iterazione in modo da non avere sorprese e poter correggere la rotta man mano che si procede;
  • avrà la massima libertà, in qualsiasi momento, di chiedere modifiche alle funzionalità già implementate o addirittura di richiedere nuove funzionalità inizialmente non previste;
  • potrà decidere di sospendere o interrompere lo sviluppo quando vuole.

Abbinare lo sviluppo di software su misura alla modalità di sviluppo a iterazioni è il modo più efficace ed efficiente di ottenere gli strumenti giusti per far crescere la propria impresa.

Problematiche ricorrenti nello sviluppo di webapp 2/3: encoding

Turmbau zu Babel - Pieter Bruegel 1563

Dopo la gestione dell’escaping vediamo la gestione dell’encoding.

Questo problema ha origini storiche e dipende dal fatto che, agli albori della computazione, quando le risorse erano limitate, si preferì individuare un sott’insieme di tutti i caratteri noti per poter dialogare con un computer, questo sott’insieme coincideva sostanzialmente con i caratteri dell’alfabeto latino i numeri e qualche altro carattere di utilità.

Questo insieme di caratteri o charset, noto come ASCII è stato il charset di riferimento fino all’avvento di internet e all’aumento delle risorse a disposizione.

Oggi infatti ad una webapp multilingua viene richiesta la corretta gestione di un charset molto più esteso dell’ASCII, di un charset che contenga più o meno tutti gli alfabeti della terra: latino, arabo, ebraico, cinese, giapponese, ecc.

Questo charset noto come UTF-8 è un superset dell’ASCII, questo significa che è retrocompatibile con l’ASCII, ma che è in grado di rappresentare anche i caratteri degli altri alfabeti.

Per fare ciò sostanzialmente si prevede l’espansione dinamica dell’occupazione di ogni singolo carattere: nel caso dell’ASCII i caratteri occupano 1 byte, nel caso di altri alfabeti possono arrivare ad occupare 4 byte ciascuno.

Come detto precedentemente mentre qualsiasi linguaggio, per ragioni storiche, gestisce nativamente il charset ASCII, ciò non è sempre vero per l’UTF-8.

Nel PHP, per esempio, c’è una libreria apposita per la gestione di stringhe multibyte come nel caso dell’UTF-8 e si chiama appunto Multibyte String.

Questa libreria ripropone tutte le funzioni classiche per la gestione delle stringhe strlen, strtolower, strtoupper, substr ecc. in versione multibyte mb_strlen, mb_strtolower, mb_strtoupper, mb_substr ecc.

Ciò non è però sufficiente, infatti la corretta gestione dell’encoding interessa vari livelli della nostra webapp: dagli header HTTP, all’HTML, al PHP.

Per quanto riguarda gli header HTTP ci dobbiamo ricordare di indicare l’encoding attraverso la funzione header del PHP e del parametro Content-Type come nell’esempio seguente:

header('Content-Type: text/html; charset=utf-8');

Nella sezione head dell’HTML dobbiamo specificare l’encoding della pagina con il meta seguente:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Nel PHP, oltre ad utilizzare la già citata libreria al posto di quella standard per le stringhe, dobbiamo specificare che l’ internal encoding della nostra applicazione è UTF-8 utilizzando la funzione mb_internal_encoding

mb_internal_encoding("UTF-8");

E infine anche gli stessi sorgenti PHP devono essere codificati in UTF-8 senza BOM.

Per sapere se una funzione PHP tratta correttamente il multibyte ci si può riferire al seguente articolo Handling UTF-8 with PHP

Il tuo software è sicuro?

pic_0655

Con la crescita di economie come la Cina, le imprese Italiane si sono trovate a dover fronteggiare una concorrenza spietata fatta di spionaggio industriale e copie su larga scala del made in italy e in particolar modo sul design.

Sempre in tema di spionaggio industriale è recente infatti la notizia di un virus per Autocad capace di rubarne i file e di inviarli a provider Cinesi.

Da questi fatti si evince che la sicurezza del proprio sistema informativo non è da considerarsi un aspetto di secondaria importanza.

Scrivere software sicuro però non è alla portata di tutti: servono preparazione, esperienza e aggiornamento continuo.

Un’ottima fonte di informazioni è il sito OWASP il quale analizza le possibili minacce alla sicurezza, propone best practice nello sviluppo di software sicuro e fornisce tool per la ricerca automatica di vulnerabilità come OWASP ZAP.

Di particolare utilità il progetto Top 10 che classifica e analizza i 10 maggiori rischi di sicurezza per le applicazioni.

Il rispetto di queste pratiche assicura un buon margine di sicurezza e di conseguenza la salvaguardia dei dati sensibili del cliente.

Problematiche ricorrenti nello sviluppo di webapp 1/3: escaping

Cactus

Il primo di tre problemi ricorrenti nello sviluppo di webapp deriva dal corretto escaping dei dati inviati dal server al browser.

  • Questo problema sorge laddove l’utente può inserire dei dati nella nostra webapp;
  • non trattare opportunamente questi dati equivale a lasciare aperta la porta a malintenzionati;
  • l’escaping infatti è la soluzione a vulnerabilità come il XSS (Cross Site Scripting);
  • conoscerlo e saperlo gestire correttamente è essenziale per sviluppare webapp sicure;

In generale in una webapp va fatto l’escaping di tutto ciò che viene generato lato server e che poi viene interpretato dal browser.

Tutte le volte che si sta generando una pagina HTML da inviare al browser utilizzando dati provenienti dal database o dall’utente, bisogna chiedersi se e come bisogna farne l’escaping.

In particolare se si sviluppa in PHP bisogna conoscere per ogni elemento della pagina (html, css, javascript, …) che si sta creando, le apposite funzioni e gli appositi accorgimenti per effettuare l’escaping del contenuto.

Le funzioni della tabella seguente se utilizzate con gli opportuni accorgimenti possono essere la base per effettuare un corretto escaping.

elemento funzione PHP
HTML htmlentities/htmlspecialchars
valore degli attributi HTML htmlentities/htmlspecialchars
JavaScript addslashes/json_encode
URL/URI rawurlencode/urlencode

Se il framework che utilizziamo si preoccupa di effettuare correttamente l’escaping di questi elementi bene, diversamente ce ne dovremo occupare noi.