Introduzione

Ingegneria del So-ware (e Prova Finale) Luciano Baresi [email protected] Organizzazione dei corsi •  Ingegneria del so-ware (7 crediB) –  Lezioni: 42 ore –  Esercitazioni: 28 ore •  Prova finale (3 crediB) –  Esercitazioni: 16 ore –  Laboratorio: 32 ore 2
Chi siamo •  Titolare del corso: Luciano Baresi –  [email protected] •  Esercitazioni –  Alessandro Campi •  Laboratorio 3
Orario •  Lunedì (D0.3) –  13:15 – 15:15 •  Martedì (S1.3) –  13:15 – 17:15 •  Mercoledì (T0.2) –  10:15 – 12:15 •  Venerdì (CE1) –  8:15 – 10:15 4
Programma •  Programmazione nei linguaggi orientaB agli oggeW –  Linguaggio Java •  Principi di programmazione di rete e distribuita •  Principi di programmazione delle interfacce utente •  ProgeZazione orientata agli oggeW –  Unified Modeling Language –  Design paZern •  Specifica di metodi e classi •  Principi del test funzionale e struZurale 5
Materiale didaWco •  Non esiste un libro di testo unico •  hZp://home.deib.polimi.it/baresi/is.htm 6
ObieWvi •  ProgeZazione e programmazione ad oggeW –  Java/RMI/Swing –  UML •  Specifica rigorosa (per contraW) •  ElemenB per il test sistemaBco dei programmi 7
Iniziamo? Ingegneria del So-ware •  SeZore dell'informaBca che studia sistemi –  complessi e di grandi dimensioni –  naB dal lavoro di gruppo •  QuesB sistemi –  esistono in diverse versioni –  hanno una durata di anni –  sono soggeW a frequenB modifiche 9
Possibili definizioni •  Approccio sistemaBco allo sviluppo, alla messa in opera e alla manutenzione del so-ware •  Metodi tecnici e manageriali per prevedere e tenere soZo controllo i cosB per tuZa la vita ("lifecycle") dei prodoW so-ware •  Come tuZe le ingegnerie: –  Fornisce una guida per applicare la conoscenza scienBfica allo sviluppo di soluzioni (so-ware) "cost-‐
effecBve" per risolvere problemi praBci a beneficio dell'uomo 10
Processo e prodoZo •  Processo –  Come avviene lo sviluppo industriale del so-ware •  ProdoZo –  Che cosa viene prodoZo? Studiare i metodi da usare perché il processo porB allo sviluppo di prodoW di qualità 11
Ingegneria •  ProgeZo normale/standard –  Soluzione a un problema noto e ricorrente –  Riuso di soluzioni note –  Innovazione limitata •  Bpico di discipline mature •  ProgeZo innovaBvo –  Soluzioni radicalmente nuove a problemi non noB •  Occorre saper disBnguere tra i due 12
Confronto con ingegneria tradizionale •  (Troppo) spesso viene traZata come “progeZo innovaBvo” •  (Troppo) spesso viene praBcata in modo poco sistemaBco (ingegnerisBco/industriale) 13
Differenze •  Ingegnerie tradizionali –  prevale il progeZo di rouBne –  progeZo di estremo deZaglio che produce le specifiche per la realizzazione –  processo di produzione separato –  progeW alternaBvi convalidaB aZraverso modelli –  dopo il progeZo, pochi margini di cambiamento –  processi standard per progeZo e produzione 14
Ingegneria del so-ware (1) •  L’ingegneria civile ha alle spalle 3000 anni –  Un patrimonio di conoscenze •  Ciò è vero per quasi tuZe le ingegnerie •  L’ingegneria del so-ware ha solo 45 anni 15
Ingegneria del so-ware (2) •  Congelare le specifiche di prodoZo e di progeZo è spesso non realisBco •  CambiamenB ed evoluzione spesso inevitabili –  poichè il so-ware è il cuore dei processi sociali e di business –  QuesB conBnuano ad evolvere 16
Il so-ware oggi •  Il so-ware è parte essenziale di molB prodoW di largo consumo –  Dal telefonino alla lavatrice, dall’automobile al forno •  Spesso il so-ware non è il prodoZo, ma è una parte del prodoZo –  Deve essere ingegnerizzato con il resto dell’applicazione •  Il meccanismo delle patch non funziona in tuW quesB casi –  Come faccio ad aZaccare la macchina ad Internet 17
18
Complessità, criBcità e dimensione •  Fanno la vera differenza –  Richiedono un approccio sistemaBco (ingegnerisBco) per poter oZenere la necessaria qualità controllando cosB e tempi •  Secondo F. Brooks (The Mythical Man Month) –  "programmare per se stesso" rispeZo a "programmare per altri" -‐> costo al quadrato –  Aggiungere persone a un progeZo in ritardo lo ritarda ulteriormente 19
CHAOS report (I) RESOLUTION
2004
2006
2008
2010
2012
Successful
29%
35%
32%
37%
39%
Failed
18%
19%
24%
21%
18%
Challenged
53%
46%
44%
42%
43%
Project resolution
results from CHAOS
research for years
2004 to 2012.
OVERRUNS AND FEATURES
Time and cost
overruns, plus
percentage of
features delivered
from CHAOS research
for the years 2004 to
2012.
100
80
60
40
Features
20
Cost
Time
0
2004
2006
2008
2010
2012
TIME
84%
72%
79%
71%
74%
COST
56%
47%
54%
46%
59%
FEATURES
64%
68%
67%
74%
69%
Determining the relationship of project overruns to features delivered is an analytical process. An
analyst reviews each challenged project. This year’s figures show a slight increase in both cost and
time overruns. Cost overruns increased from 56% in 2004 to 59% in 2012. Time overruns also
have gone up, from 71% in 2010 to 74% in 2012. The high point in time overruns was 2004 (84%).
20
CHAOS report (II) FACTORS OF SUCCESS FOR SMALL PROJECTS
The current 2013 Factors of Success in the
Factors of Success
CKC are unchanged from 2012. We have
Executive management support
20
developed a special version of the Factors
User involvement
15
of Success for Small Projects using our new
Optimization
15
Skilled resources
13
Project management expertise
12
CHAOS database and analytic tools. The small
project version of the Factors of Success also
Points
Agile process
10
has executive sponsorship as the number one
Clear business objectives
6
factor, but the prioritization of some of the
Emotional maturity
5
other factors shifts.
Execution
3
Tools and infrastructure
1
Executive Management Support: The most important
person in the project is the executive sponsor. The
executive sponsor is ultimately responsible for the
Agile Process: Embodies the small project philosophy.
CHAOS
RESOLUTION
success and failure of the project. We
give executive
TheBY
agileLARGE
process AND
directlySMALL
addressesPROJECTS
user involvement,
sponsorship 20 small project success points.
executive support, and the other success factors. We
Small Projects
Project resolution for the
Large Projects
give the agile process 10 small project success points.
User Involvement: CHAOS research clearly shows that
calendar year 2012 in the
projects that lack user involvement perform
poorly.
User Small Clear Business Objectives: A less important ingredient
new CHAOS
database.
projects resolution
are defined as
participation has a major effect on project
10%
for small projects than larger
20% projects. Still, the small
projects
lessproject
than $1 project should have a business objective, though it might
large or small; in fact, we give it 15%
of ourwith
small
million in labor content and
success points.
be less clear. Even so, all projects
4% should align the
large projects are considered
organization’s
goals
and
strategy,
which is why it has 6
with moreIfthan $10
Optimization: Is in the third spot forprojects
small projects.
of
the
small
project
success
points.
76%
labor content.
we defined optimization as a projectmillion
with ainsmall
labor
Successful
Failed
Challenged
52%
38%
content and fast delivery, it could be number one. Size
and complexity trump all other factors. Optimization gets
15 small project success points.
Skilled Resources: In the fourth position and with 13
small project success points, it may seem that skilled
resources gets no respect, but that is not true. A project
is made up of people, and success is on their shoulders.
This is especially true for small projects.
Emotional Maturity: Covers the emotional state of
the project environment. Projects get resolved within
the ecosystem; a healthy ecosystem produces more
successful projects. Emotional maturity accounts for 5
small project success points.
Execution: Is the process that governs and controls the
project. Much of this factor focuses on financial controls
and procedures. We give execution 3 small project
success points.
21
ProgeZazione vs. Programmazione •  Saper programmare non basta per essere un ingegnere del so-ware –  programmatore •  sviluppa un programma completo •  partendo da specifiche fornite da altri •  lavora individualmente –  ingegnere del so-ware • 
• 
• 
• 
analizza problemi e domini applicaBvi coglie i requisiB e sviluppa specifiche progeZa componenB, potenzialmente riusabili lavora in un gruppo 22
ProgeZazione •  Scomposizione di un sistema in moduli –  scomporre un problema in soZo-‐problemi che possano essere risolB indipendentemente •  Quali obieWvi della scomposizione? –  governare la complessità •  divide et impera –  rendere efficiente il processo •  sviluppo indipendente delle parB •  Riduzione di confliW/incomprensioni fra gli sviluppatori 23

Download Report