Metodi moderni per lo sviluppo del software

Sviluppare sw di qualità e mantenere un gruppo di sviluppo affidabile secondo le più moderne tecniche

Data:
5-6-7 Ottobre 2009

Docente:
Francesco Mondora

Per informazioni riguardo il corso contattare:
lucia.longoni {at} mondora(.)com


Descrizione

Sono due i principali pilastri su cui è stato costruito il corso.

  • L’esigenza di adottare un processo di sviluppo di software che permetta di raggiungere gli obiettivi secondo regole di qualità, secondo i requisiti funzionali e rispettando un budget preallocato e compatibile con le richieste di mercato.
  • Distribuzione della conoscenza per rendere un gruppo di lavoro più affidabile e affrontare lo sviluppo del software in maniera concreta e consapevole, secondo le più moderne tecniche che risaltano le qualità dello sviluppatore.

Il seminario si focalizza su sessioni hands-on sia manageriale che implementativo verso una dinamica al lavoro adattiva rispetto ad una predittiva per contingenza e presenta due metodi agili quali Scrum ed eXtreme Programming.

Il corso è predisposto sia per i gruppi di lavoro che intendono amalgamarsi ed iniziare una attività produttiva, che per il management che vuole avere il polso dell’andamento del lavoro stesso.

Durante l’evoluzione del corso si approcceranno temi quali la qualità nel software come valutazione oggettiva, l’adozione dell’object orientation come normale risposta alla velocità di mercato e le dinamiche sociali complesse allinterno di un gruppo di lavoro.

Una parte rilevante del corso è dedicata all’applicabilità pratica dei metodi attraverso esercitazioni su situazioni concrete. Il caso di studio di un sistema informativo è presentato all’inizio e segue passo passo gli argomenti del corso.


Argomenti

Il ciclo di sviluppo del software fino all’anno 2000
Si ripercorre un excursus sui metodi strutturati nell’analisi di sistemi informativi.

Introduzione all’Object Oriented e all’UML
Valorizzazione del modo di pensare ad oggetti rispetto a un modo di lavoro funzionale, che introduce il concetto di classi, istanze, incapsulamento, ereditarietà e polimorfismo.

Analisi e Design: il concetto di Classi e Oggetti e la loro individuazione
Come da una serie di requisiti si può passare ad un modello ad oggetti attraverso la tenica delle CRC cards e dell’analisi per Use Cases.

Definizione relazionale dei dati su modelli di oggetti
Passare da un modello a Classi e mapparlo su un database relazionale.
Introduzione agli ORM e al modo di mappatura delle relazioni.

I metodi agili nello sviluppo del software: Scrum ed eXtreme Programming
Introduzione a tecniche di gestione del software cui la Code Collective Ownership e lo Unit Testing.

Il ciclo di sviluppo del software secondo metodi moderni

Sviluppo software

Il paradigma di programmazione per applicazioni enterprise più utilizzato, del quale mondora conta innumerevoli esperienze positive, è quello dell’Object Oriented; anche se è in grado di affrontare lo sviluppo con paradigma procedurale.

Lo sviluppo software viene effettuato in linguaggio e con gli strumenti scelti dal cliente, a partire dal sistema operativo, il linguaggio, l’editor, il repository, il database, gli strumenti di test, fino all’application server e a tutti i tools necessari.

Per garantire il rilascio di software ad alta qualità, mondora sviluppa test per le singole unità. Inoltre, ove possibile ed opportuno, applica le metodologie, agili o tradizionali, che portano ai migliori risultati.

Mondora conta su programmatori esperti, designer di consolidata esperienza che applicano tutte le linee guida e pattern appropriatamente. Il software design ha cura di definire tutte le convenzioni standard di sviluppo del codice.

Lo skill del programmatore mondora è quello di team leader, con grande capacità di risoluzione dei problemi e di coordinamento di un gruppo di persone. Utilizzato come programmatore ha grande autonomia ed indipendenza, ma anche capacità di inserirsi in un gruppo. Rilascia parti di software robusto, stabile, manutenibile, testato, documentato, che rispetta le convenzioni di codifica stabilite, pronto per essere messo in produzione.

Developer 2.0 – a software personality

Last edited by on May 25, 2008 6:50 pm
I’m just back from Almens (Swiss) after a day of talking about stuff on several things in mine interests with a good friend Tim Mackinnon. After some talks that gave me a better understanding on how architecture are changing, they’re ready to be dumped on a blog entry.
Before start describing the 2.0 I need to go more in depth about the evolution of an Architect form 1.0 to 2.0
 In 1.0 he is responsible for:
- the architecture of the system including component reuse (logical and physical reuse),
- finding patterns for problem solution, - driving the philosophy in separating concerns between core component.   

Meanwhile, Developer 1.0 requires analysis and designs before writing a line of code, the 2.0 approach is starting from a business feature and instantly writing it. A 2.0 architecture emerges as the code’s soul, like when a voice comes from the soul of kid. The soul must be educated, and the role of the architect should be as educator to an architectural approach by iterating over all the development content and all the developers while they’re under pressure in releasing line of code. In this way, architects facilitate the emerge of an architecture thought as the Software Personality. With their new approach in linking developer 2.0 contents (code, documentation, feature, etc.) they’re are creating those links that enforce the soul of software. Personality increases day by day, line by line, and architecture emerges with it and consolidates with it. Modern architects linking code snippets with tags of a specific context (architecture for example) are implicitly educating code with a personality. Code behavior is the feature implemented, and the old fashioned architecture diagram is an outcome of what is implicitly related inside the code by architects; both the logical and physical statement. The analysis of those links between things produces different graph of related things, and those graphs can be drilled down by following all the tags.

 

– architecture cloud -

 

The above diagram can be derived by analyzing tags and relationship between tags: architecture is a derivation by the tag graph inside the system. By having it expressed as a graph from the analysis of the system, it can be thought as an architecture cloud, where the most important component is bigger than the others and when dependencies between component are inherited from tagging. An architect 2.0 is responsible for creating the culture of tagging components to create the 1.0 hidden relationship between logical and physical components. This constitutes the soul of the application that must grow with the system day by day in a pragmatic way by adopting feature to code (as the voice) to the soul. I would like to go more in dept in a future post about the tool. An architect 2.0 should use for maintain upstanding a soul of a system.

Comments (0)