diff --git a/AmmProgetto.html b/AmmProgetto.html index fbc1417..d2f0b29 100644 --- a/AmmProgetto.html +++ b/AmmProgetto.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/AnalisiDinamica.html b/AnalisiDinamica.html index 813dfe6..d62f5d7 100644 --- a/AnalisiDinamica.html +++ b/AnalisiDinamica.html @@ -1,61 +1,67 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/AnalisiStatica.html b/AnalisiStatica.html index 41c3a33..7579f21 100644 --- a/AnalisiStatica.html +++ b/AnalisiStatica.html @@ -1,61 +1,67 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/Cardin.html b/Cardin.html index abe39e5..5426b4d 100644 --- a/Cardin.html +++ b/Cardin.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/CiclodiVita.html b/CiclodiVita.html index e8b0138..17be30c 100644 --- a/CiclodiVita.html +++ b/CiclodiVita.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/Doc.html b/Doc.html index 2075a8c..4e7358a 100644 --- a/Doc.html +++ b/Doc.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/GestionediProgetto.html b/GestionediProgetto.html index ab8d38c..3fb0fd0 100644 --- a/GestionediProgetto.html +++ b/GestionediProgetto.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/Glossario.html b/Glossario.html index 227776c..27fbdee 100644 --- a/Glossario.html +++ b/Glossario.html @@ -1,77 +1,85 @@ - + - - SWEky - La wiki di SWE - - - - - - + + SWEky - La wiki di SWE + + + + + + - - - - + function sortFunction(a, b) { + return (a.word).localeCompare(b.word); + } - + function getGlossario() { + $('#contento').append('

Glossario

'); + + + $.getJSON('./src/glossary.json', function (json) { + let curLetter = 'Z'; + let rowNum = 1; + let tabNum = 1; + let mydiv = ''; + let arr = $.map(json, function (el) { + return el + }); + arr.sort(sortFunction); + + for (i = 0; i < arr.length; i++) { + if ((arr[i].word).charAt(0) != curLetter) { + if (mydiv != '') + mydiv += ' '; + curLetter = (arr[i].word).charAt(0); + mydiv += '

' + curLetter + '

' + rowNum = 1; + tabNum++; + } + + if (rowNum % 2 == 0) { + mydiv += '' + } else mydiv += '' + mydiv += '
' + arr[i].word + '
'; + mydiv += '
' + arr[i].definition + '
'; + rowNum++; + } + ; + mydiv += '
'; + let html = $.parseHTML(mydiv); + + $('#contento').append(html); + }); + } + + + + - - -
- + + +
+ -
- +
+ diff --git a/IngRequisiti.html b/IngRequisiti.html index 911a4c2..27257d7 100644 --- a/IngRequisiti.html +++ b/IngRequisiti.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/Introduzione.html b/Introduzione.html index 9fbdce4..e00847e 100644 --- a/Introduzione.html +++ b/Introduzione.html @@ -1,43 +1,46 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/IntroduzioneVV.html b/IntroduzioneVV.html index 83419cf..e3df2b8 100644 --- a/IntroduzioneVV.html +++ b/IntroduzioneVV.html @@ -1,61 +1,67 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/Metriche.html b/Metriche.html index 2c3c65a..5f864e4 100644 --- a/Metriche.html +++ b/Metriche.html @@ -1,61 +1,67 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/ProcessiSW.html b/ProcessiSW.html index 75234d0..80325fc 100644 --- a/ProcessiSW.html +++ b/ProcessiSW.html @@ -1,43 +1,46 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/ProgSoftware.html b/ProgSoftware.html index 220b033..d90f274 100644 --- a/ProgSoftware.html +++ b/ProgSoftware.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/QualProc.html b/QualProc.html index c9f1c15..b770062 100644 --- a/QualProc.html +++ b/QualProc.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/QualSW.html b/QualSW.html index b87986c..6aea16d 100644 --- a/QualSW.html +++ b/QualSW.html @@ -1,48 +1,51 @@ - + - - SWEky - La wiki di SWE - - - - - - - - - - - - - - - - - + + SWEky - La wiki di SWE + + + + + + + + + + + + + + + + + - - -
- + + +
+ -
- +
+ diff --git a/commonBody.html b/commonBody.html index 9f0ced0..e48d387 100644 --- a/commonBody.html +++ b/commonBody.html @@ -1,92 +1,96 @@ -
- - - + + + +
+ +

La wiki di SWE

+
+ +
+
+
+
-
-
-
-
- -
-
- - \ No newline at end of file +
+
+ + \ No newline at end of file diff --git a/css/style.css b/css/style.css index 778e0e5..162dfd9 100644 --- a/css/style.css +++ b/css/style.css @@ -1,616 +1 @@ -@import "https://designmodo.github.io/Flat-UI/dist/css/flat-ui.min.css"; -@import "https://maxcdn.bootstrapcdn.com/font-awesome/4.4.0/css/font-awesome.min.css"; -@import "https://daneden.github.io/animate.css/animate.min.css"; -/*-------------------------------*/ -/* VARIABLES */ -/*-------------------------------*/ -body { - position: relative; - overflow-x: hidden; - font-size: 1.8em; -} -body, -html { - height: auto; - background-color: #313335; -} -.nav .open > a { - background-color: transparent; -} -.nav .open > a:hover { - background-color: transparent; -} -.nav .open > a:focus { - background-color: transparent; -} -/*-------------------------------*/ -/* Wrappers */ -/*-------------------------------*/ -#wrapper { - -moz-transition: all 0.5s ease; - -o-transition: all 0.5s ease; - -webkit-transition: all 0.5s ease; - padding-left: 0; - height:100%; - background-color: #313335; - - transition: all 0.5s ease; -} -#wrapper.toggled { - padding-left: 20em; -} -#wrapper.toggled #sidebar-wrapper { - width: 20em; -} -#wrapper.toggled #page-content-wrapper { - margin-right: -20em; - position: absolute; -} -#sidebar-wrapper { - -moz-transition: all 0.5s ease; - -o-transition: all 0.5s ease; - -webkit-transition: all 0.5s ease; - background: #1a1a1a; - height: 100%; - left: 20em; - margin-left: -20em; - overflow-x: hidden; - overflow-y: auto; - transition: all 0.5s ease; - width: 0; - font-size: 1em; - z-index: 999; -} -#sidebar-wrapper::-webkit-scrollbar { - display: none; -} -#page-content-wrapper { - height: auto; - padding-top: 70px; - width: 100%; -} -/*-------------------------------*/ -/* Sidebar nav styles */ -/*-------------------------------*/ -.sidebar-nav { - list-style: none; - margin: 0; - padding: 0; - position: absolute; - top: 0; - width: 20em; -} -.sidebar-nav li { - display: inline-block; - line-height: 1.3em; - position: relative; - width: 100%; -} -.sidebar-nav li:before { - background-color: #1c1c1c; - content: ''; - height: 100%; - left: 0; - position: absolute; - top: 0; - -webkit-transition: width 0.2s ease-in; - transition: width 0.2s ease-in; - width: 3px; - z-index: -1; -} -.sidebar-nav li:first-child a { - background-color: #1a1a1a; - color: #ffffff; -} -.sidebar-nav li:nth-child(2):before { - background-color: #004D40; -} -.sidebar-nav li:nth-child(3):before { - background-color: #055548; -} -.sidebar-nav li:nth-child(4):before { - background-color: #0B5D50; -} -.sidebar-nav li:nth-child(5):before { - background-color: #116558; -} -.sidebar-nav li:nth-child(6):before { - background-color: #176D61; -} -.sidebar-nav li:nth-child(7):before { - background-color: #1D7569; -} -.sidebar-nav li:nth-child(8):before { - background-color: #237D71; -} -.sidebar-nav li:nth-child(9):before { - background-color: #29857A; -} -.sidebar-nav li:nth-child(10):before { - background-color: #2F8D82; -} -.sidebar-nav li:nth-child(11):before { - background-color: #35958A; -} -.sidebar-nav li:nth-child(12):before { - background-color: #3B958A; -} -.sidebar-nav li:nth-child(13):before { - background-color: #41A59B; -} -.sidebar-nav li:nth-child(14):before { - background-color: #47ADA3; -} -.sidebar-nav li:nth-child(15):before { - background-color: #4DB6AC; -} -.sidebar-nav li:hover:before { - -webkit-transition: width 0.2s ease-in; - transition: width 0.2s ease-in; - width: 100%; -} -.sidebar-nav li:hover { - background-color: transparent; - color: #ffffff; - font-weight: bold; -} -.sidebar-nav li a { - color: #ededed; - display: block; - padding: 10px 15px 10px 30px; - text-decoration: none; -} -.sidebar-nav li.open:hover before { - -webkit-transition: width 0.2s ease-in; - transition: width 0.2s ease-in; - width: 100%; -} -.sidebar-nav .dropdown-menu { - background-color: #212121; - border-radius: 0; - border: none; - box-shadow: none; - margin: 0; - padding: 0; - position: relative; - width: 100%; -} -.sidebar-nav li a:hover, -.sidebar-nav li a:active, -.sidebar-nav li a:focus, -.sidebar-nav li.open a:hover, -.sidebar-nav li.open a:active, -.sidebar-nav li.open a:focus { - background-color: transparent; - color: #ffffff; - text-decoration: none; -} -.sidebar-nav > .sidebar-brand { - font-size: 2em; - font-weight: bold; - height: 65px; - line-height: 44px; -} -/*-------------------------------*/ -/* Hamburger-Cross */ -/*-------------------------------*/ -.hamburger { - background: transparent; - border: none; - display: block; - height: 2em; - margin-left: 1em; - position: fixed; - top: 1em; - width: 2em; - z-index: 999; -} -.hamburger:hover { - outline: none; -} -.hamburger:focus { - outline: none; -} -.hamburger:active { - outline: none; -} -.hamburger.is-closed:before { - -webkit-transform: translate3d(0, 0, 0); - -webkit-transition: all 0.35s ease-in-out; - color: #ffffff; - content: ''; - display: block; - font-size: 14px; - line-height: 32px; - opacity: 0; - text-align: center; - width: 100px; -} -.hamburger.is-closed:hover before { - -webkit-transform: translate3d(-100px, 0, 0); - -webkit-transition: all 0.35s ease-in-out; - display: block; - opacity: 1; -} -.hamburger.is-closed:hover .hamb-top { - -webkit-transition: all 0.35s ease-in-out; - top: 0; -} -.hamburger.is-closed:hover .hamb-bottom { - -webkit-transition: all 0.35s ease-in-out; - bottom: 0; -} -.hamburger.is-closed .hamb-top { - -webkit-transition: all 0.35s ease-in-out; - background-color: rgba(255, 255, 255, 0.7); - top: 5px; -} -.hamburger.is-closed .hamb-middle { - background-color: rgba(255, 255, 255, 0.7); - margin-top: -2px; - top: 50%; -} -.hamburger.is-closed .hamb-bottom { - -webkit-transition: all 0.35s ease-in-out; - background-color: rgba(255, 255, 255, 0.7); - bottom: 5px; -} -.hamburger.is-closed .hamb-top, -.hamburger.is-closed .hamb-middle, -.hamburger.is-closed .hamb-bottom, -.hamburger.is-open .hamb-top, -.hamburger.is-open .hamb-middle, -.hamburger.is-open .hamb-bottom { - height: 4px; - left: 0; - position: absolute; - width: 100%; -} -.hamburger.is-open .hamb-top { - -webkit-transform: rotate(45deg); - -webkit-transition: -webkit-transform 0.2s cubic-bezier(0.73, 1, 0.28, 0.08); - background-color: #fff; - margin-top: -2px; - top: 50%; -} -.hamburger.is-open .hamb-middle { - background-color: #fff; - display: none; -} -.hamburger.is-open .hamb-bottom { - -webkit-transform: rotate(-45deg); - -webkit-transition: -webkit-transform 0.2s cubic-bezier(0.73, 1, 0.28, 0.08); - background-color: #fff; - margin-top: -2px; - top: 50%; -} -.hamburger.is-open:before { - -webkit-transform: translate3d(0, 0, 0); - -webkit-transition: all 0.35s ease-in-out; - color: #ffffff; - content: ''; - display: block; - font-size: 14px; - line-height: 32px; - opacity: 0; - text-align: center; - width: 100px; -} -.hamburger.is-open:hover before { - -webkit-transform: translate3d(-100px, 0, 0); - -webkit-transition: all 0.35s ease-in-out; - display: block; - opacity: 1; -} -/*-------------------------------*/ -/* Dark Overlay */ -/*-------------------------------*/ -.overlay { - position: fixed; - display: none; - width: 100%; - height: 100%; - top: 0; - left: 0; - right: 0; - bottom: 0; - background-color: rgba(0, 0, 0, 0.6); - z-index: 3; -} -/* SOME DEMO STYLES - NOT REQUIRED */ -body, -html { - background-color: #313335; -} -body h1, -body h2, -body h3, -body h4 { - color: #ffffff; - font-family: "RobotoRegular"; -} -body p{ - color: #ededed; - font-family: "RobotoLight"; -} -body ul{ - color: #ededed; - font-size: 1.1em; - font-family: "RobotoLight"; -} -body blockquote { - color: #ffffff; - font-size: 1.2em; - font-family: "RobotoLight"; - font-style: italic; -} -body a { - color: #ffffff; - font-family: "RobotoRegular"; - text-decoration: underline; -} -body a:hover { - color: #009688; -} -body b { - font-family: "RobotoRegular" -} - - -/* ROBA MIA */ - -@font-face { - font-family: "RobotoLight"; - src: url("./customFont.ttf") format("truetype"); -} - -@font-face { - font-family: "RobotoRegular"; - src: url("./customFontRegular.ttf") format("truetype"); -} - -.sidebar-nav { - font-family: "RobotoLight"; -} - -.container{ - width: 100%; - padding-left: 3em; - height: 100%; - padding-bottom: 2em; - padding-right: 3em; - background-color: #313335; -} - -#uppertext{ - margin-top: -1.49em; - margin-left: 2em; - font-size: 2em; - position: fixed; - width: 100%; - z-index: 2; -} - -#upperbar{ - position:fixed; - top: 0; - height: 4em; - width:100%; - background-color: #009688; - z-index: 1; -} - -.page-header{ - padding-bottom: 0.3em; - margin: 1.5em 0 0.75em; -} - -.lead{ - margin-bottom: 1em; - font-size: 1.7em; -} - -.container p{ - margin-bottom: 1em; - font-size: 1.1em; -} - -.container h3{ - font-size: 1.8em; -} -.container h4{ - font-size: 1.2em; -} -.container blockquote{ - padding: 0 0 0 1.2em; - font-size: 1em; - margin: 2em 0 2em; - color: #ffffff; - border-left: 3px solid #009688; -} - -.popover{ - z-index: 0; -} - -.popover-title { - font-size: 0.8em; - color: #ffffff; - background-color: #009688; - text-align: center; -} - -.popover-content { - color: #424242; - font-style: italic; - font-size: 1.1em; -} - -.panel-default > .panel-heading { - color: #ededed; - background-color: #009688; -} - -.panel-title a { - text-decoration: none; -} - -.panel-title a:hover, a:focus { - color: #ededed; -} - -.list-group-item { - background-color: #424242; - border: 1px solid #212121; - color: #ededed; -} - -.list-group-item:hover{ - opacity:0.8; -} - -.evenRow { - background-color: #393939; -} - -.fa { - margin-right: 0.7em; -} - -ul.dropdown-menu li { - font-size: 1.2em; - font-weight: bold; -} - -blockquote footer { - background: transparent; - font-style: italic; - color: #009688; - text-align: right; -} - -.docIndex { - background-color: #4d4d4d; - text-align: center; -} - -.indeximg { - width: 16em; -} - -.cardinimg{ - width: 80%; - margin-left: 10%; -} - -.navbar ::-webkit-scrollbar { - width: 0px; /* remove scrollbar space */ - display: none; -} - -#footer{ - padding-top: 0.4em; - padding-bottom: 0.4em; - width:100%; - z-index: 1; - background-color: #212121; - text-align: center; -} - -#footerText{ - color: #ffffff; - font-family: "RobotoRegular"; - font-size: 0.8em; - margin-bottom: 0; -} - -#footerText a{ - text-decoration: none; - font-weight: bold; -} - - - - -/* MEDIA QUERIES */ - -@media screen and (max-width:767px){ - #wrapper.toggled{ - padding-left: 0; - } - - #wrapper.toggled #sidebar-wrapper { - width: 69%; - } - #wrapper.toggled #page-content-wrapper { - margin-right: 0; - position: absolute; - } -#sidebar-wrapper { - left: 69%; - margin-left: -69%; - font-size: 1.25em; -} -/*-------------------------------*/ -/* Sidebar nav styles */ -/*-------------------------------*/ -.sidebar-nav { - width: 100%; -} - -.sidebar-nav > .sidebar-brand { - font-size: 1.7em; -} - -.sidebar-nav li { - line-height: 1.2em; - font-size: 0.8em; -} - -.hamburger { - width: 1.7em; - height: 1.7em; -} - -.hamburger.is-open { - margin-left: 60%; - position: absolute; - width: 1.7em; - z-index: 1000; -} - -#uppertext { - margin-top: -1.75em; - margin-left: 2em; - font-size: 1.7em; - width: 150%; -} - -.container { - padding-left: 1.5em; - padding-right: 1.5em; -} - -.page-header { - font-size: 2em; -} - -.container p, .container blockquote { - font-size: 0.95em; -} - -.container h3 { - font-size: 1.6em; -} - -.cardinimg{ - width: 100%; - margin-left: 0; -} -} - -@media screen and (max-width:450px){ -.indeximg { - width: 90%; -} -} \ No newline at end of file +@import "https://cdn.jsdelivr.net/npm/font-awesome@4/css/font-awesome.min.css";@import "https://cdn.jsdelivr.net/npm/flat-ui@2/css/flat-ui.min.css";@import "https://cdn.jsdelivr.net/npm/animate.css@4/animate.min.css";body{position:relative;overflow-x:hidden}body,html{height:100%;background-color:#ededed}.nav .open>a{background-color:transparent}.nav .open>a:hover{background-color:transparent}.nav .open>a:focus{background-color:transparent}#wrapper{-moz-transition:all .5s ease;-o-transition:all .5s ease;-webkit-transition:all .5s ease;padding-left:0;transition:all .5s ease}#wrapper.toggled{padding-left:220px}#wrapper.toggled #sidebar-wrapper{width:220px}#wrapper.toggled #page-content-wrapper{margin-right:-220px;position:absolute}#sidebar-wrapper{-moz-transition:all .5s ease;-o-transition:all .5s ease;-webkit-transition:all .5s ease;background:#1a1a1a;height:100%;left:220px;margin-left:-220px;overflow-x:hidden;overflow-y:auto;transition:all .5s ease;width:0;z-index:1000}#sidebar-wrapper::-webkit-scrollbar{display:none}#page-content-wrapper{padding-top:70px;width:100%}.sidebar-nav{list-style:none;margin:0;padding:0;position:absolute;top:0;width:220px}.sidebar-nav li{display:inline-block;line-height:20px;position:relative;width:100%}.sidebar-nav li:before{background-color:#1c1c1c;content:'';height:100%;left:0;position:absolute;top:0;transition:width .2s ease-in;width:3px;z-index:-1}.sidebar-nav li:first-child a{background-color:#1a1a1a;color:#fff}.sidebar-nav li:nth-child(2):before{background-color:#d3d3d3}.sidebar-nav li:nth-child(3):before{background-color:#e0e0e0}.sidebar-nav li:nth-child(4):before{background-color:#ededed}.sidebar-nav li:nth-child(5):before{background-color:#fafafa}.sidebar-nav li:nth-child(6):before{background-color:#fff}.sidebar-nav li:nth-child(7):before{background-color:#fff}.sidebar-nav li:nth-child(8):before{background-color:#fff}.sidebar-nav li:nth-child(9):before{background-color:#fff}.sidebar-nav li:hover:before{transition:width .2s ease-in;width:100%}.sidebar-nav li a{color:#ddd;display:block;padding:10px 15px 10px 30px;text-decoration:none}.sidebar-nav li.open:hover before{transition:width .2s ease-in;width:100%}.sidebar-nav .dropdown-menu{background-color:#222;border-radius:0;border:none;box-shadow:none;margin:0;padding:0;position:relative;width:100%}.sidebar-nav li a:active,.sidebar-nav li a:focus,.sidebar-nav li a:hover,.sidebar-nav li.open a:active,.sidebar-nav li.open a:focus,.sidebar-nav li.open a:hover{background-color:transparent;color:#fff;text-decoration:none}.sidebar-nav>.sidebar-brand{font-size:20px;height:65px;line-height:44px}.hamburger{background:0 0;border:none;display:block;height:32px;margin-left:15px;position:fixed;top:20px;width:32px;z-index:999}.hamburger:hover{outline:0}.hamburger:focus{outline:0}.hamburger:active{outline:0}.hamburger.is-closed:before{-webkit-transform:translate3d(0,0,0);-webkit-transition:all .35s ease-in-out;color:#fff;content:'';display:block;font-size:14px;line-height:32px;opacity:0;text-align:center;width:100px}.hamburger.is-closed:hover before{-webkit-transform:translate3d(-100px,0,0);-webkit-transition:all .35s ease-in-out;display:block;opacity:1}.hamburger.is-closed:hover .hamb-top{-webkit-transition:all .35s ease-in-out;top:0}.hamburger.is-closed:hover .hamb-bottom{-webkit-transition:all .35s ease-in-out;bottom:0}.hamburger.is-closed .hamb-top{-webkit-transition:all .35s ease-in-out;background-color:rgba(33,33,33,.7);top:5px}.hamburger.is-closed .hamb-middle{background-color:rgba(33,33,33,.7);margin-top:-2px;top:50%}.hamburger.is-closed .hamb-bottom{-webkit-transition:all .35s ease-in-out;background-color:rgba(33,33,33,.7);bottom:5px}.hamburger.is-closed .hamb-bottom,.hamburger.is-closed .hamb-middle,.hamburger.is-closed .hamb-top,.hamburger.is-open .hamb-bottom,.hamburger.is-open .hamb-middle,.hamburger.is-open .hamb-top{height:4px;left:0;position:absolute;width:100%}.hamburger.is-open .hamb-top{-webkit-transform:rotate(45deg);-webkit-transition:-webkit-transform .2s cubic-bezier(.73,1,.28,.08);background-color:#212121;margin-top:-2px;top:50%}.hamburger.is-open .hamb-middle{background-color:#212121;display:none}.hamburger.is-open .hamb-bottom{-webkit-transform:rotate(-45deg);-webkit-transition:-webkit-transform .2s cubic-bezier(.73,1,.28,.08);background-color:#212121;margin-top:-2px;top:50%}.hamburger.is-open:before{-webkit-transform:translate3d(0,0,0);-webkit-transition:all .35s ease-in-out;color:#fff;content:'';display:block;font-size:14px;line-height:32px;opacity:0;text-align:center;width:100px}.hamburger.is-open:hover before{-webkit-transform:translate3d(-100px,0,0);-webkit-transition:all .35s ease-in-out;display:block;opacity:1}.overlay{position:fixed;display:none;width:100%;height:100%;top:0;left:0;right:0;bottom:0;background-color:rgba(0,0,0,.4);z-index:1}body,html{background-color:#ededed}body h1,body h2,body h3,body h4{color:rgba(33,33,33,.9)}body blockquote,body p{color:rgba(33,33,33,.7)}body a{color:rgba(33,33,33,.8);text-decoration:underline}body a:hover{color:#212121} \ No newline at end of file diff --git a/index.html b/index.html index 617e3c0..e251578 100644 --- a/index.html +++ b/index.html @@ -1,15 +1,11 @@ - - - - -

Redirecting...

-

- Se la pagina non dovesse caricarsi automaticamente, clicca qui. -

- + + + + +

Redirecting...

+

+ Se la pagina non dovesse caricarsi automaticamente, clicca qui. +

+ \ No newline at end of file diff --git a/js/index.js b/js/index.js index 765aba9..1340482 100644 --- a/js/index.js +++ b/js/index.js @@ -1,52 +1,55 @@ $(document).ready(function () { - var trigger = $('.hamburger'), - overlay = $('.overlay'), - isClosed = false; + var trigger = $('.hamburger'), + overlay = $('.overlay'), + isClosed = false; trigger.click(function () { - hamburger_cross(); + hamburger_cross(); }); + function hamburger_cross() { - if (isClosed == true) { - overlay.hide(); - trigger.removeClass('is-open'); - trigger.addClass('is-closed'); - isClosed = false; - } else { - overlay.show(); - trigger.removeClass('is-closed'); - trigger.addClass('is-open'); - isClosed = true; - } - } - - $('[data-toggle="offcanvas"]').click(function () { + if (isClosed == true) { + overlay.hide(); + trigger.removeClass('is-open'); + trigger.addClass('is-closed'); + isClosed = false; + } else { + overlay.show(); + trigger.removeClass('is-closed'); + trigger.addClass('is-open'); + isClosed = true; + } + } + + $('[data-toggle="offcanvas"]').click(function () { $('#wrapper').toggleClass('toggled'); - }); - - $('#int').click( - function(){ - $('#news').load('Introduzione.html'); - }); + }); + + $('#int').click( + function () { + $('#news').load('Introduzione.html'); + }); }); - function getText(param){ - var testo; - - $.getJSON('./src/glossary.json', function(json) { - $.each(json.glossary, function(i, v) { - if (v.word ==param) { - document.getElementById(param).setAttribute('data-content',v.definition); - - } - }); - }); - } - function miao(){ - var popover=$('.glossar').data('bs.popover'); - popover.setContent(); - } - - function getTitle(){ - return "La wiki di SWE"; - } \ No newline at end of file + +function getText(param) { + var testo; + + $.getJSON('./src/glossary.json', function (json) { + $.each(json.glossary, function (i, v) { + if (v.word == param) { + document.getElementById(param).setAttribute('data-content', v.definition); + + } + }); + }); +} + +function miao() { + var popover = $('.glossar').data('bs.popover'); + popover.setContent(); +} + +function getTitle() { + return "La wiki di SWE"; +} \ No newline at end of file diff --git a/less/style.less b/less/style.less index cb2d229..be7cd9a 100644 --- a/less/style.less +++ b/less/style.less @@ -1,6 +1,6 @@ -@import "https://designmodo.github.io/Flat-UI/dist/css/flat-ui.min.css"; -@import "https://maxcdn.bootstrapcdn.com/font-awesome/4.4.0/css/font-awesome.min.css"; -@import "https://daneden.github.io/animate.css/animate.min.css"; +@import "https://cdn.jsdelivr.net/npm/font-awesome@4/css/font-awesome.min.css"; +@import "https://cdn.jsdelivr.net/npm/flat-ui@2/css/flat-ui.min.css"; +@import "https://cdn.jsdelivr.net/npm/animate.css@4/animate.min.css"; /*-------------------------------*/ /* VARIABLES */ /*-------------------------------*/ @@ -35,9 +35,10 @@ @full-height: 100%; body { - position: relative; - overflow-x: hidden; + position: relative; + overflow-x: hidden; } + body, html { height: @full-height; @@ -45,17 +46,14 @@ html { } - - - - - .nav { - .open>a { + .open > a { background-color: transparent; + &:hover { background-color: transparent; } + &:focus { background-color: transparent; } @@ -63,17 +61,6 @@ html { } - - - - - - - - - - - /*-------------------------------*/ /* Wrappers */ /*-------------------------------*/ @@ -85,16 +72,20 @@ html { padding-left: 0; transition: all 0.5s ease; } + #wrapper.toggled { padding-left: 220px; + #sidebar-wrapper { width: @width1; } + #page-content-wrapper { margin-right: -220px; position: absolute; } } + #sidebar-wrapper { -moz-transition: all 0.5s ease; -o-transition: all 0.5s ease; @@ -108,37 +99,17 @@ html { transition: all 0.5s ease; width: 0; z-index: 1000; + &::-webkit-scrollbar { display: none; } } + #page-content-wrapper { padding-top: 70px; width: @full-width; - -} - - - - - - - - - - - - - - - - - - - - - +} /*-------------------------------*/ @@ -152,11 +123,13 @@ html { position: absolute; top: 0; width: @width1; + li { display: inline-block; line-height: 20px; position: relative; width: @full-width; + &:before { background-color: #1c1c1c; content: ''; @@ -168,58 +141,69 @@ html { width: 3px; z-index: -1; } + &:first-child { a { background-color: @side-color-1; color: #ffffff; } } + &:nth-child(2) { &:before { background-color: @side-color-2; } } + &:nth-child(3) { &:before { background-color: @side-color-3; } } + &:nth-child(4) { &:before { background-color: @side-color-4; } } + &:nth-child(5) { &:before { background-color: @side-color-5; } } + &:nth-child(6) { &:before { background-color: @side-color-6; } } + &:nth-child(7) { &:before { background-color: @side-color-7; } } + &:nth-child(8) { &:before { background-color: @side-color-8; } } + &:nth-child(9) { &:before { background-color: @side-color-9; } } + &:hover { &:before { transition: width .2s ease-in; width: @full-width; } } + a { color: #dddddd; display: block; @@ -227,6 +211,7 @@ html { text-decoration: none; } } + li.open { &:hover { before { @@ -235,6 +220,7 @@ html { } } } + .dropdown-menu { background-color: #222222; border-radius: 0; @@ -246,43 +232,20 @@ html { width: @full-width; } } + .sidebar-nav li a:hover, .sidebar-nav li a:active, .sidebar-nav li a:focus, .sidebar-nav li.open a:hover, .sidebar-nav li.open a:active, .sidebar-nav li.open a:focus { background-color: transparent; color: #ffffff; text-decoration: none; } -.sidebar-nav>.sidebar-brand { + +.sidebar-nav > .sidebar-brand { font-size: 20px; height: 65px; line-height: 44px; } - - - - - - - - - - - - - - - - - - - - - - - - - /*-------------------------------*/ /* Hamburger-Cross */ /*-------------------------------*/ @@ -297,19 +260,23 @@ html { top: 20px; width: 32px; z-index: 999; + &:hover { outline: none; } + &:focus { outline: none; } + &:active { outline: none; } } + .hamburger.is-closed { &:before { - -webkit-transform: translate3d(0,0,0); + -webkit-transform: translate3d(0, 0, 0); -webkit-transition: all .35s ease-in-out; color: #ffffff; content: ''; @@ -320,66 +287,77 @@ html { text-align: center; width: @width2; } + &:hover { before { - -webkit-transform: translate3d(-100px,0,0); + -webkit-transform: translate3d(-100px, 0, 0); -webkit-transition: all .35s ease-in-out; display: block; opacity: 1; } + .hamb-top { -webkit-transition: all .35s ease-in-out; top: 0; } + .hamb-bottom { -webkit-transition: all .35s ease-in-out; bottom: 0; } } + .hamb-top { -webkit-transition: all .35s ease-in-out; background-color: @hamburger-color-closed; top: 5px; } + .hamb-middle { background-color: @hamburger-color-closed; margin-top: -2px; top: 50%; } + .hamb-bottom { -webkit-transition: all .35s ease-in-out; background-color: @hamburger-color-closed; bottom: 5px; } } -.hamburger.is-closed .hamb-top, .hamburger.is-closed .hamb-middle, .hamburger.is-closed .hamb-bottom, .hamburger.is-open .hamb-top, .hamburger.is-open .hamb-middle, .hamburger.is-open .hamb-bottom { + +.hamburger.is-closed .hamb-top, .hamburger.is-closed .hamb-middle, .hamburger.is-closed .hamb-bottom, .hamburger.is-open .hamb-top, .hamburger.is-open .hamb-middle, .hamburger.is-open .hamb-bottom { height: 4px; left: 0; position: absolute; width: @full-width; } + .hamburger.is-open { .hamb-top { -webkit-transform: rotate(45deg); - -webkit-transition: -webkit-transform .2s cubic-bezier(.73,1,.28,.08); + -webkit-transition: -webkit-transform .2s cubic-bezier(.73, 1, .28, .08); background-color: @hamburger-color-open; margin-top: -2px; top: 50%; } + .hamb-middle { background-color: @hamburger-color-open; display: none; } + .hamb-bottom { -webkit-transform: rotate(-45deg); - -webkit-transition: -webkit-transform .2s cubic-bezier(.73,1,.28,.08); + -webkit-transition: -webkit-transform .2s cubic-bezier(.73, 1, .28, .08); // background-color: #1a1a1a; background-color: @hamburger-color-open; margin-top: -2px; top: 50%; } + &:before { - -webkit-transform: translate3d(0,0,0); + -webkit-transform: translate3d(0, 0, 0); -webkit-transition: all .35s ease-in-out; color: #ffffff; content: ''; @@ -390,9 +368,10 @@ html { text-align: center; width: @width2; } + &:hover { before { - -webkit-transform: translate3d(-100px,0,0); + -webkit-transform: translate3d(-100px, 0, 0); -webkit-transition: all .35s ease-in-out; display: block; opacity: 1; @@ -401,71 +380,46 @@ html { } - - - - - - - - - - - - - - /*-------------------------------*/ /* Dark Overlay */ /*-------------------------------*/ .overlay { - position: fixed; - display: none; - width: @full-width; - height: @full-height; - top: 0; - left: 0; - right: 0; - bottom: 0; - background-color: rgba(0,0,0,.4); - z-index: 1; + position: fixed; + display: none; + width: @full-width; + height: @full-height; + top: 0; + left: 0; + right: 0; + bottom: 0; + background-color: rgba(0, 0, 0, .4); + z-index: 1; } +/* SOME DEMO STYLES - NOT REQUIRED */ +body, html { + background-color: @bg-color +} +body { + h1, h2, h3, h4 { + color: fadeout(@text-color, 10); + } + p, blockquote { + color: fadeout(@text-color, 30); + } + a { + color: fadeout(@text-color, 20); + text-decoration: underline; - - - - - - - - - - - - - - - - - - - - - - - - - - - - -/* SOME DEMO STYLES - NOT REQUIRED */ -body, html {background-color: @bg-color} body {h1,h2,h3,h4 {color:fadeout(@text-color, 10);}p, blockquote {color:fadeout(@text-color, 30);}a {color:fadeout(@text-color, 20);text-decoration:underline;&:hover {color:@text-color;}}} + &:hover { + color: @text-color; + } + } +} diff --git a/src/cAmmProgetto.html b/src/cAmmProgetto.html index 9a40982..ac5e179 100644 --- a/src/cAmmProgetto.html +++ b/src/cAmmProgetto.html @@ -1,131 +1,184 @@

Amministrazione Progetto

Compiti dell'amministratore di progetto

-L'amministratore è una figura che non si occupa delle scelte gestionali all'interno del progetto ma attua -scelte tecnologiche concordate con i responsabili, per far sì che l'infrastruttura di lavoro sia sempre operante e -per evitare conflitti che si possono manifestare dalla sovrapposizione di ruoli o di responsabilità. -
-Egli si occupa dunque di: equipaggiare(reperire e mantenere), organizzare e gestire l'ambiente di lavoro e di produzione a supporto di tutti i processi istanziati nel progetto.
-
-
-Questo viene fatto tramite la redazione di regole e procedure (approvate dal responsabile), strumenti e -servizi. -I suoi obblighi principali riguardano dunque la documentazione di progetto e dell'ambiente di lavoro. + L'amministratore è una figura che non si occupa delle scelte gestionali all'interno del progetto ma attua + scelte tecnologiche concordate con i responsabili, per far sì che l'infrastruttura di lavoro sia sempre operante e + per evitare conflitti che si possono manifestare dalla sovrapposizione di ruoli o di responsabilità. +
+ Egli si occupa dunque di: equipaggiare (reperire e mantenere), organizzare e gestire l'ambiente di lavoro e di + produzione a supporto di tutti i processi istanziati nel progetto.
+
+
+ Questo viene fatto tramite la redazione di regole e procedure (approvate dal responsabile), + strumenti e + servizi. + I suoi obblighi principali riguardano dunque la documentazione di progetto e dell'ambiente di lavoro.

Documentazione di progetto

-La documentazione è necessaria per rende un progetto ripetibile e gestibile. -La gestione dei documenti è affidata all'amministratore che deve assicurarsi che essi siano -chiaramente identificati, corretti nei contenuti, verificati, approvati, aggiornati e dotati di versione. -
-Deve inoltre controllarne la diffusione, identificando i destinari(lista di distribuzione). -Al fine di essere utili devono essere sempre disponibili. -
- -I documenti si dividono in: -
documenti di sviluppo, contenenti la documentazione fornita dal cliente, i diagrammi di progettazione, -il codice, i piani di qualifica(con relativi risultati delle prove) e la documentazione di accompagnamento del prodotto(manuali); -
-documenti di gestione del progetto che contengono i documenti contrattuali, i piani e i consuntivi delle attività e i piani di qualità. + La documentazione è necessaria per rende un progetto ripetibile e gestibile. + La gestione dei documenti è affidata all'amministratore che deve assicurarsi che essi siano + chiaramente identificati, corretti nei contenuti, verificati, approvati, aggiornati e dotati di versione. +
+ Deve inoltre controllarne la diffusione, identificando i destinatari (lista di distribuzione). + Al fine di essere utili devono essere sempre disponibili. +
+ + I documenti si dividono in: +
documenti di sviluppo, contenenti la documentazione fornita dal cliente, i diagrammi di progettazione, + il codice, i piani di qualifica (con relativi risultati delle prove) e la documentazione di accompagnamento del + prodotto (manuali); +
+ documenti di gestione del progetto che contengono i documenti contrattuali, i piani e i consuntivi delle attività e i piani di qualità.

Ambiente di lavoro

-L'amministratore si occupa della gestione dell'ambiente di lavoro in tutte le sue forme ossia per le persone, per i ruoli, per le procedure e per -l'infrastruttura.
-La qualità dell'ambiente di lavoro ha impatto diretto sulla qualità di processo e di prodotto, in quanto l'ambiente di lavoro rappresenta quanto serve i processi di produzione. -
-L'ambiente di lavoro deve dunque essere completo, ordinato e aggiornato. + L'amministratore si occupa della gestione dell'ambiente di lavoro in tutte le sue forme ossia per le persone, per i + ruoli, per le procedure e per + l'infrastruttura.
+ La qualità dell'ambiente di lavoro ha impatto diretto sulla qualità di processo e di prodotto, in quanto l'ambiente + di lavoro rappresenta quanto serve i processi di produzione. +
+ L'ambiente di lavoro deve dunque essere completo, ordinato e aggiornato.

Supporto di processi

-L'amministratore di progetto si deve occupare di trovare degli strumenti e dei servizi utili per supportare i processi di progetto. -Ad esempio per la gestione di progetto ha bisogno di strumenti di issue tracking per la pianificazione, di diagrammi(Gantt, wrike) per l'allocazione delle -risorse e di strumenti collaborativi. -
-Per la gestione documentale si possono usare strumenti di versionamento(LaTeX, Git) e di condivisione delle informazioni(Google Docs). -Per l'analisi e la progettazione serve uno strumento per tracciare i requisiti(Trender v.Carlo) e un supporto alle metodologie(UML). -
-Infine per la codifica e l'integrazione servono ambienti integrati di sviluppo(IntelliJIDEA), strumenti di integrazione continua con misurazioni e analisi del codice -e generazione dell'esecuzione automatica delle prove prima dell'integrazione. + L'amministratore di progetto si deve occupare di trovare degli strumenti e dei servizi utili per supportare i + processi di progetto. + Ad esempio per la gestione di progetto ha bisogno di strumenti di issue tracking per la pianificazione, di + diagrammi (Gantt, Wrike) per l'allocazione delle + risorse e di strumenti collaborativi. +
+ Per la gestione documentale si possono usare strumenti di versionamento (LaTeX, Git) e + di condivisione delle informazioni (Google Docs). + Per l'analisi e la progettazione serve uno strumento per tracciare i requisiti (Trender v.Carlo) e un supporto + alle metodologie (UML). +
+ Infine per la codifica e l'integrazione servono ambienti integrati di sviluppo (IntelliJ IDEA), strumenti di integrazione continua con misurazioni e + analisi del codice + e generazione dell'esecuzione automatica delle prove prima dell'integrazione.

Gestione della configurazione

-Altro compito dell'amministratore di progetto è la gestione della configurazione e del versionamento del prodotto, in modo da gestirne -le varie parti e tenere traccia delle modifiche. -
-Le regole secondo cui le parti di un prodotto software si uniscono (regole di configurazione) vanno pianificate -e la gestione della configurazione va automatizzata tramite strumenti adeguati come Git. -
-Bisogna identificare la configurazione tramite le parti che andranno a comporre il prodotto dette -configuration item. -Ogni CI deve presentare identità unica tramite id, nome, data, autore, registro delle modifiche e stato corrente. -
-Obiettivo della gestione di configurazione è la prevenzione di scritture accidentali, la possibilità di ritornare a configurazioni precedenti -e di permettere il recupero da perdite accidentali tramite la messa in sicurezza di baseline. -La baseline indica una base verificata, approvata e garantita di un insieme di CI dalla quale non si può retrocedere. -
-Una -milestone -è associata ad uno specifico insieme di baseline e indica un valore strategico nel tempo. -
Una milestone di buona qualità deve: + Altro compito dell'amministratore di progetto è la gestione della configurazione e del versionamento del prodotto, + in modo da gestirne + le varie parti e tenere traccia delle modifiche. +
+ Le regole secondo cui le parti di un prodotto software si uniscono (regole di configurazione) vanno pianificate + e la gestione della configurazione va automatizzata tramite strumenti adeguati come Git. +
+ Bisogna identificare la configurazione tramite le parti che andranno a comporre il prodotto dette + configuration item. + Ogni CI deve presentare identità unica tramite id, nome, data, autore, registro delle modifiche e stato corrente. +
+ Obiettivo della gestione di configurazione è la prevenzione di scritture accidentali, la possibilità di ritornare a + configurazioni precedenti + e di permettere il recupero da perdite accidentali tramite la messa in sicurezza di baseline. + La baseline indica una base verificata, approvata e garantita di un insieme di CI dalla quale non si può + retrocedere. +
+ Una + milestone + è associata ad uno specifico insieme di baseline e indica un valore strategico nel tempo. +
Una milestone di buona qualità deve essere:

+

Gestione delle modifiche

-Nel corso di un progetto è ragionevole pensare si abbia la necessità di apportare delle modifiche che possono avere origine da varie fonti: -dagli utenti e dagli sviluppatori per difetti o mancanze o dall'analisi della competizione per apportare valore aggiunto. -Le richieste di modifica vanno però sottoposte ad un processo rigoroso di analisi, decisione, realizzazione e verifica in cui -la richiesta di modifica va presentata in modo formale tenendone traccia con issue tracking o ticketing. -
-Va quindi gestita con attenzione allo stato corrente e all'eventuale stato di chiusura, tenendo traccia dello stato precedente tramite -controllo di versione (change request). + Nel corso di un progetto è ragionevole pensare si abbia la necessità di apportare delle modifiche che possono avere + origine da varie fonti: + dagli utenti e dagli sviluppatori per difetti o mancanze o dall'analisi della competizione per apportare valore + aggiunto. + Le richieste di modifica vanno però sottoposte ad un processo rigoroso di analisi, decisione, realizzazione e + verifica in cui + la richiesta di modifica va presentata in modo formale tenendone traccia con issue tracking o ticketing. +
+ Va quindi gestita con attenzione allo stato corrente e all'eventuale stato di chiusura, tenendo traccia dello stato + precedente tramite + controllo di versione (change request).

Controllo di versione

-Il controllo di versione deve basarsi su un repository, un database centralizzato su cui risiedono tutti i CI di ogni baseline e la loro storia completa. -In questo modo è possibile lavorare in contemporanea su vecchi e nuovi CI, senza rischio di sovrascritture accidentali, -ma con la possibilità di condividere il lavoro nello spazio comune e verificare la bontà di ogni modifica alla baseline. -
-Il controllo di versione può portare a diversi risultati: -una versione è un'istanza di prodotto funzionalmente distinta dalle altre; una variante è un'istanza del prodotto funzionalmente identica ma diversa per caratteristiche non funzionali; -una release è un'istanza di prodotto resa disponibile a utenti esterni. -
-Tutte queste istanze vengono identificate per numero, caratteristiche e modifiche e vanno pianificate e gestite. + Il controllo di versione deve basarsi su un repository, un database centralizzato su cui risiedono tutti i CI di + ogni baseline e la loro storia completa. + In questo modo è possibile lavorare in contemporanea su vecchi e nuovi CI, senza rischio di sovrascritture + accidentali, + ma con la possibilità di condividere il lavoro nello spazio comune e verificare la bontà di ogni modifica alla + baseline. +
+ Il controllo di versione può portare a diversi risultati: + una versione è un'istanza di prodotto funzionalmente distinta dalle altre; una variante è un'istanza + del prodotto funzionalmente identica ma diversa per caratteristiche non funzionali; + una release è un'istanza di prodotto resa disponibile a utenti esterni. +
+ Tutte queste istanze vengono identificate per numero, caratteristiche e modifiche e vanno pianificate e gestite.

- + \ No newline at end of file diff --git a/src/cAnalisiDinamica.html b/src/cAnalisiDinamica.html index bc2613f..e88efca 100644 --- a/src/cAnalisiDinamica.html +++ b/src/cAnalisiDinamica.html @@ -2,37 +2,48 @@

Analisi Dinamica

Definizione

-L'analisi dinamica è l'esecuzione di test(prove) che verificano il comportamento dinamico del programma in alcune sue esecuzioni, quindi avviene definendo un insieme finito di casi ciascuno dei quali prevede alcuni valori di ingresso e assume uno stato iniziale del sistema. -Dato che il dominio di tutte le esecuzioni possibili tende all'infinito i test non garantiscono l'esaustività e infatti un test cerca di produrre un esito decidibile(oracolo) da verificare rispetto al comportamento atteso. -
-Dunque l'analisi dinamica può rilevare la presenza di malfunzionamenti ma non può dimostrarne l'assenza. + L'analisi dinamica è l'esecuzione di test(prove) che verificano il comportamento dinamico del programma in alcune + sue esecuzioni, quindi avviene definendo un insieme finito di casi ciascuno dei quali prevede alcuni valori di + ingresso e assume uno stato iniziale del sistema. + Dato che il dominio di tutte le esecuzioni possibili tende all'infinito i test non garantiscono l'esaustività e + infatti un test cerca di produrre un esito decidibile(oracolo) da verificare rispetto al comportamento atteso. +
+ Dunque l'analisi dinamica può rilevare la presenza di malfunzionamenti ma non può dimostrarne l'assenza.

-Una prova è il processo di eseguire un programma con -l’intento di trovarvi difetti. -
-The Art of Software Testing, G.J. Myers, Wiley-Interscience, 1979 -
+ Una prova è il processo di eseguire un programma con + l’intento di trovarvi difetti. +
+ The Art of Software Testing, G.J. Myers, Wiley-Interscience, 1979 +

-L'analisi dinamica produce una misura della qualità del sistema. -
-L'attività di testing è parte essenziale del processo di verifica e come tale va pianificata nelle varie forme non appena possibile, seguendo come riferimento il modello a V, a monte della codifica. -È importante avere una visione lungimirante delle esigenze legate ad essa, tenendone conto durante la progettazione del sistema. -
-I test vanno eseguiti in parallelo all'attività di codifica e non solamente al suo termine. -
-I test sono onerosi in quanto richiedono molte risorse umane e infrastrutturali, necessitano di processi definiti e richiedono attività di ricerca, analisi e correzione. + L'analisi dinamica produce una misura della qualità del sistema. +
+ L'attività di testing è parte essenziale del processo di verifica e come tale va pianificata + nelle varie forme non appena possibile, seguendo come riferimento il modello a V, a monte della codifica. + È importante avere una visione lungimirante delle esigenze legate ad essa, tenendone conto durante la progettazione + del sistema. +
+ I test vanno eseguiti in parallelo all'attività di codifica e non solamente al suo termine. +
+ I test sono onerosi in quanto richiedono molte risorse umane e infrastrutturali, necessitano di processi definiti e + richiedono attività di ricerca, analisi e correzione.

-Ciò che cerchiamo tramite test sono failure (malfunzionamenti). -Un malfunzionamento si verifica quando il comportamento del sistema non corrisponde a quello atteso. -Un malfunzionamento ha origine da un error -(errore) che è un problema interno al sistema e a sua volta la sua causa meccanica, algoritmica o concettuale deriva da un fault(guasto). -
-Gli errori sono dunque stati del sistema mentre i guasti ne sono la causa. I sistemi si possono vedere come composizioni gerarchiche di sottosistemi, per cui malfunzionamento di una componente interna può scatenare un guasto per le componenti di più alto livello. + Ciò che cerchiamo tramite test sono failure (malfunzionamenti). + Un malfunzionamento si verifica quando il comportamento del sistema non corrisponde a quello atteso. + Un malfunzionamento ha origine da un error + (errore) che è un problema interno al sistema e a sua volta la sua causa meccanica, algoritmica o concettuale deriva + da un fault(guasto). +
+ Gli errori sono dunque stati del sistema mentre i guasti ne sono la causa. I sistemi si possono vedere come + composizioni gerarchiche di sottosistemi, per cui malfunzionamento di una componente interna può scatenare un guasto + per le componenti di più alto livello.

@@ -40,159 +51,204 @@

Definizione

Strategie

-La strategia nel definire le prove punta a perseguire la quantità minima di test sufficienti a fornire certezza adeguata sulla qualità del prodotto, sfruttando la quantità di sforzo, tempo e risorse allocate per la verifica. -
-Lo sforzo non deve comunque essere eccessivo poiché per la legge del rendimento decrescente superata una certa soglia di risorse impiegate, il loro rapporto con i benefici ottenuti non è vantaggioso. -
-
-Dei criteri guida da seguire nella definizione dei test riguardano la classificazione dell'obiettivo della prova, che va specificata per ogni caso di test in termini precisi e quantitativi e va inserita nel Piano di Qualità e -la definizione di prove che devono essere ripetibili poiché la loro esecuzione va effettuata più volte durante l'integrazione di più componenti. -
-Va comunque ricordato che secondo il teorema di Howden non esiste un algoritmo che dato un programma ne individui un set di test finito e ideale. + La strategia nel definire le prove punta a perseguire la quantità minima di test sufficienti a fornire certezza + adeguata sulla qualità del prodotto, sfruttando la quantità di sforzo, tempo e risorse allocate per la verifica. +
+ Lo sforzo non deve comunque essere eccessivo poiché per la legge del rendimento decrescente superata una certa + soglia di risorse impiegate, il loro rapporto con i benefici ottenuti non è vantaggioso. +
+
+ Dei criteri guida da seguire nella definizione dei test riguardano la classificazione dell'obiettivo della + prova, che va specificata per ogni caso di test in termini precisi e quantitativi e va inserita nel Piano di + Qualità e la definizione di prove che devono essere ripetibili poiché la loro esecuzione va effettuata più volte + durante l'integrazione di più componenti. +
+ Va comunque ricordato che secondo il teorema di Howden non esiste un algoritmo che dato un programma ne individui un + set di test finito e ideale.

Test

-Come già specificato un test ha lo scopo di far fallire il programma e quando ci riesce deve essere aggiunto quel caso di test alla suite di test del progetto in modo permanente. -I test non sono sostitutivi delle specifiche del programma, -ma i loro oracoli andrebbero inseriti come commento nel codice in modo da utilizzarli come "contratti" di metodo. -
-Una strategia di testing deve prevedere un processo di testing riproducibile e valutabile oggettivamente tramite criteri definiti. -Una strategia di testing è tanto più buona tanti più malfunzionamenti individua in un dato lasso di tempo. - -

-

-La definizione di un caso di prova prevede la specifica di tre elementi: dati in ingresso, dati in uscita e l'ambiente d'esecuzione che comprende anche l'oggetto della prova. -Per un progetto vengono definite delle batterie di prove che sono un insieme di casi di prova. -
-La prova nel suo complesso consiste nell'eseguire una batteria di prove secondo una procedura di prova -che è il procedimento, possibilmente automatizzato, -per eseguire, -registrare, analizzare e valutare i risultati di prove. -
-
-A supporto dell'analisi dinamica vengono usati tre strumenti: + Come già specificato un test ha lo scopo di far fallire il programma e quando ci riesce deve essere aggiunto quel + caso di test alla suite di test del progetto in modo permanente. + I test non sono sostitutivi delle specifiche del programma, + ma i loro oracoli andrebbero inseriti come commento nel codice in modo da utilizzarli come "contratti" di metodo. +
+ Una strategia di testing deve prevedere un processo di testing riproducibile e valutabile oggettivamente tramite + criteri definiti. + Una strategia di testing è tanto più buona tanti più malfunzionamenti individua in un dato lasso di tempo. +

+

+ La definizione di un caso di prova prevede la specifica di tre elementi: dati in ingresso, dati in uscita e + l'ambiente d'esecuzione che comprende anche l'oggetto della prova. + Per un progetto vengono definite delle batterie di prove che sono un insieme di casi di prova. +
+ La prova nel suo complesso consiste nell'eseguire una batteria di prove secondo una procedura + di prova + che è il procedimento, possibilmente automatizzato, per eseguire, registrare, analizzare e valutare i risultati di prove. +
+
+ A supporto dell'analisi dinamica vengono usati tre strumenti:

-Per convalidare i risultati ottenuti dai test si usano degli oracoli che generano a priori i risultati attesi, generalmente applicati da agenti automatici per velocizare e rendere oggettiva la convalida. + Per convalidare i risultati ottenuti dai test si usano degli oracoli che generano a priori i risultati attesi, + generalmente applicati da agenti automatici per velocizzare e rendere oggettiva la convalida.

-I test sono definiti e successivamente eseguiti in ordine preciso definito dal modello a V. + I test sono definiti e successivamente eseguiti in ordine preciso definito dal modello a V.

Test di unità

-I test di unità si occupano di testare le unità software e i relativi moduli e vanno definiti durante la progettazione di dettaglio. -Circa i 2/3 dei difetti trovati dall'analisi dinamica derivano da questa tipologia di test. -
-I test di unità possono essere funzionali(black-box) che facendo riferimento alla specifica dell'unità utilizzano dei dati in ingresso che portino ad un dato comportamento funzionale. -Per la scelta dei dati in ingresso vengono definite delle classi di equivalenza che raggruppino insiemi di dati che porterebbero al medesimo comportamento. -
- -Da soli i test funzionali non bastano per accertare la correttezza della logica interna e vengono dunque affiancati da test strutturali(white-box). -Questi test verificano la logica interna dell'unità cercando di percorrere ogni cammino di esecuzione interno al modulo(massima copertura) e la loro esecuzione può essere facilitata dall'uso di debugger. -
-Il testing di unità è completo quando tutte le unità sono state verificate e può portare a diversi livelli di copertura spiegati successivamente. + I test di unità si occupano di testare le unità software e i relativi moduli e vanno + definiti durante la progettazione di dettaglio. + Circa i 2/3 dei difetti trovati dall'analisi dinamica derivano da questa tipologia di test. +
+ I test di unità possono essere funzionali (black-box) che facendo riferimento alla specifica dell'unità utilizzano + dei dati in ingresso che portino ad un dato comportamento funzionale. + Per la scelta dei dati in ingresso vengono definite delle classi di equivalenza che raggruppino insiemi di dati che + porterebbero al medesimo comportamento. +
+ + Da soli i test funzionali non bastano per accertare la correttezza della logica interna e vengono dunque affiancati + da test strutturali (white-box). + Questi test verificano la logica interna dell'unità cercando di percorrere ogni cammino di esecuzione interno al + modulo (massima copertura) e la loro esecuzione può essere facilitata dall'uso di debugger. +
+ Il testing di unità è completo quando tutte le unità sono state verificate e può portare a diversi livelli di + copertura spiegati successivamente.

Test di integrazione

-I test di integrazione si applicano per testare la corretta interazione tra le componenti del sistema. -Essi vengono definiti durante la progettazione architetturale e si basano sui componenti in essa specificati. -
-Per definire i test di integrazione è necessario selezionare -quali funzionalità integrare individuandone le componenti coinvolte e ordinandole per dipendenze crescenti. -
-I problemi rilevati dai test di integrazione rappresentano difetti di progettazione o una scarsa qualità dei test di unità. -Il numero dei test di integrazione è il necessario per accertare che i dati scambiati tra interfacce siano conformi e che i flussi di controllo siano tutti testati e funzionanti. -

-

-L'integrazione delle componenti può avvenire assemblando prima i componenti produttori e poi i consumatori, in modo da verificare che i primi forniscano un flusso di controllo e di dati corretto ai secondi; -in alternativa si procede assemblando le parti in modo che ogni passo sia reversibile; l'ultimo approccio è incrementale e prevede l'aggiunta ad insiemi già ben verificati, motivo per cui eventuali difetti sono probabilmente da attribuire alle ultime parti aggiunte. -
-Nell'integrazione incrementale si può procedere con modalità bottom-up decidendo di integrare prima le parti con minore dipendenza funzionale e maggiore utilità. -In questo modo sono necessari meno stub ma si arriva tardi alle funzionalità di alto livello. -In alternativa con l'approccio top-down si parte dalle parti più esterne utilizzando molti stub per simulare le componenti mancanti, integrando cosi subito le funzionalità di alto livello. + I test di integrazione si applicano per testare la corretta interazione tra le componenti del sistema. + Essi vengono definiti durante la progettazione architetturale e si basano sui componenti in essa specificati. +
+ Per definire i test di integrazione è necessario selezionare + quali funzionalità integrare individuandone le componenti coinvolte e ordinandole per dipendenze crescenti. +
+ I problemi rilevati dai test di integrazione rappresentano difetti di progettazione o una scarsa qualità dei test di + unità. + Il numero dei test di integrazione è il necessario per accertare che i dati scambiati tra interfacce siano conformi + e che i flussi di controllo siano tutti testati e funzionanti. +

+

+ L'integrazione delle componenti può avvenire assemblando prima i componenti produttori e poi i consumatori, in modo + da verificare che i primi forniscano un flusso di controllo e di dati corretto ai secondi; + in alternativa si procede assemblando le parti in modo che ogni passo sia reversibile; l'ultimo approccio è + incrementale e prevede l'aggiunta ad insiemi già ben verificati, motivo per cui eventuali difetti sono probabilmente + da attribuire alle ultime parti aggiunte. +
+ Nell'integrazione incrementale si può procedere con modalità bottom-up decidendo di integrare prima le parti + con minore dipendenza funzionale e maggiore utilità. + In questo modo sono necessari meno stub ma si arriva tardi alle funzionalità di alto livello. + In alternativa con l'approccio top-down si parte dalle parti più esterne utilizzando molti stub per + simulare le componenti mancanti, integrando cosi subito le funzionalità di alto livello.

Test di sistema

-I test di sistema sono test funzionali e verificano il comportamento dinamico del sistema nel suo complesso rispetto ai requisiti individuati. -Essi vengono definiti durante l'analisi dei requisiti ma hanno inizio solo con il completamento dei test di integrazione. + I test di sistema sono test funzionali e verificano il comportamento dinamico del sistema nel suo complesso rispetto + ai requisiti individuati. + Essi vengono definiti durante l'analisi dei requisiti ma hanno inizio solo con il completamento dei test di + integrazione.

Test di validazione

-I test di validazione(accettazione/collaudo) accertano il soddisfacimento dei requisiti richiesti dal proponente. - -Essi possono essere definiti già a partire dal capitolato. - + I test di validazione (accettazione/collaudo) accertano il soddisfacimento dei requisiti richiesti dal proponente. + Essi possono essere definiti già a partire dal capitolato.

Test di regressione

-I test di regressione prevedono la ripetizione selettiva di test di integrazione ed eventualmente di sistema al fine accertare che eventuali modifiche derivanti da correzioni o estensioni del sistema non abbiano introdotto errori.
-Essi vanno decisi nel -momento in cui si approvano modifiche al software ma vanno eseguiti solo in seguito al superamento dei test di unità legati alle componenti coinvolte. + I test di regressione prevedono la ripetizione selettiva di test di integrazione ed eventualmente di sistema al fine + accertare che eventuali modifiche derivanti da correzioni o estensioni del sistema non abbiano introdotto errori. +
+ Essi vanno decisi nel momento in cui si approvano modifiche al software ma vanno eseguiti solo in seguito al superamento + dei test di unità legati alle componenti coinvolte.

Copertura

-I test di unità portano ad avere una determinata copertura -del codice sorgente. -
-La copertura può essere funzionale se cerca la percentuale di funzionalità richieste effettivamente testate o strutturale se cerca la percentuale di logica interna testata. - -
-La copertura va massimizzata ma seguendo un criterio di copertura in base a quante risorse si vogliono impiegare per i test. -Va comunque ricordato che una copertura del 100% non garantisce assenza di difetti e a volte non è raggiungibile per problemi come: costi eccessivi, codice sorgente non disponibile e codice irraggiungibile ma non eliminabile. - -
-
- -Function coverage
-Controlla quante funzioni(sotto-procedure) sono state eseguite. -
-
-Statement coverage
-Controlla quante istruzioni sono state eseguite nel corso dell'esecuzione di vari cammini del programma. -(num. righe codice) -
-
-Branch coverage
-Controlla quanti rami distinti d'esecuzione del programma sono stati eseguiti. -La branch coverage è più potente della statement coverage in quanto testa per ogni istruzione condizionale entrambi i casi anche se ciò non porta ad esaminare un numero maggiore di linee di codice. -(i.e. rami if senza else che lo statement coverage può testare solo con la condizione true) -
- -
-Condition coverage
-Controlla quanti valori possibili di espressioni logiche sono stati effettivamente testati. -È la più stringente in quanto non basta testare la decisione finale di un'espressione condizionale ma obbliga anche a testare ogni decisione atomica al suo interno(condizione). -Spesso massimizzare questa tipologia di coverage diventa troppo oneroso. -
-Una via di mezzo tra condition e branch coverage è la Modified Decision Condition Coverage che non testa ogni singola condizione ma garantisce che ogni possibile output ottenibile a seguito di una decisione sia coperto da test. + I test di unità portano ad avere una determinata copertura del codice sorgente. +
+ La copertura può essere funzionale se cerca la percentuale di funzionalità richieste effettivamente testate o + strutturale se cerca la percentuale di logica interna testata. + +
+ La copertura va massimizzata ma seguendo un criterio di copertura in base a quante risorse si vogliono impiegare per + i test. + Va comunque ricordato che una copertura del 100% non garantisce assenza di difetti e a volte non è raggiungibile per + problemi come: costi eccessivi, codice sorgente non disponibile e codice irraggiungibile ma non eliminabile. + +
+
+ + Function coverage
+ Controlla quante funzioni(sotto-procedure) sono state eseguite. +
+
+ Statement coverage
+ Controlla quante istruzioni sono state eseguite nel corso dell'esecuzione di vari cammini del programma. + (num. righe codice) +
+
+ Branch coverage
+ Controlla quanti rami distinti d'esecuzione del programma sono stati eseguiti. + La branch coverage è più potente della statement coverage in quanto testa per ogni istruzione condizionale entrambi + i casi anche se ciò non porta ad esaminare un numero maggiore di linee di codice. + (i.e. rami if senza else che lo statement coverage può testare solo con la condizione true) +
+ +
+ Condition coverage
+ Controlla quanti valori possibili di espressioni logiche sono stati effettivamente testati. + È la più stringente in quanto non basta testare la decisione finale di un'espressione condizionale ma obbliga anche + a testare ogni decisione atomica al suo interno(condizione). + Spesso massimizzare questa tipologia di coverage diventa troppo oneroso. +
+ Una via di mezzo tra condition e branch coverage è la Modified Decision Condition Coverage che non testa ogni + singola condizione ma garantisce che ogni possibile output ottenibile a seguito di una decisione sia coperto da + test.

Maturità di prodotto

-Tramite l'analisi dinamica si può stimare il grado di evoluzione del prodotto, analizzando quanto esso migliora in seguito alle prove, quanto la densità dei difetti residui diminuisce e quanto può costare la scoperta di ulteriori difetti. -
-Per perseguire la maturità di prodotto è sconsigliato l'uso di tecniche empiriche come code-n'-fix, -ma è ideale definire un modello per questa stima. -Due modelli standard sono quello base e quello logaritmico; il primo prevede un numero di difetti del software stimato come costante iniziale mentre il secondo assume che le modifiche successive possano introdurre difetti. + Tramite l'analisi dinamica si può stimare il grado di evoluzione del prodotto, analizzando quanto esso migliora in + seguito alle prove, quanto la densità dei difetti residui diminuisce e quanto può costare la scoperta di ulteriori + difetti. +
+ Per perseguire la maturità di prodotto è sconsigliato l'uso di tecniche empiriche come code-n'-fix, + ma è ideale definire un modello per questa stima. + Due modelli standard sono quello base e quello logaritmico; il primo prevede un numero di difetti del software + stimato come costante iniziale mentre il secondo assume che le modifiche successive possano introdurre difetti.

diff --git a/src/cAnalisiStatica.html b/src/cAnalisiStatica.html index 695ff75..c8d1b88 100644 --- a/src/cAnalisiStatica.html +++ b/src/cAnalisiStatica.html @@ -2,122 +2,161 @@

Analisi Statica

Definizione

-Un software di buona qualità deve possedere tutte le caratteristiche previste e per determinare ciò deve essere verificato il possesso di determinate proprietà di costruzione, d'uso e di funzionamento. -I costrutti(del linguaggio scelto) da utilizzare per adempiere a tali proprietà vanno scelti in base al loro impatto in relazione al costo di verifica. -
-La verifica solo retrospettiva (a valle dello -sviluppo) è inutile. -
-Poiché il costo di rilevazione e correzione di un errore cresce con il grado di sviluppo del prodotto, posticipare la verifica porta al raggiungimento della correttezza by correction, cosa inadeguata, mentre far accompagnare la produzione dalla verifica è un approccio costruttivo che porta alla correttezza della soluzione by construction. + Un software di buona qualità deve possedere tutte le caratteristiche previste e per determinare ciò deve essere + verificato il possesso di determinate proprietà di costruzione, d'uso e di funzionamento. + I costrutti (del linguaggio scelto) da utilizzare per adempiere a tali proprietà vanno scelti in base al loro impatto + in relazione al costo di verifica. +
+ La verifica solo retrospettiva (a valle dello sviluppo) è inutile. +
+ Poiché il costo di rilevazione e correzione di un errore cresce con il grado di sviluppo del prodotto, posticipare + la verifica porta al raggiungimento della correttezza by correction, cosa inadeguata, mentre far accompagnare + la produzione dalla verifica è un approccio costruttivo che porta alla correttezza della soluzione by + construction.

Premesse all'analisi statica

-Un aspetto da verificare nell'analisi statica è la presenza di comportamenti predicibili nel codice sorgente, che deve dunque evitare di avere ambiguità. -Per ottenere ciò una stessa funzione non deve portare a risultati diversi a partire da invocazioni similari, l'andamento del programma non deve dipendere dall'ordine di elaborazione(attenzione ai thread) e -la modalità del passaggio dei parametri deve essere coerente con il comportamento atteso. + Un aspetto da verificare nell'analisi statica è la presenza di comportamenti predicibili nel codice sorgente, + che deve dunque evitare di avere ambiguità. + Per ottenere ciò una stessa funzione non deve portare a risultati diversi a partire da invocazioni similari, + l'andamento del programma non deve dipendere dall'ordine di elaborazione(attenzione ai thread) e + la modalità del passaggio dei parametri deve essere coerente con il comportamento atteso.

-La verificabilità di un programma dipende anche da scelte di strutturazione del codice, -tenendo a mente che più grande è la dimensione del contesto(scope e visibilità) minore è la sua verificabilità, mentre la definizione di una buona architettura facilita la verifica. -
-Per ottenere tale risultato è bene separare l'interfaccia dall'implementazione, massimizzare l'incapsulamento che aiuta a restringere lo scope e usare tipi specializzati per i dati tramite composizioni e specializzazioni. -L'architettura creata va dunque seguita con attenzione durante la codifica. + La verificabilità di un programma dipende anche da scelte di strutturazione del codice, + tenendo a mente che più grande è la dimensione del contesto(scope e visibilità) minore è la sua + verificabilità, mentre la definizione di una buona architettura facilita la verifica. +
+ Per ottenere tale risultato è bene separare l'interfaccia dall'implementazione, massimizzare l'incapsulamento che + aiuta a restringere lo scope e usare tipi specializzati per i dati tramite composizioni e specializzazioni. + L'architettura creata va dunque seguita con attenzione durante la codifica.

-La dimostrazione della completezza e dell'economicità della soluzione viene supportata dal tracciamento, -che deve essere altamente automatizzato e viene creato durante lo sviluppo(ramo discendente del modello a V) -e serve poi durante ogni passaggio della verifica(ramo ascendente del modello a V).
+ La dimostrazione della completezza e dell'economicità della soluzione viene supportata dal tracciamento, + che deve essere altamente automatizzato e viene creato durante lo sviluppo(ramo discendente del modello a V) + e serve poi durante ogni passaggio della verifica(ramo ascendente del modello a V).
-Per facilitare il tracciamento un buon stile di programmazione è assegnare a singoli moduli dei requisiti elementari poiché maggiore è l'astrazione -di un costrutto maggiore è la difficoltà di associarlo ad un requisito. + Per facilitare il tracciamento un buon stile di programmazione è assegnare a singoli moduli dei requisiti elementari + poiché maggiore è l'astrazione + di un costrutto maggiore è la difficoltà di associarlo ad un requisito.

Inspection & Walkthrough

-Si tratta di metodi pratici di analisi statica basati su lettura della documentazione del prodotto la cui -efficacia -dipende dall'esperienza dei verificatori nell'organizzare le attività di verifica e nel documentarle con i risultati ottenuti. + Si tratta di metodi pratici di analisi statica basati su lettura della documentazione del prodotto la cui + efficacia + dipende dall'esperienza dei verificatori nell'organizzare le attività + di verifica e nel documentarle con i risultati ottenuti.

-Le due metodologie sono entrambe dei controlli di tipo desk check, documentati formalmente e che coinvolgono programmatori e verificatori. -Di contro, walkthrough richiede maggiore attenzione e un lavoro collaborativo, mentre inspection risulta più rapido ma si basa su errori presupposti e dunque può rilevare solo alcuni errori. + Le due metodologie sono entrambe dei controlli di tipo desk check, documentati formalmente e che coinvolgono + programmatori e verificatori. + Di contro, walkthrough richiede maggiore attenzione e un lavoro collaborativo, mentre inspection risulta più rapido + ma si basa su errori presupposti e dunque può rilevare solo alcuni errori.

Tipi di analisi statica

-L'analisi statica costruisce modelli astratti del software in esame in cui ogni modello rappresenta un programma -come un grafo diretto e ne studia i possibili cammini mettendo etichette agli archi che descrivono proprietà sintattiche o semantiche dell'istruzione corrispondente. -Ciascun flusso di controllo(thread) viene rappresentato separatamente assumendo che non interferisca con altri. -
- -Ci sono molti tipi di analisi statica: -
-
- -1. Analisi di flusso di controllo
-Si accerta che il codice sia ben strutturato ed esegua nella sequenza specificata individuando eventuali punti di codice non raggiungibili o che portano a non terminazione. -

- -2. Analisi di flusso dei dati
-Si accerta che non esistano cammini d'esecuzione associati a variabili prive di valore rilevando possibili anomalie nella consistenza dei dati. -

- -3. Analisi di flusso dell'informazione
-Determina quali dipendenze tra ingressi e uscite sono presenti durante l'esecuzione di un'unità di codice, accertandosi che siano corrispondenti a quelle previste dalla specifica. -

- -4. Esecuzione simbolica
-Verifica proprietà del programma mediante -manipolazione algebrica del codice sorgente combinando le tre tecniche precedenti e effettuando sostituzioni inverse in cui gli output sono in funzione degli input. -

- -5. Verifica formale del codice
-Fornisce le prove di correttezza del codice sorgente rispetto alla specifica dei requisiti eventualmente in modo parziale supponendo determinate pre e post condizioni. -

- -6. Analisi di limite
-Verifica che i dati non sforino i limiti imposti dalla precisione del loro tipo. -

- -7. Analisi uso dello stack
-Determina la massima richiesta di stack relativa ad un'esecuzione del programma in relazione con -la dimensione dell’area di memoria -assegnata al processo, assicurandosi che non ci sia collisione tra stack e heap. -

- -8. Analisi temporale
-Analizza le dipendenze temporali richieste da diverse parti del programma. - -

- -9. Analisi d'interferenza
-Assicura l'assenza di side-effect da parte di parti separate del sistema. -

- -10. Analisi del codice oggetto
-Assicura che il codice oggetto sia una corretta traduzione del codice sorgente corrispondente e che non siano stati introdotti errori dal compilatore. + L'analisi statica costruisce modelli astratti del software in esame in cui ogni modello rappresenta un programma + come un grafo diretto e ne studia i possibili cammini mettendo etichette agli archi che descrivono proprietà + sintattiche o semantiche dell'istruzione corrispondente. + Ciascun flusso di controllo(thread) viene rappresentato separatamente assumendo che non interferisca con altri. +
+ + Ci sono molti tipi di analisi statica: +
+
+ + 1. Analisi di flusso di controllo
+ Si accerta che il codice sia ben strutturato ed esegua nella sequenza specificata individuando eventuali punti di + codice non raggiungibili o che portano a non terminazione. +

+ + 2. Analisi di flusso dei dati
+ Si accerta che non esistano cammini d'esecuzione associati a variabili prive di valore rilevando possibili anomalie + nella consistenza dei dati. +

+ + 3. Analisi di flusso dell'informazione
+ Determina quali dipendenze tra ingressi e uscite sono presenti durante l'esecuzione di un'unità + di codice, accertandosi che siano corrispondenti a quelle previste dalla specifica. +

+ + 4. Esecuzione simbolica
+ Verifica proprietà del programma mediante + manipolazione algebrica del codice sorgente combinando le tre tecniche precedenti e effettuando sostituzioni inverse + in cui gli output sono in funzione degli input. +

+ + 5. Verifica formale del codice
+ Fornisce le prove di correttezza del codice sorgente rispetto alla specifica dei requisiti eventualmente in modo + parziale supponendo determinate pre e post condizioni. +

+ + 6. Analisi di limite
+ Verifica che i dati non sforino i limiti imposti dalla precisione del loro tipo. +

+ + 7. Analisi uso dello stack
+ Determina la massima richiesta di stack relativa ad un'esecuzione del programma in relazione con + la dimensione dell’area di memoria + assegnata al processo, assicurandosi che non ci sia collisione tra stack e heap. +

+ + 8. Analisi temporale
+ Analizza le dipendenze temporali richieste da diverse parti del programma. + +

+ + 9. Analisi d'interferenza
+ Assicura l'assenza di side-effect da parte di parti separate del sistema. +

+ + 10. Analisi del codice oggetto
+ Assicura che il codice oggetto sia una corretta traduzione del codice sorgente corrispondente e che non siano stati + introdotti errori dal compilatore.



diff --git a/src/cCardin.html b/src/cCardin.html index 49bae18..b92f6bb 100644 --- a/src/cCardin.html +++ b/src/cCardin.html @@ -4,621 +4,726 @@

Cardin

Design Pattern

-
-

Adapter

-
-
-
-

- Il pattern Adapter converte l'interfaccia di una classe in un'altra. Si può applicare quando si vuole -utilizzare una classe esistente, ma la sua interfaccia non corrisponde a quella voluta. -Il pattern Adapter esiste in due varianti. -

-

-

- Class Adapter
- Il Class Adapter utilizza l'ereditarietà multipla per adattare un'interfaccia ad un'altra.
- Il Class Adapter adatta Adaptee a Target attraverso una specifica classe concreta Adapter; -questo non è sufficiente se si vuole adattare una classe e tutte le sue sottoclassi. Per contro, -però, permette di ridefinire parte del comportamento di Adaptee con il subclassing, e introduce -solamente un oggetto (Adapter), senza ulteriore indirezione per raggiungere l'oggetto da adattare. -

-

- Object Adapter
- L'Object Adapter utilizza la composizione per adattare un'interfaccia ad -un'altra. Permette di adattare una classe e tutte le sue sottoclassi, ma rende più difficoltoso -modificare il comportamento dell'Adaptee. -

-
-
+
+

Adapter

+
+
+
+

+ Il pattern Adapter converte l'interfaccia di una classe in un'altra. Si può applicare quando si vuole + utilizzare una classe esistente, ma la sua interfaccia non corrisponde a quella voluta. + Il pattern Adapter esiste in due varianti. +

+

+

+ Class Adapter
+ Il Class Adapter utilizza l'ereditarietà multipla per adattare un'interfaccia ad un'altra.
+ Il Class Adapter adatta Adaptee a Target attraverso una specifica classe concreta Adapter; + questo non è sufficiente se si vuole adattare una classe e tutte le sue sottoclassi. Per contro, + però, permette di ridefinire parte del comportamento di Adaptee con il subclassing, e introduce + solamente un oggetto (Adapter), senza ulteriore indirezione per raggiungere l'oggetto da adattare. +

+

+ Object Adapter
+ L'Object Adapter utilizza la composizione per adattare un'interfaccia ad + un'altra. Permette di adattare una classe e tutte le sue sottoclassi, ma rende più difficoltoso + modificare il comportamento dell'Adaptee. +

+
+
-
-

Abstract Factory

-
-
-
-

- Il pattern Abstract Factory fornisce un'interfaccia per la creazione di famiglie di oggetti - correlati e dipendenti tra loro senza specificare le loro classi concrete.
- Il pattern può essere applicato quando: un sistema deve essere indipendente da come i suoi prodotti vengono creati, aggregati e rappresentati; un sistema deve interfacciarsi con molteplici famiglie di prodotti, dotate di interfaccia comune; degli oggetti sono progettati per essere utilizzati insieme, e si vuole imporre tale vincolo; si vuole esporre solo l'interfaccia di un gruppo di oggetti in una libreria di classi. -

-

-

- Ogni famiglia di prodotti è creata da un'apposita ConcreteFactory, che il codice client accede - attraverso l'interfaccia di AbstractFactory. Solitamente, un solo ConcreteFactory viene creato a run-time. -

-

- Vantaggi
- Le classi concrete vengono isolate dal client, inoltre è possibile cambiare la configurazione di prodotti semplicemente cambiando la Concrete-Factory che viene istanziata. Infine si può promuove consistenza tra i prodotti, imponendo che oggetti della stessa famiglia vengano - usati insieme. -

-

- Svantaggi
- Tipicamente, l'interfaccia di AbstractFactory espone una serie di metodi factory - che si occupano di costruire ogni oggetto della famiglia. Ogni classe concreta specifica i suoi - prodotti definendo l'implementazione di tali metodi. Questa implementazione è semplice, ma ha - lo svantaggio di richiedere un una nuova ConcreteFactory e una completa ridefinizione dei metodi - factory per ogni famiglia di prodotti, anche se alcune famiglie differiscono tra loro solo in alcuni - dettagli.
- Un altro svantaggio dell'Abstract Factory sta nella difficoltà di aggiungere nuove classi di - prodotti. L'interfaccia di AbstractFactory fissa l'insieme di prodotti che possono essere creati, e - aggiungerne di nuovi implica la modifica della classe AbstractFactory e di tutte le ConcreteFactory - che la ereditano. -

-
-
+
+

Abstract Factory

+
+
+
+

+ Il pattern Abstract Factory fornisce un'interfaccia per la creazione di famiglie di oggetti + correlati e dipendenti tra loro senza specificare le loro classi concrete.
+ Il pattern può essere applicato quando: un sistema deve essere indipendente da come i suoi prodotti + vengono creati, aggregati e rappresentati; un sistema deve interfacciarsi con molteplici famiglie di + prodotti, dotate di interfaccia comune; degli oggetti sono progettati per essere utilizzati insieme, e + si vuole imporre tale vincolo; si vuole esporre solo l'interfaccia di un gruppo di oggetti in una + libreria di classi. +

+

+

+ Ogni famiglia di prodotti è creata da un'apposita ConcreteFactory, che il codice client accede + attraverso l'interfaccia di AbstractFactory. Solitamente, un solo ConcreteFactory viene creato a + run-time. +

+

+ Vantaggi
+ Le classi concrete vengono isolate dal client, inoltre è possibile cambiare la configurazione di + prodotti semplicemente cambiando la Concrete-Factory che viene istanziata. Infine si può promuove + consistenza tra i prodotti, imponendo che oggetti della stessa famiglia vengano + usati insieme. +

+

+ Svantaggi
+ Tipicamente, l'interfaccia di AbstractFactory espone una serie di metodi factory + che si occupano di costruire ogni oggetto della famiglia. Ogni classe concreta specifica i suoi + prodotti definendo l'implementazione di tali metodi. Questa implementazione è semplice, ma ha + lo svantaggio di richiedere un una nuova ConcreteFactory e una completa ridefinizione dei metodi + factory per ogni famiglia di prodotti, anche se alcune famiglie differiscono tra loro solo in alcuni + dettagli.
+ Un altro svantaggio dell'Abstract Factory sta nella difficoltà di aggiungere nuove classi di + prodotti. L'interfaccia di AbstractFactory fissa l'insieme di prodotti che possono essere creati, e + aggiungerne di nuovi implica la modifica della classe AbstractFactory e di tutte le ConcreteFactory + che la ereditano. +

+
+
-
-

Builder

-
-
-
-

- Il pattern Builder serve per separare la costruzione di un oggetto complesso dalla sua rappresentazione, in modo che lo stesso processo di costruzione possa creare diverse rappresentazioni.
- Il pattern può essere applicato quando: l'algoritmo di creazione di un oggetto complesso dovrebbe essere indipendente dalle parti che compongono tale oggetto e come esse vengono assemblate; il processo di creazione deve permettere diverse rappresentazioni dell'oggetto che viene creato. -

-

-

- All'utilizzo di un pattern Builder prendono parte diverse entità: un client, un director, un - builder astratto, un builder concreto e un product, risultato del processo di creazione. - Il Client crea un oggetto Director e lo configura con il builder concreto desiderato. Il Director - utilizza tale builder, dietro interfaccia astratta, per costruire il prodotto, che viene restituito - dall'oggetto builder concreto al Client. -

-

- Vantaggi
- L'interfaccia del Builder parmette di nascondere la rappresentazione e la struttura interna - del prodotto, e come esso viene costruito. Per modificare la struttura interna del prodotto, - e sufficiente aggiungere un builder;
- isola il codice di rappresentazione e costruzione dei prodotti. Gli stessi ConcreteBuilder - possono essere utilizzati da più Director;
- il Builder costruisce il prodotto step-by-step, permettendo un controllo più fine sul processo di costruzione. -

- -
-
+
+

Builder

+
+
+
+

+ Il pattern Builder serve per separare la costruzione di un oggetto complesso dalla sua rappresentazione, + in modo che lo stesso processo di costruzione possa creare diverse rappresentazioni.
+ Il pattern può essere applicato quando: l'algoritmo di creazione di un oggetto complesso dovrebbe essere + indipendente dalle parti che compongono tale oggetto e come esse vengono assemblate; il processo di + creazione deve permettere diverse rappresentazioni dell'oggetto che viene creato. +

+

+

+ All'utilizzo di un pattern Builder prendono parte diverse entità: un client, un director, un + builder astratto, un builder concreto e un product, risultato del processo di creazione. + Il Client crea un oggetto Director e lo configura con il builder concreto desiderato. Il Director + utilizza tale builder, dietro interfaccia astratta, per costruire il prodotto, che viene restituito + dall'oggetto builder concreto al Client. +

+

+ Vantaggi
+ L'interfaccia del Builder permette di nascondere la rappresentazione e la struttura interna + del prodotto, e come esso viene costruito. Per modificare la struttura interna del prodotto, + e sufficiente aggiungere un builder;
+ isola il codice di rappresentazione e costruzione dei prodotti. Gli stessi ConcreteBuilder + possono essere utilizzati da più Director;
+ il Builder costruisce il prodotto step-by-step, permettendo un controllo più fine sul processo di + costruzione. +

+ +
+
-
-

Command

-
-
-
-

- Incapsula una richiesta, un azione o una transazione in un oggetto, permettendo di parametrizzare oggetti con diverse richieste, accodare o loggare richieste, e supportare operazioni annullabili (undo.)
- Il pattern command risponde alla necessità di creare richieste a oggetti senza conoscere nulla - l'operazione richiesta o il ricevente della richiesta. -

-

-

- Collaborazioni -

-
    -
  • Il client crea un oggetto command concreto e specifica il suo receiver;
    • -
  • Un oggetto invoker memorizza l'oggetto command concreto;
    • -
  • L'invoker fa una richiesta chiamando il metodo execute del command;
    • -
  • Il command concreto invoca operazioni sul receiver per portare a termine la richiesta.
    • -
- -

- Applicabilità -

-
    -
  • Parametrizzare oggetti con azioni da eseguire (si pensi ad un menuitem, al quale un client - esterno può assegnare l'azione da svolgere al click dell'utente.) Command rappresenta - l'alternativa object-oriented delle callback procedurali;
    • -
  • Specificare, accodare e eseguire richieste in tempi differenti;
    • -
  • Supportare operazioni reversibili (undo). L'operazione execute() dell'oggetto Command può - memorizzare stato per annullare i suoi effetti all'interno del Command stesso, e offrire un - metodo unexecute();
    • -
  • Supportare il logging dei cambiamenti in modo da poterli riapplicare in caso di crash del - sistema;
    • -
  • Supportare transazioni, operazioni ad alto livello costruite su operazioni primitive.
    • -
- -

- Conseguenze -

-
    -
  • Command disaccoppia l'oggetto che invoca l'operazione da quello che la esegue;
    • -
  • I command sono first-class objects, e pertanto sono manipolabili come tali;
    • -
  • Più command possono essere assemblati in command composti;
    • -
  • L'aggiunta di nuovi command è semplice poiché non è necessaria la modifica di classi già esistenti.
    • -
-
-
+
+

Command

+
+
+
+

+ Incapsula una richiesta, un azione o una transazione in un oggetto, permettendo di parametrizzare + oggetti con diverse richieste, accodare o loggare richieste, e supportare operazioni annullabili (undo.) +
+ Il pattern command risponde alla necessità di creare richieste a oggetti senza conoscere nulla + l'operazione richiesta o il ricevente della richiesta. +

+

+

+ Collaborazioni +

+
    +
  • Il client crea un oggetto command concreto e specifica il suo receiver;
    • +
  • Un oggetto invoker memorizza l'oggetto command concreto;
    • +
  • L'invoker fa una richiesta chiamando il metodo execute del command;
    • +
  • Il command concreto invoca operazioni sul receiver per portare a termine la richiesta.
    • +
+ +

+ Applicabilità +

+
    +
  • Parametrizzare oggetti con azioni da eseguire (si pensi ad un menuitem, al quale un client + esterno può assegnare l'azione da svolgere al click dell'utente.) Command rappresenta + l'alternativa object-oriented delle callback procedurali; +
    • +
  • Specificare, accodare e eseguire richieste in tempi differenti;
    • +
  • Supportare operazioni reversibili (undo). L'operazione execute() dell'oggetto Command può + memorizzare stato per annullare i suoi effetti all'interno del Command stesso, e offrire un + metodo unexecute(); +
    • +
  • Supportare il logging dei cambiamenti in modo da poterli riapplicare in caso di crash del + sistema; +
    • +
  • Supportare transazioni, operazioni ad alto livello costruite su operazioni primitive.
    • +
+ +

+ Conseguenze +

+
    +
  • Command disaccoppia l'oggetto che invoca l'operazione da quello che la esegue;
    • +
  • I command sono first-class objects, e pertanto sono manipolabili come tali;
    • +
  • Più command possono essere assemblati in command composti;
    • +
  • L'aggiunta di nuovi command è semplice poiché non è necessaria la modifica di classi già + esistenti. +
    • +
+
+
-
-

Decorator

-
-
-
-

- Talvolta vi è la necessità di aggiungere funzionalità a singoli oggetti, senza modificare la classe - di appartenenza. Un modo per farlo è con l'ereditarietà, ma in questo modo la scelta di aggiungere - funzionalità è fatta staticamente, e il client non ha modo di controllare tale comportamento. - In alcuni casi, il subclassing è poco pratico o irrealizzabile: un numero elevato di estensioni - indipendenti tra loro produrrebbe un'esplosione di sottoclassi, per rappresentare ogni possibile - combinazione. La classe base potrebbe, inoltre, essere inaccessibile, e quindi non ereditabile.
- Un approccio più - flessibile consiste nell'incapsulare il componente da estendere in un altro - oggetto, che aggiunga la funzionalità. Tale oggetto è chiamato decorator, ed espone la stessa - interfaccia del componente che incapsula. Il decorator inoltra le chiamate a metodo al componente, - e può eseguire operazioni aggiuntive prima o dopo. Poiché ogni decorator aderisce alla stessa - interfaccia, è possibile annidare più decorator ricorsivamente. -

-

- -

- Vantaggi
- Uno dei principali vantaggi del pattern è la - flessibilità con cui permette di aggiungere e rimuovere funzionalità a singoli oggetti a run-time. Inoltre, è facile aggiungere più volte la stessa - funzionalità (ad esempio, un bordo), attribuendo due volte lo stesso decorator a un componente.
- Il decorator permette di aggiungere gradualmente funzionalità agli oggetti: invece che costruire - classi grandi e complesse cercando di supportare più funzionalità possibile, che potrebbero in futuro - rivelarsi inutili, si possono aggiungere incrementalmente solo quelle necessarie, definendo un nuovo - Decorator per ognuna di esse. -

-

- Svantaggi
- Un decorator e il componente incapsulato espongono la medesima interfaccia, ma non - sono identici. Non si può fare affidamento all'identità tra oggetti quando vengono usati Decorator.
- Un altro svantaggio sta nel fatto una progettazione basata su Decorator spesso risulta in - sistemi composti da molti piccoli oggetti simili tra loro. Essi differiscono nel modo in cui sono - interconnessi, ma non nelle classi di appartenenza, e possono essere difficili da gestire in fase di - debug. - -

-
-
+
+

Decorator

+
+
+
+

+ Talvolta vi è la necessità di aggiungere funzionalità a singoli oggetti, senza modificare la classe + di appartenenza. Un modo per farlo è con l'ereditarietà, ma in questo modo la scelta di aggiungere + funzionalità è fatta staticamente, e il client non ha modo di controllare tale comportamento. + In alcuni casi, il subclassing è poco pratico o irrealizzabile: un numero elevato di estensioni + indipendenti tra loro produrrebbe un'esplosione di sottoclassi, per rappresentare ogni possibile + combinazione. La classe base potrebbe, inoltre, essere inaccessibile, e quindi non ereditabile.
+ Un approccio più + flessibile consiste nell'incapsulare il componente da estendere in un altro + oggetto, che aggiunga la funzionalità. Tale oggetto è chiamato decorator, ed espone la stessa + interfaccia del componente che incapsula. Il decorator inoltra le chiamate a metodo al componente, + e può eseguire operazioni aggiuntive prima o dopo. Poiché ogni decorator aderisce alla stessa + interfaccia, è possibile annidare più decorator ricorsivamente. +

+

+ +

+ Vantaggi
+ Uno dei principali vantaggi del pattern è la + flessibilità con cui permette di aggiungere e rimuovere funzionalità a singoli oggetti a run-time. + Inoltre, è facile aggiungere più volte la stessa + funzionalità (ad esempio, un bordo), attribuendo due volte lo stesso decorator a un componente.
+ Il decorator permette di aggiungere gradualmente funzionalità agli oggetti: invece che costruire + classi grandi e complesse cercando di supportare più funzionalità possibile, che potrebbero in futuro + rivelarsi inutili, si possono aggiungere in modo incrementale solo quelle necessarie, definendo un nuovo + Decorator per ognuna di esse. +

+

+ Svantaggi
+ Un decorator e il componente incapsulato espongono la medesima interfaccia, ma non + sono identici. Non si può fare affidamento all'identità tra oggetti quando vengono usati Decorator.
+ Un altro svantaggio sta nel fatto una progettazione basata su Decorator spesso risulta in + sistemi composti da molti piccoli oggetti simili tra loro. Essi differiscono nel modo in cui sono + interconnessi, ma non nelle classi di appartenenza, e possono essere difficili da gestire in fase di + debug. + +

+
+
-
-

Factory Method

-
-
-
-

- Definisce un'interfaccia per la creazione di un oggetto, lasciando però alle sottoclassi la decisione riguardo a quale classe istanziare. Tramite il Factory Method si fa in modo che una classe possa delegare l'istanziazione di un prodotto alle sue sottoclassi. -

-

-

- La classe Product definisce un'interfaccia per gli oggetti che il Factory Method andrà a creare (che non sono famiglie di prodotti distinte come su Abstract Factory), i prodotti sono poi implementati in vari ConcreteProduct.
- La classe Creator dichiara invece il metodo FactoryMethod(), che ritorna un oggetto di tipo Product, specificando eventualmente un'implementazione di default di tale metodo che ritorni un ConcreteProduct di default. I ConcreteCreator invece ridefiniscono il FactoryMethod() ritornando un'istanza specifica di ConcreteProduct. -

-
-
+
+

Factory Method

+
+
+
+

+ Definisce un'interfaccia per la creazione di un oggetto, lasciando però alle sottoclassi la decisione + riguardo a quale classe istanziare. Tramite il Factory Method si fa in modo che una classe possa + delegare l'istanziazione di un prodotto alle sue sottoclassi. +

+

+

+ La classe Product definisce un'interfaccia per gli oggetti che il Factory Method andrà a creare (che non + sono famiglie di prodotti distinte come su Abstract Factory), i prodotti sono poi implementati in vari + ConcreteProduct.
+ La classe Creator dichiara invece il metodo FactoryMethod(), che ritorna un oggetto di tipo + Product, specificando eventualmente un'implementazione di default di tale metodo che ritorni un + ConcreteProduct di default. I ConcreteCreator invece ridefiniscono il FactoryMethod() ritornando + un'istanza specifica di ConcreteProduct. +

+
+
-
-

Iterator

-
-
-
-

- Fornisce una modalità di accesso sequenziale ai singoli elementi di un aggregato di oggetti, ma senza esporne la rappresentazione sottostante. -

-

-

- La classe Iterator definisce un'interfaccia di accesso e attraversamento degli elementi, ConcreteIterator tiene traccia della posizione corrente di attraversamento, Aggregate definisce l'interfaccia per creare un oggetto Iterator e ConcreteAggregate implementa la creazione dell'iteratore ritornando un'istanza del ConcreteIterator corretto. -

-

- Iterator va usato quando c'è la necessità di scorrere una struttura come un array, una lista o anche strutture più complesse come alberi e grafi.
- L'iterator aiuta a implementare vari metodi di scorrimento della collezione separando la collezione stessa dal suo attraversamento. -

-
-
+
+

Iterator

+
+
+
+

+ Fornisce una modalità di accesso sequenziale ai singoli elementi di un aggregato di oggetti, ma senza + esporne la rappresentazione sottostante. +

+

+

+ La classe Iterator definisce un'interfaccia di accesso e attraversamento degli elementi, + ConcreteIterator tiene traccia della posizione corrente di attraversamento, Aggregate definisce + l'interfaccia per creare un oggetto Iterator e ConcreteAggregate implementa la creazione dell'iteratore + ritornando un'istanza del ConcreteIterator corretto. +

+

+ Iterator va usato quando c'è la necessità di scorrere una struttura come un array, una lista o anche + strutture più complesse come alberi e grafi.
+ L'iterator aiuta a implementare vari metodi di scorrimento della collezione separando la collezione + stessa dal suo attraversamento. +

+
+
-
-

MVC

-
-
-
-

- Model View Controller è un pattern architetturale che viene usato per dividere business logic e interfaccia. Può essere "push model" se è nativamente implementato in locale o "pull model" se il controller sta su un server. -

-

-

- MVC prevede sempre l'uso di pattern Observer per far sì che Model, View e Controller reagiscano al cambiamento di stato del programma. -

- -

- Nell'alternativa ModelViewPresenter(MVP) la view è passiva e si limita ad aggiornare la vista, è un'interfaccia di comunicazione.
- Nel ModelViewViewModel(MVVM) invece solo la validazione rimane nel modello e il ViewModel rappresenta la proiezione del modello per una vista, con binding a 2 view dunque tra la View e ViewModel. -

-
-
+
+

MVC

+
+
+
+

+ Model View Controller è un pattern architetturale che viene usato per dividere business logic e + interfaccia. Può essere "push model" se è nativamente implementato in locale o "pull model" se il + controller sta su un server. +

+

+

+ MVC prevede sempre l'uso di pattern Observer per far sì che Model, View e Controller reagiscano al + cambiamento di stato del programma. +

+ +

+ Nell'alternativa ModelViewPresenter(MVP) la view è passiva e si limita ad aggiornare la vista, è + un'interfaccia di comunicazione.
+ Nel ModelViewViewModel(MVVM) invece solo la validazione rimane nel modello e il ViewModel rappresenta la + proiezione del modello per una vista, con binding a 2 view dunque tra la View e ViewModel. +

+
+
-
-

Observer

-
-
-
-

- Definisce delle dipendenze tra degli oggetti per fare in modo che quando uno di essi cambia stato, tutti quelli in ascolto (da lui dipendenti) siano notificati. -

-

-

- L'Observer promuove una buona programmazione ad oggetti, in quanto il Subject non dipende da nessun tipo particolare di Observer a patto che ciò che viene delegato sia del tipo corretto per tale evento. -

- -
-
+
+

Observer

+
+
+
+

+ Definisce delle dipendenze tra degli oggetti per fare in modo che quando uno di essi cambia stato, tutti + quelli in ascolto (da lui dipendenti) siano notificati. +

+

+

+ L'Observer promuove una buona programmazione ad oggetti, in quanto il Subject non dipende da nessun tipo + particolare di Observer a patto che ciò che viene delegato sia del tipo corretto per tale evento. +

+ +
+
-
-

Proxy

-
-
-
-

- Il pattern Proxy fornisce un surrogato di un altro oggetto per controllarne l'accesso. Esso è - applicabile ogni qualvolta vi sia bisogno di un più versatile e sofisticato riferimento ad un oggetto - rispetto a un semplice puntatore. -

-

- -

- Un proxy è applicabile nelle seguenti situazioni: -

-
    -
  • Remote proxy: fornisce un rappresentante in locale di un oggetto in un diverso spazio di - indirizzamento;
    • -
  • Virtual proxy: crea oggetti complessi e pesanti on-demand;
    • -
  • Protection proxy: controlla l'accesso all'oggetto originale;
    • -
  • Smart reference: rimpiazza il semplice puntatore per svolgere azioni più avanzate, come il - reference counting.
    • -
-
-
+
+

Proxy

+
+
+
+

+ Il pattern Proxy fornisce un surrogato di un altro oggetto per controllarne l'accesso. Esso è + applicabile ogni qualvolta vi sia bisogno di un più versatile e sofisticato riferimento ad un oggetto + rispetto a un semplice puntatore. +

+

+ +

+ Un proxy è applicabile nelle seguenti situazioni: +

+
    +
  • Remote proxy: fornisce un rappresentante in locale di un oggetto in un diverso spazio di + indirizzamento; +
    • +
  • Virtual proxy: crea oggetti complessi e pesanti on-demand;
    • +
  • Protection proxy: controlla l'accesso all'oggetto originale;
    • +
  • Smart reference: rimpiazza il semplice puntatore per svolgere azioni più avanzate, come il + reference counting. +
    • +
+
+
-
-

Strategy

-
-
-
-

- Il pattern Strategy è utilizzato quando occorre definire una famiglia di algoritmi e renderli inter- - cambiabili, permettendo loro di variare indipendentemente dal client.
- Oggetti Strategy possono essere utilizzati per fornire diverse implementazioni di uno stesso - algoritmo o comportamento, e il client può scegliere il più appropriato in base ai diversi trade-off - di tempo e spazio. -

-

-

- La classe base comune a tutti gli oggetti Strategy permette di fattorizzare eventuale logica in - comune. -

-

- Vantaggi
- La presenza di più comportamenti è modellabile con l'ereditarietà, dove ogni sottoclasse implementa un algoritmo differente per la stessa operazione. In questo modo, però, la - sottoclasse è legata staticamente all'algoritmo, e può generare una moltitudine di sottoclassi che - differiscono tra loro solamente per il comportamento.
- Il pattern Strategy permette di variare algoritmi diversi dinamicamente, e indipendentemente - dal contesto di utilizzo, eliminando il bisogno di statement condizionali per selezionare il comportamento più appropriato. -

-

- Svantaggi
- Il client deve comprendere la differenza tra i diversi Strategy, per selezionare quello - più appropriato. Pertanto, tale pattern va utilizzato solamente se la variazione di comportamento - è rilevante per il codice client.
- Un altro svantaggio riguarda l'incremento del numero di oggetti presenti a runtime conseguente - dall'uso del pattern. Tale numero può essere ridotto implementando gli Strategy come oggetti - stateless, permettendo a più client di condividere istanze. -

-

- Implementazione
- Tutte le classi rappresentanti uno Strategy devono aderire ad un'interfaccia - comune, che deve essere opportunamente progettata. Tale interfaccia deve costituire un efficace - punto di accesso dallo Strategy al contesto di utilizzo, e viceversa.
- Un possibile approccio consiste nel passare i dati necessari allo Strategy per parametro. Questo - permette un basso accoppiamento, ma la presenza di troppi parametri potrebbe fare in modo che - alcuni Strategy concreti usino solo parte di essi, facendo istanziare al client oggetti che non verranno - utilizzati.
- Un'altra possibile implementazione vede il client passare se stesso come parametro allo Strategy, - o lo Strategy avere un riferimento al suo client. Questo elimina il bisogno di passare parametri, e il - possibile spreco di essi, ma richiede che il client definisca un'interfaccia più elaborata per l'accesso - ai suoi dati, aumentando l'accoppiamento tra i due elementi. -

-
-
+
+

Strategy

+
+
+
+

+ Il pattern Strategy è utilizzato quando occorre definire una famiglia di algoritmi e renderli inter- + cambiabili, permettendo loro di variare indipendentemente dal client.
+ Oggetti Strategy possono essere utilizzati per fornire diverse implementazioni di uno stesso + algoritmo o comportamento, e il client può scegliere il più appropriato in base ai diversi trade-off + di tempo e spazio. +

+

+

+ La classe base comune a tutti gli oggetti Strategy permette di fattorizzare eventuale logica in + comune. +

+

+ Vantaggi
+ La presenza di più comportamenti è modellabile con l'ereditarietà, dove ogni sottoclasse implementa un + algoritmo differente per la stessa operazione. In questo modo, però, la + sottoclasse è legata staticamente all'algoritmo, e può generare una moltitudine di sottoclassi che + differiscono tra loro solamente per il comportamento.
+ Il pattern Strategy permette di variare algoritmi diversi dinamicamente, e indipendentemente + dal contesto di utilizzo, eliminando il bisogno di statement condizionali per selezionare il + comportamento più appropriato. +

+

+ Svantaggi
+ Il client deve comprendere la differenza tra i diversi Strategy, per selezionare quello + più appropriato. Pertanto, tale pattern va utilizzato solamente se la variazione di comportamento + è rilevante per il codice client.
+ Un altro svantaggio riguarda l'incremento del numero di oggetti presenti a runtime conseguente + dall'uso del pattern. Tale numero può essere ridotto implementando gli Strategy come oggetti + stateless, permettendo a più client di condividere istanze. +

+

+ Implementazione
+ Tutte le classi rappresentanti uno Strategy devono aderire ad un'interfaccia + comune, che deve essere opportunamente progettata. Tale interfaccia deve costituire un efficace + punto di accesso dallo Strategy al contesto di utilizzo, e viceversa.
+ Un possibile approccio consiste nel passare i dati necessari allo Strategy per parametro. Questo + permette un basso accoppiamento, ma la presenza di troppi parametri potrebbe fare in modo che + alcuni Strategy concreti usino solo parte di essi, facendo istanziare al client oggetti che non verranno + utilizzati.
+ Un'altra possibile implementazione vede il client passare se stesso come parametro allo Strategy, + o lo Strategy avere un riferimento al suo client. Questo elimina il bisogno di passare parametri, e il + possibile spreco di essi, ma richiede che il client definisca un'interfaccia più elaborata per l'accesso + ai suoi dati, aumentando l'accoppiamento tra i due elementi. +

+
+
-
-

Template Method

-
-
-
-

- Definisce lo scheletro di un algoritmo, delegando alcuni dei passi a sottoclassi. Permette alle - sottoclassi di ridefinire alcuni passi di un algoritmo senza cambiarne la struttura. -

-

-

- Il pattern si può applicare quando si vuole implementare una sola volta le parti invarianti di un algoritmo, lasciando la ridefinizione delle parti variabili alle sottoclassi, oppure quando si vuole fattorizzare un comportamento comune tra diverse sottoclassi per evitare duplicazione. -

-
-
+
+

Template Method

+
+
+
+

+ Definisce lo scheletro di un algoritmo, delegando alcuni dei passi a sottoclassi. Permette alle + sottoclassi di ridefinire alcuni passi di un algoritmo senza cambiarne la struttura. +

+

+

+ Il pattern si può applicare quando si vuole implementare una sola volta le parti invarianti di un + algoritmo, lasciando la ridefinizione delle parti variabili alle sottoclassi, oppure quando si vuole + fattorizzare un comportamento comune tra diverse sottoclassi per evitare duplicazione. +

+
+
- -

Principi SOLID

-
-

Single Responsibility Principle

-
-
-
-

- Questo principio è conosciuto anche come coesione e dice dunque che una classe deve occuparsi solamente di fornire un certo tipo di funzionalità.
- Nel caso in cui una classe presenti più responsabilità, ciò può essere risolto inserendo una nuova classe intermedia che divida le responsabilità.
- Nella creazione dell'architettura tramite questo principio si perseguono: modularità, affidabilità, riusabilità, semplicità e basso accoppiamento. -

- -
-
+
+

Single Responsibility Principle

+
+
+
+

+ Questo principio è conosciuto anche come coesione e dice dunque che una classe + deve occuparsi solamente di fornire un certo tipo di funzionalità.
+ Nel caso in cui una classe presenti più responsabilità, ciò può essere risolto inserendo una nuova + classe intermedia che divida le responsabilità.
+ Nella creazione dell'architettura tramite questo principio si perseguono: modularità, affidabilità, + riusabilità, semplicità e basso accoppiamento. +

+ +
+
-
-

Open Closed Principle

-
-
-
-

- Questo principio dice che una classe dovrebbe essere aperta all'estensione ma chiusa al cambiamento.
- Per ottenere ciò uno strumento da utilizzare è l'astrazione, definendo metodi virtuali per prevedere l'estensibilità. -
- Tre principi da perseguire sono: rendere private le variabili, evitare le variabili globali e fare attenzione all'utilizzo di RTTI. -
- È impossibile ottenere una chiusura completa dell'intero software, dunque nella creazione dell'architettura si devono fare scelte strategiche per garantire modularità, flessibilità e incapsulamento. -

- -
-
+
+

Open Closed Principle

+
+
+
+

+ Questo principio dice che una classe dovrebbe essere aperta all'estensione ma chiusa al + cambiamento.
+ Per ottenere ciò uno strumento da utilizzare è l'astrazione, definendo metodi virtuali per prevedere + l'estensibilità. +
+ Tre principi da perseguire sono: rendere private le variabili, evitare le variabili globali e fare + attenzione all'utilizzo di RTTI. +
+ È impossibile ottenere una chiusura completa dell'intero software, dunque nella creazione + dell'architettura si devono fare scelte strategiche per garantire modularità, flessibilità e + incapsulamento. +

+ +
+
-
-

Liskov Substitution Principle

-
-
-
-

- Questo principio è alla base della programmazione ad oggetti e implica che dove è presente ereditarietà, le classi derivate possono essere usate al posto della classe base senza dover fare alcuna nuova assunzione. -
- Violare tale principio implica violare OCP. - Per rispettare tale principio è necessario che le precondizioni nella classi derivate siano uguali o più deboli(fanno meno assunzioni), mentre le post condizioni siano uguali o più forti di quelle della classe basi. -
- Nella creazione dell'architettura si devono fare scelte strategiche per garantire modularità, flessibilità e coesione. -

- -
-
+
+

Liskov Substitution Principle

+
+
+
+

+ Questo principio è alla base della programmazione ad oggetti e implica che dove è presente ereditarietà, + le classi derivate possono essere usate al posto della classe base senza dover fare alcuna nuova + assunzione. +
+ Violare tale principio implica violare OCP. + Per rispettare tale principio è necessario che le precondizioni nella classi derivate siano uguali o più + deboli(fanno meno assunzioni), mentre le post condizioni siano uguali o più forti di quelle della classe + basi. +
+ Nella creazione dell'architettura si devono fare scelte strategiche per garantire modularità, + flessibilità e coesione. +

+ +
+
-
-

Interface Segregation Principle

-
-
-
-

- Questo principio esprime la necessità di evitare che delle classi implementino delle interfacce che non usano. -
- Questo riduce l'accoppiamento ed è ottenuto attraverso la creazione di interfacce più "specializzate" e che siano coese. -
- Per rispettare questo principio la scelta migliore è utilizzare l'ereditarietà multipla, se disponibile da linguaggio, altrimenti è possibile separare le interfacce delegando l'aggiunta di funzionalità ad un pattern adapter. -
- Nella creazione dell'architettura si devono fare scelte strategiche per garantire modularità, flessibilità, basso accoppiamento, coesione e riusabilità. -

- -
-
+
+

Interface Segregation Principle

+
+
+
+

+ Questo principio esprime la necessità di evitare che delle classi implementino delle interfacce che non + usano. +
+ Questo riduce l'accoppiamento ed è ottenuto attraverso la creazione di interfacce più "specializzate" e + che siano coese. +
+ Per rispettare questo principio la scelta migliore è utilizzare l'ereditarietà multipla, se disponibile + da linguaggio, altrimenti è possibile separare le interfacce delegando l'aggiunta di funzionalità ad un + pattern adapter. +
+ Nella creazione dell'architettura si devono fare scelte strategiche per garantire modularità, + flessibilità, basso accoppiamento, coesione e riusabilità. +

+ +
+
-
-

Dependency Inversion Principle

-
-
-
-

- Questo principio esprime la necessità di evitare dipendenze dirette tra componenti di alto livello e quelle di basso livello. -
- Per evitare tale situazione entrambe le componenti devono dipendere da astrazioni che non dipendano a loro volta da implementazioni di dettaglio. -
- Modi di perseguire tale principio sono l'inserimento delle policy decisionali nei moduli alto livello, l'utilizzo del pattern template method e l'utilizzo di interfacce per ogni livello di architettura. - -
- Nella creazione dell'architettura si devono fare scelte strategiche per garantire modularità, flessibilità, basso accoppiamento, coesione, sicurezza rispetto ai malfunzionamenti, semplicità e robustezza. -

- -
-
+
+

Dependency Inversion Principle

+
+
+
+

+ Questo principio esprime la necessità di evitare dipendenze dirette tra componenti di alto livello e + quelle di basso livello. +
+ Per evitare tale situazione entrambe le componenti devono dipendere da astrazioni che non dipendano a + loro volta da implementazioni di dettaglio. +
+ Modi di perseguire tale principio sono l'inserimento delle policy decisionali nei moduli alto livello, + l'utilizzo del pattern template method e l'utilizzo di interfacce per ogni livello di architettura. + +
+ Nella creazione dell'architettura si devono fare scelte strategiche per garantire modularità, + flessibilità, basso accoppiamento, coesione, sicurezza rispetto ai malfunzionamenti, semplicità e + robustezza. +

+ +
+
- - - -

Tullio

Gli standard ISO

-
-

ISO 12207

-
-
-
-

- L'ISO 12207 (Systems and software engineering – Software life cycle processes) fornisce una suddivisione dei processi ad alto livello: i processi primari (acquisizione,fornitura,sviluppo), i processi di supporto(documentazione, versionamento, verifica e validazione) e processi organizzativi(gestione processi, gestione infrastrutture, miglioramento processi, formazione personale). -
- Fornisce inoltre per ogni processo una descrizione delle attività e dei compiti che lo compongono, fornendo un modello da specializzare in base al ciclo di vita adottato ma con specifiche responsabilità sui processi di cui identifica i prodotti attesi. -

-
-
+
+

ISO 12207

+
+
+
+

+ L'ISO 12207 (Systems and software engineering – Software life cycle processes) fornisce una suddivisione + dei processi ad alto livello: i processi primari (acquisizione,fornitura,sviluppo), i processi di + supporto(documentazione, versionamento, + verifica e validazione) e processi organizzativi(gestione processi, gestione infrastrutture, + miglioramento processi, formazione personale). +
+ Fornisce inoltre per ogni processo una descrizione delle attività e dei compiti + che lo compongono, fornendo un modello da specializzare in base al ciclo di vita adottato ma con + specifiche responsabilità sui processi di cui identifica i prodotti attesi. +

+
+
-
-

ISO/IEC 9126

-
-
-
-

- L'ISO 9126 fornisce un modello basato su sette caratteristiche per la valutazione della qualità di prodotto, suddivise in totale in 31 sotto-caratteristiche. Esso si basa su tre tipi di visioni: esterna, interna e in uso. -
- Una delle caratteristiche è la qualità in uso, le altre 6 sono interne e esterne e sono funzionalità, affidabilità, efficienza, usabilità, manutenibilità e portabilità. -

-
-
+
+

ISO/IEC 9126

+
+
+
+

+ L'ISO 9126 fornisce un modello basato su sette caratteristiche per la valutazione della qualità di + prodotto, suddivise in totale in 31 sotto-caratteristiche. Esso si basa su tre tipi di visioni: + esterna, interna e in uso. +
+ Una delle caratteristiche è la qualità in uso, le altre 6 sono interne e esterne e sono funzionalità, + affidabilità, efficienza, usabilità, manutenibilità e portabilità. +

+
+
-
-
-

ISO/IEC 14598

-
-
-
-

- L'ISO 14598 fornisce linee guida per l'associazione di una misurazione quantitativa(metrica) ad una data sotto-caratteristica individuata nello standard ISO 9126. -
- Se ISO/IEC 9126 definisce un modello della qualità del software, lo standard 14598 descrive il processo di valutazione della qualità del software. -

-
-
+
+

ISO/IEC 14598

+
+
+
+

+ L'ISO 14598 fornisce linee guida per l'associazione di una misurazione quantitativa(metrica) ad + una data sotto-caratteristica individuata nello standard ISO 9126. +
+ Se ISO/IEC 9126 definisce un modello della qualità del software, lo standard 14598 descrive il processo + di valutazione della qualità del software. +

+
+
-
-
-

ISO/IEC 25000

-
-
-
-

- L'ISO 25000 ingloba gli standard 9126 e 14598 in un unico standard chiamato SQuaRE: Software product Quality Requirements and Evaluation. -

-
-
+
+

ISO/IEC 25000

+
+
+
+

+ L'ISO 25000 ingloba gli standard 9126 e 14598 in un unico standard chiamato SQuaRE: Software product + Quality Requirements and Evaluation. +

+
+
-
-

ISO 9000

-
-
-
-

- L'ISO 9000 rappresenta il fondamento per i modelli di qualità dei processi ma resta neutro rispetto al dominio di applicazione, infatti la suddivisione prevista nei processi differisce completamente da quella definita in ISO/IEC 12207. -

-
-
+
+

ISO 9000

+
+
+
+

+ L'ISO 9000 rappresenta il fondamento per i modelli di qualità dei processi ma resta neutro + rispetto al dominio di applicazione, infatti la suddivisione prevista nei processi differisce + completamente da quella definita in ISO/IEC 12207. +

+
+
-
-

ISO 9001

-
-
-
-

- L'ISO 9001 definisce un Sistema Gestione Qualità(SGQ), calando la visione di ISO 9000 nei sistemi produttivi, introducendo dei requisiti ben specifici. ISO 9001 è anche una certificazione. -

-
-
+
+

ISO 9001

+
+
+
+

+ L'ISO 9001 definisce un Sistema + Gestione Qualità(SGQ), calando la visione di ISO 9000 nei sistemi produttivi, introducendo dei + requisiti ben specifici. ISO 9001 è anche una certificazione. +

+
+
-
-

ISO/IEC 15504 (SPICE)

-
-
-
-

- L'ISO 15504 definito come SPICE (Software Process Improvement Capability dEtermination) è un modello che che va a ricercare il grado di capability dei processi aziendali, in ottica di miglioramento. Individua cinque (più uno) livelli di capability di processo: incomplete (lv. 0), performed, managed, established, predictable, optimizing. -
- Su questi livelli sono suddivisi 9 attributi di processo, per ognuno dei quali è associato un livello di raggiungimento tra non raggiunto, parzialmente raggiunto, in gran parte raggiunto e completamente raggiunto. -

-
-
+
+

ISO/IEC 15504 (SPICE)

+
+
+
+

+ L'ISO 15504 definito come SPICE (Software Process Improvement Capability dEtermination) è un + modello che che va a ricercare il grado di capability dei processi aziendali, in ottica di + miglioramento. Individua cinque (più uno) livelli di capability di processo: incomplete (lv. 0), + performed, managed, established, predictable, optimizing. +
+ Su questi livelli sono suddivisi 9 attributi di processo, per ognuno dei quali è associato un livello di + raggiungimento tra non raggiunto, parzialmente raggiunto, in gran parte raggiunto e completamente + raggiunto. +

+
+
-
-

ISO/IEC 15939

-
-
-
-

- L'ISO 15939 fornisce un modello delle misurazioni da produrre e delle relazioni tra esse, descrivendone il processo di misurazione. Questo standard afferma che i bisogni informativi sono basati su obiettivi, vincoli, rischi e problemi che hanno origine dai processi tecnici e di gestione. -
- Il modello fornito da questo ISO può essere istanziato sulla base di attributi derivanti da altri modelli, ad esempio CMMI. -

-
-
+
+

ISO/IEC 15939

+
+
+
+

+ L'ISO 15939 fornisce un modello delle misurazioni da produrre e delle relazioni tra esse, + descrivendone il processo di misurazione. Questo standard afferma che i bisogni informativi sono basati + su obiettivi, vincoli, rischi e problemi che hanno origine dai processi tecnici e di gestione. +
+ Il modello fornito da questo ISO può essere istanziato sulla base di attributi derivanti da altri + modelli, ad esempio CMMI. +

+
+
diff --git a/src/cCiclodiVita.html b/src/cCiclodiVita.html index 97b8973..220fdb6 100644 --- a/src/cCiclodiVita.html +++ b/src/cCiclodiVita.html @@ -1,214 +1,273 @@

Ciclo di vita

-La durata del ciclo di vita di un software va dalla sua concezione, -cioè il momento in cui nasce l'idea o il bisogno (processo di acquisizione), passa poi per sviluppo e utilizzo, che -idealmente è prolungato nel tempo e in cui subisce manutenzione, per poi terminare con il ritiro del prodotto. + La durata del ciclo di vita di un software va dalla sua concezione, + cioè il momento in cui nasce l'idea o il bisogno (processo di acquisizione), passa poi per sviluppo e utilizzo, che + idealmente è prolungato nel tempo e in cui subisce manutenzione, per poi terminare con il ritiro del prodotto. -L'avanzamento tra questi stati è originato dalle attività definite dal modello di ciclo di vita scelto, -esse devono essere coese e raggruppate in processi. + L'avanzamento tra questi stati è originato dalle attività + definite dal modello di ciclo di vita scelto, esse devono essere coese e raggruppate in processi. -In tali attività è importante identificare dipendenze tra ingressi e uscite e fissarne ordinamento temporale, orientato all'avanzamento. -
-Un progetto può essere visto come un insieme di fasi che rappresentano la durata temporale entro uno stato di ciclo di vita o in una transizione tra essi. + In tali attività è importante identificare dipendenze tra ingressi e uscite e fissarne ordinamento temporale, + orientato all'avanzamento. +
+ Un progetto può essere visto come un insieme di fasi che rappresentano la durata temporale entro uno stato di ciclo + di vita o in una transizione tra essi.

- - -

Gestione di progetto

-

- La scelta del modello di ciclo di vita da adottare va fatta precedere dalla pianificazione e dalla gestione del progetto poiché le vincola, - rimanendo però indipendete da strumenti e metodi di sviluppo. -
- Il modello di ciclo di vita -fornisce le relazioni temporali e logiche tra i processi, rispetto agli stati di ciclo di -vita. - Molto importante è un'analisi preventiva del modello da scegliere poiché da esso dipende la stima dei costi, dei tempi, di obblighi e benefici associati al progetto. -
- L'adozione di un modello richiede un sistema di qualità per garantire conformità e maturità alle attese, con misurazioni in quanto i modelli di ciclo di vita aiutano a perseguire la quantificabilità. - -

-

Scelta del modello

-

- I fattori critici nella scelta del modello di ciclo di vita sono: -

- -

- - L'esigenza di definire dei modelli di cicli di vita nasce al fine di evitare il "code-'n-fix" che viene adottato in progetti caotici, non gestibili. -

- -

Sequenziale, detto a cascata

-

- Questo modello prevedere una definizione di fasi strettamente sequenziali, distinte e non sovrapposte nel tempo, senza la possibilità di ritorni a - fasi precedenti. -
- Ogni fase è caratterizzata da precondizioni e postcondizioni definite, che devono essere dimostrate prima dai prodotti documentali - (l'approvazione dei documenti è necessaria per l'avvio di una fase successiva) e poi software. - Può essere adatto allo sviluppo di sistemi complessi a livello organizzativo e eventi inaspettati implicano ripartire dall'inizio. -
- Ogni fase viene definita in termini di: - -

- - -

Le fasi sono durate temporali con dipendenze -causali tra loro. -
-Tra i difetti principali di questo modello troviamo l'eccessiva rigidità data dalla stretta sequenzialità tra le fasi -e da una visione burocratica poco realistica che non ammette modifiche in corso d'opera se non per molta manutenzione. - -Per correggere tale rigidità sono stati introdotti dei modelli ibridi di due tipi: -con prototipazione, che prevede dei prototipi usa e getta per capire meglio i requisiti e con ritorni in cui ogni ciclo di ritorni raggruppa sottosequenze di fasi. + + +

Gestione di progetto

+

+ La scelta del modello di ciclo di vita da adottare va fatta precedere dalla pianificazione e dalla gestione del + progetto poiché le vincola, rimanendo però indipendente da strumenti e metodi di sviluppo. +
+ Il modello di ciclo di vita fornisce le relazioni temporali e logiche tra i processi, rispetto agli stati di ciclo + di + vita. + Molto importante è un'analisi preventiva del modello da scegliere poiché da esso dipende la stima dei costi, dei + tempi, di obblighi e benefici associati al progetto. +
+ L'adozione di un modello richiede un sistema di qualità per garantire conformità e maturità alle attese, con + misurazioni in quanto i modelli di ciclo di vita aiutano a perseguire la quantificabilità. + +

+

Scelta del modello

+

+ I fattori critici nella scelta del modello di ciclo di vita sono: +

+ +

+ + L'esigenza di definire dei modelli di cicli di vita nasce al fine di evitare il "code-'n-fix" che viene adottato in + progetti caotici, non gestibili. +

+ +

Sequenziale, detto a cascata

+

+ Questo modello prevedere una definizione di fasi strettamente sequenziali, distinte e non sovrapposte nel tempo, + senza la possibilità di ritorni a + fasi precedenti. +
+ Ogni fase è caratterizzata da precondizioni e postcondizioni + definite, che devono essere dimostrate prima dai prodotti documentali + (l'approvazione dei documenti è necessaria per l'avvio di una fase successiva) e poi software. + Può essere adatto allo sviluppo di sistemi complessi a livello organizzativo e eventi inaspettati implicano + ripartire dall'inizio. +
+ Ogni fase viene definita in termini di: + +

+ + +

Le fasi sono durate temporali con dipendenze causali tra loro. +
+ Tra i difetti principali di questo modello troviamo l'eccessiva rigidità data dalla stretta sequenzialità tra le + fasi e da una visione burocratica poco realistica che non ammette modifiche in corso d'opera se non per molta + manutenzione. + + Per correggere tale rigidità sono stati introdotti dei modelli ibridi di due tipi: + con prototipazione, che prevede dei prototipi usa e getta per capire meglio i requisiti e con ritorni + in cui ogni ciclo di ritorni raggruppa sottosequenze di fasi.

-

Incremento vs Iterazione

-

- L'inserimento di ritorni in un progetto può essere di tipo iterativo o incrementale. - Un'iterazione aiuta il dialogo con gli stakeholder in caso ogni aspetto del sistema non sia compreso fin dall'inizio, consentendo maggiore capacità - di adattamento ma comporta rischio di non convergenza poiché ogni iterazione comporta un ritorno all'indietro nel tempo.
- Dunque le iterazioni possono essere distruttive e l'approccio migliore sarebbe decomporre la realizzazione del sistema, identificando le componenti più - critiche in modo di limitare superiormente il numero delle iterazioni. -

- - Gli incrementi invece consentono di non rimandare l'integrazione tra le parti del sistema alla fine, ma di integrare per volta piccole parti - al fine di produrre valore ad ogni incremento. - Per tale motivo un insieme non vuoto di funzionalità è presto disponibile e i primi incrementi si possono sfruttare come prototipi - per fissare meglio i requisiti, riducendo il rischio di fallimento. - Questo è dovuto al fatto che le funzionalità principali sono sviluppate per prime e attraversano quindi più fasi di verifica. - Un'iterazione coincide con un incremento se il suo unico effetto è raffinare il prodotto senza ulteriori impatti sulle altre parti del sistema. -

-

Incrementale

-

-In questo modello i cicli non sono più iterazioni ma incrementi; - ogni incremento attraversa tutte le fasi del modello sequenziale, dall’analisi alla verifica - (anche se, nella variante principale Staged Delivery, l’analisi e la progettazione si affrontano all’inizio e non vengono più ripetute). -
- Il modello prevede rilasci multipli realizzando un incremento di funzionalità e avvicinandosi sempre più alle attese. - Un grande vantaggio è che le funzionalità più importanti vengono trattate per prime; così facendo, queste vengono verificate più volte - (dato che ogni ciclo prevede la verifica del software). -
Ogni incremento ha il vantaggio di ridurre il rischio di fallimento, con un approccio più realistico e predisposto ai cambiamenti. - Difatti, mentre il modello sequenziale segue un approccio predittivo (cioè basato su piani che devono essere rispettati), - il modello incrementale segue un approccio adattativo, dove la realtà è considerata imprevedibile. -

- - Sarebbe preferibile un approccio predittivo, che permette di stimare con precisione una data di consegna e un preventivo; - tuttavia l’approccio adattativo può essere conveniente in uno scenario in cui i requisiti cambiano in corso d’opera. -

-

- Schema generale
- La prima cosa da fare è comprendere il problema e definire i contorni dei requisiti, assegnando poi i requisiti agli incrementi, bisogna quindi pensare ad una sequenza che idealmente porti verso una buona soluzione e converga. - Si passa dunque alla progettazione dell'architettura di massima del sistema, finita la quale si inizia un incremento con modifica alla progettazione di dettaglio e inizio della codifica. - Si passa dunque a validare l'incremento controllando che esso soddisfi i requisiti ad esso associati e si integra eventualmente a quanto era già stato prodotto. - Si valida quindi il sistema e poi si torna a sviluppare il prossimo incremento fino a quando il sistema non raggiunge il suo stato finale. - -

- - -

Evolutivo

-

Il modello evolutivo, che è incrementale, prevede un'analisi preliminare per identificare requisiti e architettura di massima -e pianificare la realizzazione evolutiva. -Gli incrementi successivi raffinano ed estendono l'analisi e la progettazione con il rilascio di versioni(prototipi) usabili dal cliente. - Più versioni posso essere mantenute in parallelo e ogni fase ammette iterazioni multiple. -

-

- Schema generale
- La prima cosa da fare è un'analisi preliminare per identificare i requisiti di massima, un'architettura di massima e pianificare i passi di analisi successivi per la realizzazione evolutiva. - Per ogni evoluzione viene eseguito un raffinamento e un'estensione dell'analisi dalla quale si procede a progettazione, codifica e integrazione. - Vengono dunque rilasciati dei prototipi fino ad arrivare all'accettazione finale. -

- - -

Spirale

-

- Nel 1988 Barry Boehm propose il modello a spirale, che introduce il concetto di "rischio di progetto", - ponendo grande attenzione sugli aspetti gestionali tramite pianificazione delle fasi e analisi dei rischi. - - Lo sviluppo procede a cicli inizialmente rapidi ma via via sempre più lenti; - difatti i cicli esterni della spirale sono così lenti che possono aderire, ognuno, ad un diverso modello di ciclo di vita. - Ad ogni ciclo si analizzano i rischi e si compiono simulazioni. Misura del successo di un progetto è il diametro della spirale. - Un ciclo si articola generalmente in quattro momenti: +

Incremento vs Iterazione

+

+ L'inserimento di ritorni in un progetto può essere di tipo iterativo o incrementale. + Un'iterazione aiuta il dialogo con gli stakeholder in + caso ogni aspetto del sistema non sia compreso fin dall'inizio, consentendo maggiore capacità + di adattamento ma comporta rischio di non convergenza poiché ogni iterazione comporta un ritorno all'indietro nel + tempo.
+ Dunque le iterazioni possono essere distruttive e l'approccio migliore sarebbe decomporre la realizzazione del + sistema, identificando le componenti più critiche in modo di limitare superiormente il numero delle iterazioni. +

+ + Gli incrementi invece consentono di non rimandare l'integrazione tra le parti del sistema alla fine, ma di integrare + per volta piccole parti al fine di produrre valore ad ogni incremento. + Per tale motivo un insieme non vuoto di funzionalità è presto disponibile e i primi incrementi si possono sfruttare + come prototipi per fissare meglio i requisiti, riducendo il rischio di fallimento. + Questo è dovuto al fatto che le funzionalità principali sono sviluppate per prime e attraversano quindi più fasi di + verifica. + Un'iterazione coincide con un incremento se il suo unico effetto è raffinare il prodotto senza ulteriori impatti + sulle altre parti del sistema. +

+

Incrementale

+

+ In questo modello i cicli non sono più iterazioni ma incrementi; + ogni incremento attraversa tutte le fasi del modello sequenziale, dall’analisi alla verifica + (anche se, nella variante principale Staged Delivery, l’analisi e la progettazione si affrontano all’inizio e non + vengono più ripetute). +
+ Il modello prevede rilasci multipli realizzando un incremento di funzionalità e avvicinandosi sempre più alle + attese. + Un grande vantaggio è che le funzionalità più importanti vengono trattate per prime; così facendo, queste vengono + verificate più volte (dato che ogni ciclo prevede la verifica del software). +
Ogni incremento ha il vantaggio di ridurre il rischio di fallimento, con un approccio più realistico e + predisposto ai cambiamenti. + Difatti, mentre il modello sequenziale segue un approccio predittivo (cioè basato su piani che devono essere + rispettati), + il modello incrementale segue un approccio adattativo, dove la realtà è considerata imprevedibile. +

+ + Sarebbe preferibile un approccio predittivo, che permette di stimare con precisione una data di consegna e un + preventivo; + tuttavia l’approccio adattativo può essere conveniente in uno scenario in cui i requisiti cambiano in corso d’opera. +

+

+ Schema generale
+ La prima cosa da fare è comprendere il problema e definire i contorni dei requisiti, assegnando poi i requisiti agli + incrementi, bisogna quindi pensare ad una sequenza che idealmente porti verso una buona soluzione e converga. + Si passa dunque alla progettazione dell'architettura di massima del sistema, finita la quale si inizia un incremento + con modifica alla progettazione di dettaglio e inizio della codifica. + Si passa dunque a validare l'incremento controllando che esso soddisfi i requisiti ad esso associati e si integra + eventualmente a quanto era già stato prodotto. + Si valida quindi il sistema e poi si torna a sviluppare il prossimo incremento fino a quando il sistema non + raggiunge il suo stato finale. + +

+ + +

Evolutivo

+

Il modello evolutivo, che è incrementale, prevede un'analisi preliminare per identificare requisiti e architettura di + massima + e pianificare la realizzazione evolutiva. + Gli incrementi successivi raffinano ed estendono l'analisi e la progettazione con il rilascio di versioni(prototipi) + usabili dal cliente. + Più versioni posso essere mantenute in parallelo e ogni fase ammette iterazioni multiple. +

+

+ Schema generale
+ La prima cosa da fare è un'analisi preliminare per identificare i requisiti di massima, un'architettura di massima e + pianificare i passi di analisi successivi per la realizzazione evolutiva. + Per ogni evoluzione viene eseguito un raffinamento e un'estensione dell'analisi dalla quale si procede a + progettazione, codifica e integrazione. + Vengono dunque rilasciati dei prototipi fino ad arrivare all'accettazione finale. +

+ + +

Spirale

+

+ Nel 1988 Barry Boehm propose il modello a spirale, che introduce il concetto di "rischio di progetto", + ponendo grande attenzione sugli aspetti gestionali tramite pianificazione delle fasi e analisi dei rischi. + + Lo sviluppo procede a cicli inizialmente rapidi ma via via sempre più lenti; + difatti i cicli esterni della spirale sono così lenti che possono aderire, ognuno, ad un diverso modello di ciclo di + vita. + Ad ogni ciclo si analizzano i rischi e si compiono simulazioni. Misura del successo di un progetto è il diametro + della spirale. + Un ciclo si articola generalmente in quattro momenti:

- +

- Questo modello viene usato solo da chi intraprende progetti sperimentali, che nessuno ha mai realizzato, e richiede forte interazione tra committente e fornitore. - -

- - -

A componenti

- -

Prevede l’integrazione di componenti già implementati, massimizzando il riuso sistematico di componenti. - L’idea nasce dal fatto che molto di quel che ci serve fare è già stato fatto e molto di quel che faremo ci potrà servire ancora. -Richiede una progettazione incentrata al riuso, analizzando anche ciò che ho già a disposizione e eventualmente negoziando i requisiti per sfruttare -tali componenti. - -

- - -

Agile

-

Si tratta di modelli altamente dinamici, con cicli iterativi e incrementali, basati su principi fondanti per svincolarsi dall'eccessiva rigidità. -I principi fondanti sono: le persone e le interazioni sono più importanti rispetto ai processi e agli strumenti, molto più importante il software rispetto alla documentazione ed è molto più importante rispondere al cambiamento anziché agire secondo un piano. -
-L'idea base per implementare tali principi è l'user story, ossia un compito significativo che l'utente vuole svolgere con il software richiesto. -Il lavoro viene quindi suddiviso in piccoli incrementi a valore aggiunto che vengono sviluppati indipendentemente in una sequenza continua dall'analisi all'integrazione. -

-Come obiettivi strategici ci sono: la possibilità di dimostrare in ogni momento al cliente ciò che è stato fatto, verificare l'avanzamento tramite il progresso reale, -motivare gli sviluppatori con risultati immediati e assicurare una buona verifica e integrazione dell'intero prodotto software. -
-
-Un esempio molto utilizzato è lo SCRUM, dove viene creato e mantenuto un backlog, un "mucchio" di piccoli task da svolgere. -La persona incaricata di questo deve essere esperta e preparata e viene chiamata product owner e deve organizzare anche degli sprint, cioè dei periodi -di tempo brevi in cui una parte di questi task vengono discussi e assegnati ai programmatori. -In Scrum vi è la figura dello Scrum master : esso ha la responsabilità di facilitare e gestire -i meeting, tracciare il backlog, misurare il progresso e comunicare con i clienti e il management. -È responsabile di tutto il processo di Scrum. Ad ogni modo, tutto il team ha potere -decisionale. -
-Lo sprint è preferibilmente breve, poiché periodi prolungati hanno esito incerto. -I task sono compiti che può portare a termine una singola persona, i cui incrementi apportati sono sempre funzionanti (compilano).
-Durante gli sprint vengono tenuti degli incontri quotidiani al fine di monitorare lo stato di avanzamento, mentre al suo termine se ne esegue -una revisione critica mettendo eventualmente in discussione il backlog iniziale. + Questo modello viene usato solo da chi intraprende progetti sperimentali, che nessuno ha mai realizzato, e richiede + forte interazione tra committente e fornitore.

+ +

A componenti

+ +

Prevede l’integrazione di componenti già implementati, massimizzando il riuso sistematico di + componenti. + L’idea nasce dal fatto che molto di quel che ci serve fare è già stato fatto e molto di quel che faremo ci potrà + servire ancora. + Richiede una progettazione incentrata al riuso, analizzando anche ciò che ho già a disposizione e eventualmente + negoziando i requisiti per sfruttare + tali componenti. + +

+ + +

Agile

+

Si tratta di modelli altamente dinamici, con cicli iterativi e incrementali, basati su principi fondanti per + svincolarsi dall'eccessiva rigidità. + I principi fondanti sono: le persone e le interazioni sono più importanti rispetto ai processi e agli strumenti, + molto più importante il software rispetto alla documentazione ed è molto più importante rispondere al cambiamento + anziché agire secondo un piano. +
+ L'idea base per implementare tali principi è l'user story, ossia un compito significativo che l'utente vuole + svolgere con il software richiesto. + Il lavoro viene quindi suddiviso in piccoli incrementi a valore aggiunto che vengono sviluppati indipendentemente in + una sequenza continua dall'analisi all'integrazione. +

+ Come obiettivi strategici ci sono: la possibilità di dimostrare in ogni momento al cliente ciò che è stato fatto, + verificare l'avanzamento tramite il progresso reale, motivare gli sviluppatori con risultati immediati e assicurare + una buona verifica e integrazione dell'intero prodotto software. +
+
+ Un esempio molto utilizzato è lo SCRUM, dove viene creato e mantenuto un backlog, un "mucchio" di piccoli task da + svolgere. + La persona incaricata di questo deve essere esperta e preparata e viene chiamata product owner e deve + organizzare anche degli sprint, cioè dei periodi di tempo brevi in cui una parte di questi task vengono discussi e + assegnati ai programmatori. + In Scrum vi è la figura dello Scrum master : esso ha la responsabilità di facilitare e gestire i meeting, tracciare + il backlog, misurare il progresso e comunicare con i clienti e il management. + È responsabile di tutto il processo di Scrum. Ad ogni modo, tutto il team ha potere decisionale. +
+ Lo sprint è preferibilmente breve, poiché periodi prolungati hanno esito incerto. + I task sono compiti che può portare a termine una singola persona, i cui incrementi apportati sono sempre + funzionanti (compilano).
+ Durante gli sprint vengono tenuti degli incontri quotidiani al fine di monitorare lo stato di avanzamento, mentre al + suo termine se ne esegue una revisione critica mettendo eventualmente in discussione il backlog iniziale. + +

- + diff --git a/src/cDoc.html b/src/cDoc.html index 04fd261..2c70965 100644 --- a/src/cDoc.html +++ b/src/cDoc.html @@ -1,240 +1,287 @@

Documentazione

L'importanza di documentare

-Documentare è essenziale per poter replicare il prodotto descritto nella documentazione, senza coinvolgere il suo creatore. + Documentare è essenziale per poter replicare il prodotto descritto nella documentazione, senza coinvolgere il suo + creatore.

-La documentazione serve però anche al gruppo per gestire lo svolgimento dei processi produttivi e la loro qualità (documentandone -le misurazioni), per garantire il controllo sull'avanzamento nel progetto secondo regole dettate dal modello di sviluppo adottato, -segnando un confine netto tra la creatività del singolo e la disciplina. -Per mezzo della documentazione si possono dunque garantire un flusso di informazioni corretto e sempre aggiornato tra i partecipanti -al fine di attenuare eventuali dispersioni e inconsistenze dovute a decisioni non tracciate. + La documentazione serve però anche al gruppo per gestire lo svolgimento dei processi produttivi e la loro qualità + (documentandone le misurazioni), per garantire il controllo sull'avanzamento nel progetto secondo regole dettate dal + modello di sviluppo adottato, segnando un confine netto tra la creatività del singolo e la disciplina. + Per mezzo della documentazione si possono dunque garantire un flusso di informazioni corretto e sempre aggiornato + tra i partecipanti al fine di attenuare eventuali dispersioni e inconsistenze dovute a decisioni non tracciate.

-Gli aspetti principali da documentare sono legati alla pianificazione e alla gestione del progetto, con particolare attenzione -al suo sviluppo, alla verifica e alla validazione secondo gli standard di processo in uso. -Ciò è utile ai membri del progetto come strumento di comunicazione, ai responsabili per tenere sotto controllo la pianificazione e ad eventuali -manutentori per reperire informazioni sul sistema. -
-Vanno documentati anche i prodotti in ottica dell'utente utilizzatore in modo da fornire un quadro chiaro su come interfacciarsi al prodotto. -
+ Gli aspetti principali da documentare sono legati alla pianificazione e alla gestione del progetto, con particolare + attenzione al suo sviluppo, alla verifica e alla validazione secondo gli standard di processo in uso. + Ciò è utile ai membri del progetto come strumento di comunicazione, ai responsabili per tenere sotto controllo la + pianificazione e ad eventuali manutentori per reperire informazioni sul sistema. +
+ Vanno documentati anche i prodotti in ottica dell'utente utilizzatore in modo da fornire un quadro chiaro su come + interfacciarsi al prodotto. +

Stile di scrittura

-Nel redigere i documenti, oltre ad assicurarsi un'ovvia correttezza grammaticale e tipografica, va assicurato l'uso di uno stile non verboso -con paragrafi e frasi brevi incentrati su un solo fatto, descritto utilizzando terminologia precisa e riportando più punti di vista per descrizioni complesse. -In particolare la suddivisione in sezioni e sottosezioni deve presentare dei titoli, essere indicizzata e lo stile da tenere deve presentare -forma attiva piuttosto che passiva, in quanto il documento è formale e descrive il lavoro svolto in prima persona dal gruppo. + Nel redigere i documenti, oltre ad assicurarsi un'ovvia correttezza grammaticale e tipografica, va assicurato l'uso + di uno stile non verboso con paragrafi e frasi brevi incentrati su un solo fatto, descritto utilizzando terminologia + precisa e riportando più punti di vista per descrizioni complesse. + In particolare la suddivisione in sezioni e sottosezioni deve presentare dei titoli, essere indicizzata e lo stile + da tenere deve presentare forma attiva piuttosto che passiva, in quanto il documento è formale e descrive il lavoro + svolto in prima persona dal gruppo.

Studio di fattibilità

-Lo studio di fattibilità raccoglie un'analisi preliminare sui capitolati disponibili per il gruppo -che è chiamato a valutarne pregi, difetti e soprattutto fattibilità in termini di costi e tempistiche rispetto -alle abilità già possedute dai membri del gruppo. -Il grado di dettaglio dell'analisi aumenta nella valutazione del capitolato scelto. + Lo studio di fattibilità raccoglie un'analisi preliminare sui capitolati disponibili per il gruppo che è chiamato a + valutarne pregi, difetti e soprattutto fattibilità in termini di costi e tempistiche rispetto alle abilità già + possedute dai membri del gruppo. + Il grado di dettaglio dell'analisi aumenta nella valutazione del capitolato scelto.

-
-

Indice SdF by DigitalCookies

-
-
-
+
+

Indice SdF by DigitalCookies

+
+
+
-
+

Norme di progetto

-Le norme di progetto contengono le linee guida per la gestione di tutti i processi istanziati dal gruppo e devono seguire la struttura proposta -nell'ISO 12207. -Questo documento contiene l'organizzazione e l'uso delle risorse di sviluppo, -le convenzioni che il gruppo decide di adottare sull'uso degli strumenti di sviluppo, -l'organizzazione degli ambiti legati alla cooperazione, le norme sullo stile di codifica(es: convenzioni sui nomi, indentazione, intestazioni ecc) e di scrittura e la gestione dei cambiamenti. -
-Questo documento deve essere proattivo nell'identificare le norme relative ad un determinato processo. -Una norma nasce da una regola, cioè da una convenzione che viene riconosciuta come necessaria e di cui è richiesto ed accertato il rispetto -oppure da una raccomandazione che indica una prassi desiderabile ma di cui non si accerta il rispetto. -Ogni norma ha una portata definita dal contesto in cui viene applicata poiché non tutto può essere davvero regolamentato. + Le norme di progetto contengono le linee guida per la gestione di tutti i processi istanziati dal gruppo e devono + seguire la struttura proposta nell'ISO 12207. + Questo documento contiene l'organizzazione e l'uso delle risorse di sviluppo, le convenzioni che il gruppo decide di + adottare sull'uso degli strumenti di sviluppo, l'organizzazione degli ambiti legati alla cooperazione, le norme + sullo + stile di codifica(es: convenzioni sui nomi, indentazione, intestazioni ecc) e di scrittura e la + gestione dei cambiamenti. +
+ Questo documento deve essere proattivo nell'identificare le norme relative ad un determinato processo. + Una norma nasce da una regola, cioè da una convenzione che viene riconosciuta come necessaria e di cui è richiesto + ed accertato il rispetto oppure da una raccomandazione che indica una prassi desiderabile ma di cui non si accerta + il rispetto. + Ogni norma ha una portata definita dal contesto in cui viene applicata poiché non tutto può essere davvero regolamentato.

-
-

Indice NdP by DigitalCookies

-
-
-
+
+

Indice NdP by DigitalCookies

+
+
+
    -
  • Primari: fornitura(studio di fattibilità, piano di progetto, piano di qualifica, collaudo e consegna del prodotto), sviluppo(analisi dei requisiti, progettazione, codifica)
    • -
  • Supporto: documentazione, verifica(metriche, analisi statica e dinamica), validazione(analisi dinamica)
    • -
  • Organizzativi: gestione(ruoli di progetto, gestione degli incontri, gestione degli strumenti di coordinamento e di versionamento, gestione dei rischi, gestione della formazione individuale)
    • +
  • Primari: fornitura (studio di fattibilità, piano di progetto, piano di qualifica, collaudo e + consegna del prodotto), sviluppo (analisi dei requisiti, progettazione, codifica) +
    • +
  • Supporto: documentazione, verifica (metriche, analisi statica e dinamica), validazione(analisi + dinamica) +
    • +
  • Organizzativi: gestione (ruoli di progetto, gestione degli incontri, gestione degli strumenti + di coordinamento e di versionamento, + gestione dei rischi, gestione della formazione individuale) +
-
+

Piano di progetto

-Il piano di progetto contiene indicazioni sulle scadenze temporali che il gruppo prevede di rispettare -e fornisce un preventivo dei costi da presentare al proponente e derivante dalla pianificazione dettagliata della realizzazione del progetto. -In questo documento vengono inoltre individuati i rischi e analizzate le loro occorrenze, stendendo periodicamente dei consuntivi che vanno sfruttati -per azioni di mitigazione e correttive della pianificazione presentata. -
-A supporto per la definizione di una pianificazione sensata sono inseriti in questo documento diagrammi che possono essere di vario tipo, più comunemente -si decide di utilizzare i diagrammi di Gantt. -In tal modo è importante far emergere le milestone legate a punti critici. + Il piano di progetto contiene indicazioni sulle scadenze temporali che il gruppo prevede di rispettare + e fornisce un preventivo dei costi da presentare al proponente e derivante dalla pianificazione dettagliata della + realizzazione del progetto. + In questo documento vengono inoltre individuati i rischi e analizzate le loro occorrenze, stendendo periodicamente + dei consuntivi che vanno sfruttati + per azioni di mitigazione e correttive della pianificazione presentata. +
+ A supporto per la definizione di una pianificazione sensata sono inseriti in questo documento diagrammi che possono + essere di vario tipo, più comunemente + si decide di utilizzare i diagrammi di Gantt. + In tal modo è importante far emergere le milestone legate + a punti critici.

-
-

Indice PdP by DigitalCookies

-
-
-
+
+

Indice PdP by DigitalCookies

+
+
+
-
+

Piano di qualifica

-Il piano di qualifica è uno tra i documenti più importanti (anche in termini di valutazione di revisione), deve fornire tutte le informazioni relative al -sistema di controllo di qualità per i processi ed i prodotti, basandosi su assunti misurabili ma adattati alle esigenze del proprio progetto. -
-Esso deve implementare degli standard che permettano il miglioramento continuo, tracciando periodicamente tramite misurazioni -i risultati ottenuti sfruttandoli per definire azioni migliorative. -All'interno del PdQ vengono anche raccolte le definizioni dei test, il loro stato e il loro tracciamento. + Il piano di qualifica è uno tra i documenti più importanti (anche in termini di valutazione di revisione), deve + fornire tutte le informazioni relative al + sistema di controllo di qualità per i processi ed i prodotti, basandosi su assunti misurabili ma adattati alle + esigenze del proprio progetto. +
+ Esso deve implementare degli standard che permettano il miglioramento continuo, tracciando periodicamente tramite + misurazioni + i risultati ottenuti sfruttandoli per definire azioni migliorative. + All'interno del PdQ vengono anche raccolte le definizioni dei test, il loro stato e il loro tracciamento.

-
-

Indice PdQ by DigitalCookies

-
-
-
+
+

Indice PdQ by DigitalCookies

+
+
+
-
+

Analisi dei requisiti

-L'analisi dei requisiti contiene la descrizione degli attori del sistema, -definendo poi tutti i casi d'uso individuati a partire dai requisiti, fornendo una visione chiara ai progettisti sul problema da trattare. -
-A seguito di negoziazione con il proponente i requisiti vanno classificati in questo documento sia per grado di importanza sia che per tipologia, -assicurandosi di tenere aggiornata una matrice di tracciamento tra essi e le fonti da cui derivano. + L'analisi dei requisiti contiene la descrizione degli attori del sistema, + definendo poi tutti i casi d'uso individuati a partire dai requisiti, fornendo una visione chiara ai progettisti sul + problema da trattare. +
+ A seguito di negoziazione con il proponente i requisiti vanno classificati in questo documento sia per grado di + importanza sia che per tipologia, + assicurandosi di tenere aggiornata una matrice di tracciamento tra essi e le fonti da cui derivano.

-
-

Indice AR by DigitalCookies

-
-
-
+
+

Indice AR by DigitalCookies

+
+
+
-
+

Specifica tecnica

-La specifica tecnica descrive le tecnologie scelte per lo sviluppo, evidenziandone pregi e difetti, a partire dalle quali si individua l'architettura -generale del sistema per poi individuare le componenti principali di esso tramite livelli gerarchici di decomposizione. -Per ogni componente devono essere specificate la funzione svolta, il tipo di dati in ingresso e in uscita e le dipendenze logiche e fisiche -necessarie per il corretto funzionamento. -
-In questo documento si fa uso di vari diagrammi UML(attività, sequenza, package). -È buona norma contestualizzare i design pattern utilizzati e fare il traccimento delle componenti ai requisiti. + La specifica tecnica descrive le tecnologie scelte per lo sviluppo, evidenziandone pregi e difetti, a partire dalle + quali si individua l'architettura + generale del sistema per poi individuare le componenti principali di esso tramite livelli gerarchici di + decomposizione. + Per ogni componente devono essere specificate la funzione svolta, il tipo di dati in ingresso e in uscita e le + dipendenze logiche e fisiche + necessarie per il corretto funzionamento. +
+ In questo documento si fa uso di vari diagrammi UML(attività, sequenza, package). + È buona norma contestualizzare i design pattern utilizzati e fare il traccimento delle componenti ai requisiti.

-
-

Indice ST by DigitalCookies

-
-
-
+
+

Indice ST by DigitalCookies

+
+
+
-
+

Definizione di prodotto

-La definizione di prodotto scende più nel dettaglio del sistema, andando a definire anche le funzioni delle componenti terminali del sistema, -tramite diagrammi delle classi. -Il livello di dettaglio richiesto prevede la presenza di tutti i dettagli necessari per procedere alla codifica e alla verifica di ciascun modulo, -preferibilmente consentendo lo sviluppo in parallelo. -Sarebbe opportuno includere diagrammi di sequenza per tutte le funzioni più complicate e che prevedono l'interazione di molte componenti. + La definizione di prodotto scende più nel dettaglio del sistema, andando a definire anche le funzioni delle + componenti terminali del sistema, + tramite diagrammi delle classi. + Il livello di dettaglio richiesto prevede la presenza di tutti i dettagli necessari per procedere alla codifica e + alla verifica di ciascun modulo, + preferibilmente consentendo lo sviluppo in parallelo. + Sarebbe opportuno includere diagrammi di sequenza per tutte le funzioni più complicate e che prevedono l'interazione + di molte componenti.

-
-

Indice DP by DigitalCookies

-
-
-
+
+

Indice DP by DigitalCookies

+
+
+
-
+

Manuale utente

-Il manuale utente serve per aiutare l'utente nell'utilizzo del sistema e può essere di varie tipologie che scendono più o meno in dettaglio in base alla tipologia di utente a cui sono destinati. -Questo documento cresce durante lo sviluppo del prodotto e deve avere un approccio incentrato alle funzionalità e a come esse vadano sfruttate piuttosto -che sulle qualità interne del prodotto. -Esso può essere fornito in diversi formati come PDF, cartaceo o ipertestuale. + Il manuale utente serve per aiutare l'utente nell'utilizzo del sistema e può essere di varie tipologie che scendono + più o meno in dettaglio in base alla tipologia di utente a cui sono destinati. + Questo documento cresce durante lo sviluppo del prodotto e deve avere un approccio incentrato alle funzionalità e a + come esse vadano sfruttate piuttosto + che sulle qualità interne del prodotto. + Esso può essere fornito in diversi formati come PDF, cartaceo o ipertestuale.

-
-

Indice MU by DigitalCookies

-
-
-
+
+

Indice MU by DigitalCookies

+
+
+
-
+

Manuale manutentore

-Il manuale manutentore ha la funzione di spiegare ad eventuali manutentori esterni come -interagire con le componenti marginali del sistema per estenderle o correggere eventuali problemi. + Il manuale manutentore ha la funzione di spiegare ad eventuali manutentori esterni come + interagire con le componenti marginali del sistema per estenderle o correggere eventuali problemi. -Esso non sostituisce la definizione di prodotto e non deve scendere in dettagli implementativi interni al prodotto e non pubblici. + Esso non sostituisce la definizione di prodotto e non deve scendere in dettagli implementativi interni al prodotto e + non pubblici.

-
-

Indice MM by DigitalCookies

-
-
-
+
+

Indice MM by DigitalCookies

+
+
+
-
+

Tracciamenti necessari

-Nei vari documenti è importante tracciare in modo corretto e automatizzato requisiti, componenti, moduli e test. -
-I traccimenti devono essere in avanti al fine di garantire la completezza nel grado di sviluppo del sistema e all'indietro per -controllare che quanto prodotto sia realmente necessario rispetto alle richieste. + Nei vari documenti è importante tracciare in modo corretto e automatizzato requisiti, componenti, moduli e test. +
+ I traccimenti devono essere in avanti al fine di garantire la completezza nel grado di sviluppo del sistema e + all'indietro per + controllare che quanto prodotto sia realmente necessario rispetto alle richieste.

    -
  • Requisiti utente (capitolato) <-> requisiti software (AR)
    • -
  • Requisiti software (AR) <-> descrizione di componenti (ST)
    • -
  • Test di unità <-> moduli della progettazione di dettaglio (DP)
    • -
  • Test di integrazione <-> componenti architetturali (ST)
    • -
  • Test di sistema <-> requisiti software (AR)
    • -
  • Test di accettazione <-> requisiti utente (capitolato)
    • +
  • Requisiti utente (capitolato) <-> requisiti software (AR)
    • +
  • Requisiti software (AR) <-> descrizione di componenti (ST)
    • +
  • Test di unità <-> moduli della progettazione di dettaglio (DP) +
    • +
  • Test di integrazione <-> componenti architetturali (ST)
    • +
  • Test di sistema <-> requisiti software (AR)
    • +
  • Test di accettazione <-> requisiti utente (capitolato)
diff --git a/src/cGestioneProgetto.html b/src/cGestioneProgetto.html index 3181c8d..33e5c74 100644 --- a/src/cGestioneProgetto.html +++ b/src/cGestioneProgetto.html @@ -1,203 +1,245 @@

Gestione Progetto

Cos'è un progetto

-Un progetto è un insieme ordinato di attività che devono essere portate a termine, per la cui totalità è richiesto un lavoro collaborativo.
-Tali attività vengono pianificate secondo degli obbiettivi, dei vincoli che sono il tempo e le risorse disponibili e i risultati attesi. -La gestione di progetto è chiamata ad occuparsi di: + Un progetto è un insieme ordinato di attività che devono essere portate a termine, per la cui totalità è richiesto + un lavoro collaborativo.
+ Tali attività vengono pianificate secondo degli obbiettivi, dei vincoli che sono il tempo e le risorse disponibili e + i risultati attesi. + La gestione di progetto è chiamata ad occuparsi di:

    -
  • istanziare i processi in un progetto;
    • -
  • stimare costi e risorse necessarie;/li> -
  • pianificare;
    • -
  • controllare e verificare i risultati delle attività
    • -
  • assegnare le attività alle persone
    • +
  • istanziare i processi in un progetto;
    • +
  • stimare costi e risorse necessarie;
    • +
  • pianificare;
    • +
  • controllare e verificare i risultati delle attività
    • +
  • assegnare le attività alle persone
-

Ruoli di progetto

-All'interno di un progetto, sono necessari vari ruoli cioè funzioni aziendali assegnate al progetto. -Questi si dividono in vari ambiti cioè sviluppo, direzione, amministrazione e qualità. -Ad ogni ruolo corrisponde un determinato profilo professionale richiesto in termini di competenze ed esperienza per poter assumere -quel ruolo. - + All'interno di un progetto, sono necessari vari ruoli cioè funzioni aziendali assegnate al progetto. + Questi si dividono in vari ambiti cioè sviluppo, direzione, amministrazione e qualità. + Ad ogni ruolo corrisponde un determinato profilo professionale richiesto in termini di competenze ed esperienza per + poter assumere quel ruolo.

Responsabile

Punto di riferimento per le comunicazioni con il committente, nei cui confronti rappresenta il progetto. -Deve possedere delle competenze e delle capacità tecniche per poter anticipare l'evoluzione di progetto in modo da pianificare, gestire le risorse umane e tenere -sotto controllo i progressi. -Su di lui sono accentrate le responsabilità di scelta e approvazione, ragion per cui è difficilmente sostituibile e partecipa per tutta la durata del progetto. -Redige organigramma e Piano di progetto e si occupa di approvare i documenti. -Approva l'offerta e i relativi allegati. + Deve possedere delle competenze e delle capacità tecniche per poter anticipare l'evoluzione di progetto in modo da + pianificare, gestire le risorse umane e tenere sotto controllo i progressi. + Su di lui sono accentrate le responsabilità di scelta e approvazione, ragion per cui è difficilmente sostituibile e + partecipa per tutta la durata del progetto. + Redige organigramma e Piano di progetto e si occupa di approvare i documenti. + Approva l'offerta e i relativi allegati.

Amministratore

- Ruolo orizzontale, è responsabile dell'efficienza e dell'operatività dell'ambiente di sviluppo, - deve assicurarsi che in ogni istante le risorse siano presenti e operanti.
- A lui viene affidato il compito di gestione del controllo della configurazione del prodotto, del versionamento e della documentazione di progetto. - Deve inoltre risolvere i problemi legati alla gestione dei processi. - Redige le Norme di Progetto per conto del Responsabile, collabora alla redazione del Piano di progetto e si occupa della redazione e attuazione di piani e procedure di Gestione per la Qualità. - - + Ruolo orizzontale, è responsabile dell'efficienza e + dell'operatività dell'ambiente di sviluppo, deve assicurarsi che in ogni istante le risorse siano presenti e + operanti.
+ A lui viene affidato il compito di gestione del controllo della configurazione del prodotto, del versionamento + e della documentazione di progetto. + Deve inoltre risolvere i problemi legati alla gestione dei processi. + Redige le Norme di Progetto per conto del Responsabile, collabora alla redazione del Piano di progetto e si occupa + della redazione e attuazione di piani e procedure di + Gestione per la Qualità. + +

Analista

-Persona con notevole esperienza professionale e vasta conoscienza del dominio del problema, si occupa esporre il problema in maniera chiara.
-Il loro lavoro ha grande impatto sulla riuscita del progetto, ma sono generalmente pochi e non seguono il progetto fino al suo termine. -Redige lo Studio di fattibilità e l'Analisi dei requisiti. + Persona con notevole esperienza professionale e vasta conoscenza del dominio del problema, si occupa esporre il + problema in maniera chiara.
+ Il loro lavoro ha grande impatto sulla riuscita del progetto, ma sono generalmente pochi e non seguono il progetto + fino al suo termine. + Redige lo Studio di fattibilità e l'Analisi dei requisiti.

Progettista

-Persona con competenze tecniche e tecnologiche aggiornate e ampia esperienza professionale. -Si occupa dello sviluppo della soluzione al problema presentato tramite le attività di progettazione, -spesso assumendo anche responsabilità di scelta e gestione.
-Sono pochi e talvolta seguono il progetto fino alla manutenzione.
-Redige la specifica tecnica, la definizione di prodotto e la parte programmatica del Piano di qualifica. - + Persona con competenze tecniche e tecnologiche aggiornate e ampia esperienza professionale. + Si occupa dello sviluppo della soluzione al problema presentato tramite le attività di + progettazione, spesso assumendo anche responsabilità di scelta e gestione.
+ Sono pochi e talvolta seguono il progetto fino alla manutenzione.
+ Redige la specifica tecnica, la definizione di prodotto e la parte programmatica del Piano di qualifica.

Programmatore

-Persona con competenze tecniche specifiche, ma visione e responsabilità circoscritte, che si occupa di implementare la soluzione trovata dal progettista -tramite attività di codifica per il prodotto e per i test di ausilio alla verifica. -Rimane a lungo all'interno del progetto, partecipando anche alla manutenzione. - + Persona con competenze tecniche specifiche, ma visione e responsabilità circoscritte, che si occupa di implementare + la soluzione trovata dal progettista + tramite attività di codifica per il prodotto e per i test di ausilio alla verifica. + Rimane a lungo all'interno del progetto, partecipando anche alla manutenzione.

Verificatore

-Persona con competenze tecniche, esperienze di progetto e conoscenza delle norme, oltre che a capacità di giudizio e relazione. -Si occupa di attività di verifica e validazione, partecipa all'intero ciclo di vita e -assicurandosi che quanto fatto soddisfi le attese. -Redige la parte retrospettiva del piano di qualifica, ossia illustra l'esito e la completezza delle verifiche e delle prove effettuate. - - + Persona con competenze tecniche, esperienze di progetto e conoscenza delle norme, oltre che a capacità di giudizio e + relazione. + Si occupa di attività di verifica e validazione, partecipa all'intero ciclo di vita e assicurandosi che quanto fatto + soddisfi le attese. + Redige la parte retrospettiva del piano di qualifica, ossia illustra l'esito e la completezza delle verifiche e + delle prove effettuate.

Gestore della qualità

-Non si tratta di un ruolo ma di una funzione aziendale. -Si occupa di individuare le dimensioni di qualità dei prodotti e dei processi, cioè si assicura della sufficienza della qualità prodotta, sia verso il committente -che verso la direzione aziendale. -Fornisce confidenza nel lavoro svolto definendo e manutenendo i processi aziendali(PDCA) e verificandone la corretta applicazione. - + Non si tratta di un ruolo ma di una funzione aziendale. + Si occupa di individuare le dimensioni di qualità dei prodotti e dei processi, cioè si assicura della sufficienza + della qualità prodotta, sia verso il committente che verso la direzione aziendale. + Fornisce confidenza nel lavoro svolto definendo e manutenendo i processi aziendali (PDCA) e verificandone la + corretta + applicazione.

Pianificazione di progetto

-La pianificazione di progetto serve a definire le attività, controllandone l'attuazione -cosi da avere una base per l'allocazione delle risorse da stimare. -Lo stato di avanzamento di un prodotto è rilevante solo se fornisce informazioni per riflettere sulla pianificazione. -Essa è utile per stimare e controllare la scadenze(assicurarsi di rispettare la data di fine) e i costi. -Per fare ciò si possono usare vari tipi di diagrammi che hanno funzionalità differenti. - + La pianificazione di progetto serve a definire le attività, controllandone l'attuazione + cosi da avere una base per l'allocazione delle risorse da stimare. + Lo stato di avanzamento di un prodotto è rilevante solo se fornisce informazioni per riflettere sulla + pianificazione. + Essa è utile per stimare e controllare la scadenze(assicurarsi di rispettare la data di fine) e i costi. + Per fare ciò si possono usare vari tipi di diagrammi che hanno funzionalità differenti.

Diagrammi di Gantt

-Rappresentano la durata, la sequenzialità e il parallelismo delle attività, permettendo -di confrontare le stime con i progressi effettivi. -Può risultare utile per stimare il numero di persone minime per svolgere il progetto, -guardando il punto di massimo parallelismo. -Non è particolarmente atto alla gestione delle dipendenze. - + Rappresentano la durata, la sequenzialità e il parallelismo delle attività, permettendo + di confrontare le stime con i progressi effettivi. + Può risultare utile per stimare il numero di persone minime per svolgere il progetto, + guardando il punto di massimo parallelismo. + Non è particolarmente atto alla gestione delle dipendenze.

WBS - Work Breakdown Structure

-Rappresenta la struttura gerarchica delle attività del progetto, scompone quindi ogni attività in più sottoattività identificate univocamente, fortemente coese e non -necessariamente sequenziali. - + Rappresenta la struttura gerarchica delle attività del progetto, scompone quindi ogni attività in più sottoattività + identificate univocamente, fortemente coese e non necessariamente sequenziali.

PERT – Programme Evaluation and Review Technique

-Rappresenta le dipendenze temporali tra le attività, unificando le due tecniche precedenti. -Portano quindi a ragionare e valutare le scadenze di progetto, fornendo per ogni dipendenza un tempo di slack che rappresenta -la quantità di tempo di cui un evento può essere ritardato senza influenzare però l'andamento del progetto.
-Diventa dunque facile individuare dei cammini critici con slack time uguale a zero o molto bassi. - + Rappresenta le dipendenze temporali tra le attività, unificando le due tecniche precedenti. + Portano quindi a ragionare e valutare le scadenze di progetto, fornendo per ogni dipendenza un tempo di slack che + rappresenta la quantità di tempo di cui un evento può essere ritardato senza influenzare però l'andamento del + progetto.
+ Diventa dunque facile individuare dei cammini critici con slack time uguale a zero o molto bassi.

Stimare i costi di progetto

-La stima dei costi di progetto è responsabilità del -Responsabile di progetto, solitamente misurati in tempo/persona ci sono due leggi che influenzano - la stima dei costi necessari: - - + La stima dei costi di progetto è responsabilità del + Responsabile di progetto, solitamente misurati in tempo/persona ci sono due leggi che influenzano + la stima dei costi necessari:

-Il lavoro si espande per riempire tutto il tempo disponibile. -
Legge di Parkinson
+ Il lavoro si espande per riempire tutto il tempo disponibile. +
Legge di Parkinson
-Minore è il prezzo di un -servizio - o di una commodity, maggiore sarà la quantità richiesta. -
Legge della domanda
+ Minore è il prezzo di un + servizio + o di una commodity, maggiore sarà la quantità richiesta. +
Legge della domanda

-Tali leggi mettono in evidenza problematiche di stima dei costi e in particolare che troppo tempo a disposizione può un impatto negativo sull' -efficacia. -Al fine di avere un prezzo concorrenziale è invece importante tenere bassi i costi. -Per stimare i costi si può ricorrere a giudizi di esperti, a stime per analogia o a modelli di costi come ad esempio CoCoMo. -
-Il Constructive Cost Model è uno strumento per la stima del tempo/persona in mesi/persona, che si basa sulle caratteristiche relative al software da produrre -assumendo un modello sequenziale di sviluppo da zero. -Ne esistono varianti avanzate che tengono conto di fattori moltiplicativi legati agli attributi perseguiti nel prodotto e posseduti in termini di competenze. + Tali leggi mettono in evidenza problematiche di stima dei costi e in particolare che troppo tempo a disposizione può + un impatto negativo sull' + efficacia. + Al fine di avere un prezzo concorrenziale è invece importante tenere bassi i costi. + Per stimare i costi si può ricorrere a giudizi di esperti, a stime per analogia o a modelli di costi come ad esempio + CoCoMo. +
+ Il Constructive Cost Model è uno strumento per la stima del tempo/persona in mesi/persona, che si basa sulle + caratteristiche relative al software da produrre assumendo un modello sequenziale di sviluppo da zero. + Ne esistono varianti avanzate che tengono conto di fattori moltiplicativi legati agli attributi perseguiti nel + prodotto e posseduti in termini di competenze.

Rischi di progetto

-Al fine di attuare una corretta e quindi utile gestione dei rischi di progetto -bisogna prima identificarli, nel contesto di progetto, di prodotto e di mercato in cui ci si colloca. -Bisogna dunque procedere con un'analisi delle probabilità di occorrenza e delle possibili conseguenze, pianificando come evitarli o mitigarne gli effetti. -Ciò viene fatto durante la pianificazione di progetto, -e le fonti principali di rischio sono:le tecnologie scelte, i rapporti interpersonali, l'organizzazione del lavoro, i requisiti e i rapporti con gli stakeholder e i tempi e i costi stimati. - -
- -Durante lo svolgimento del progetto viene costantemente eseguito un controllo -per rilevare eventuali indicatori di rischio.
-I livelli di rischio vanno regolarmente aggiornati e va valutato se gli effetti dei rischi siano cambiati nel tempo; è necessario -riportare periodicamente ciascun rischio serio rilevato all'attenzione della gestione di progetto. - -

-

Fattori di fallimento

+ Al fine di attuare una corretta e quindi utile gestione dei rischi di progetto bisogna prima identificarli, + nel contesto di progetto, di prodotto e di mercato in cui ci si colloca. + Bisogna dunque procedere con un'analisi delle probabilità di occorrenza e delle possibili conseguenze, pianificando + come evitarli o mitigarne gli effetti. + Ciò viene fatto durante la pianificazione di progetto, e le fonti principali di rischio sono: le tecnologie scelte, + i rapporti interpersonali, l'organizzazione del lavoro, i requisiti, i rapporti con gli stakeholder, + i tempi e i costi stimati. + +
+ + Durante lo svolgimento del progetto viene costantemente eseguito un controllo + per rilevare eventuali indicatori di rischio.
+ I livelli di rischio vanno regolarmente aggiornati e va valutato se gli effetti dei rischi siano cambiati nel tempo; + è necessario riportare periodicamente ciascun rischio serio rilevato all'attenzione della gestione di progetto. + +

+

Fattori di fallimento

    -
  • Requisiti incompleti
    • -
  • Mancato coinvolgimento del cliente
    • -
  • Mancanza di risorse
    • -
  • Aspettative non realistiche
    • -
  • Mancanza di supporto esecutivo
    • -
  • Fluttuazione dei requisiti
    • -
  • Presenza nel team di Carlo (si scherza, mah)
    • +
  • Requisiti incompleti
    • +
  • Mancato coinvolgimento del cliente
    • +
  • Mancanza di risorse
    • +
  • Aspettative non realistiche
    • +
  • Mancanza di supporto esecutivo
    • +
  • Fluttuazione dei requisiti
    • +
  • Presenza nel team di Carlo (si scherza, mah)

Fattori di successo

    -
  • Coinvolgimento del cliente
    • -
  • Supporto della direzione esecutiva
    • -
  • Definizione chiara dei requisiti
    • -
  • Pianificazione corretta
    • -
  • Aspettative realistiche
    • -
  • Personale competente
    • +
  • Coinvolgimento del cliente
    • +
  • Supporto della direzione esecutiva
    • +
  • Definizione chiara dei requisiti
    • +
  • Pianificazione corretta
    • +
  • Aspettative realistiche
    • +
  • Personale competente
- + diff --git a/src/cIngRequisiti.html b/src/cIngRequisiti.html index c7c301c..6e48292 100644 --- a/src/cIngRequisiti.html +++ b/src/cIngRequisiti.html @@ -2,174 +2,195 @@

Ingegneria dei Requisiti

Definizione

- L'ingegneria dei requisiti denota l’insieme delle attività necessarie per il trattamento -sistematico dei requisiti. -I requisiti software sono uno dei prodotti del relativo processo. -
-Un requisito può essere definito secondo tre visioni distinte: + L'ingegneria dei requisiti denota l’insieme delle attività necessarie per il trattamento + sistematico dei requisiti. + I requisiti software sono uno dei prodotti del relativo processo. +
+ Un requisito può essere definito secondo tre visioni distinte:

-1. Condizione necessaria ad un utente per risolvere un problema o raggiungere un obiettivo. -
-2. Condizione che deve essere soddisfatta o posseduta da un sistema per adempiere ad un obbligo. -
-3. Descrizione documentata di una condizione di una delle due tipologie precedenti. -
Glossario IEEE
+ 1. Condizione necessaria ad un utente per risolvere un problema o raggiungere un obiettivo. +
+ 2. Condizione che deve essere soddisfatta o posseduta da un sistema per adempiere ad un obbligo. +
+ 3. Descrizione documentata di una condizione di una delle due tipologie precedenti. +
Glossario IEEE

-In particolare un requisito rappresenta una caratteristica che il software deve garantire e deve essere messa a contratto con il cliente. -Esso deve essere quindi tracciabile da una fonte, in modo da essere verificabile in seguito. -
-I requisiti possono essere classificati secondo diversi criteri. - + In particolare un requisito rappresenta una caratteristica che il software deve garantire e deve essere messa a + contratto con il cliente. + Esso deve essere quindi tracciabile da una fonte, in modo da essere verificabile in seguito. +
+ I requisiti possono essere classificati secondo diversi criteri.

Classificazione

-I requisiti si possono esprimere ad alto livello come richieste generali dell'utente -oppure in modo più dettagliato con definizioni formali delle funzionalità di sistema. -
-È bene inoltre distinguere tra requisiti derivanti da bisogni e vincoli sul prodotto software da sviluppare e tra i requisiti -derivati dal modo in cui si vuole svilupparlo, cioè dai processi istanziati. - + I requisiti si possono esprimere ad alto livello come richieste generali dell'utente oppure in modo più dettagliato + con definizioni formali delle funzionalità di sistema. +
+ È bene inoltre distinguere tra requisiti derivanti da bisogni e vincoli sul prodotto software da sviluppare e tra i + requisiti derivati dal modo in cui si vuole svilupparlo, cioè dai processi istanziati.

Tipologia

-In base allo strumento con cui un requisito viene validato esso può appartenere ad una delle seguenti categorie: + In base allo strumento con cui un requisito viene validato esso può appartenere ad una delle seguenti categorie:

    -
  • Funzionali: descrivono i -servizi - richiesti al sistema e possono essere validati tramite test, dimostrazioni formali e revisioni;
    • +
  • Funzionali: descrivono i + servizi + richiesti al sistema e possono essere validati tramite test, dimostrazioni formali e revisioni; +
    • -
  • Prestazionali: descrivono il grado di prestazione che deve raggiungere il sistema in particolari situazioni (es. latenza server), possono essere -validati tramite misurazioni delle prestazioni;
    • +
  • Prestazionali: descrivono il grado di prestazione che deve raggiungere il sistema in particolari + situazioni (es. latenza server), possono essere validati tramite misurazioni delle prestazioni; +
    • -
  • Qualitativi: descrivono le qualità richieste dal prodotto e possono essere validati soltanto tramite verifiche ad hoc;
    • +
  • Qualitativi: descrivono le qualità richieste dal prodotto e possono essere validati soltanto tramite + verifiche ad hoc; +
    • -
  • Vincolo: descrivono vincoli imposti dal cliente o dal dominio del problema; possono derivare da necessità realizzative, -scelte normative o obblighi contrattuali e vengono validati tramite revisioni.
    • +
  • Vincolo: descrivono vincoli imposti dal cliente o dal dominio del problema; possono derivare da necessità + realizzative, scelte normative o obblighi contrattuali e vengono validati tramite revisioni. +

Importanza strategica

-Un aspetto importante legato ai requisiti è loro negoziazione con il proponente, che deve tenere conto delle tempistiche e del grado di -esperienza del gruppo.
-A tal proposito è bene dividere i requisiti secondo il loro grado d'importanza: quelli obbligatori sono irrinunciabili per gli stakeholder e non più negoziabili; quelli desiderabili possono essere omessi ma rappresentano un valore aggiunto - d'interesse riconosciuto; mentre quelli facoltativi sono utili solo relativamente e possono essere contrattati in seguito, - eventualmente a fronte di pagamento addizionale. + Un aspetto importante legato ai requisiti è loro negoziazione con il proponente, che deve tenere conto delle + tempistiche e del grado di esperienza del gruppo.
+ A tal proposito è bene dividere i requisiti secondo il loro grado d'importanza: quelli obbligatori sono + irrinunciabili per gli stakeholder e non più + negoziabili; quelli desiderabili possono essere omessi ma rappresentano un valore aggiunto + d'interesse riconosciuto; mentre quelli facoltativi sono utili solo relativamente e possono essere + contrattati in seguito, eventualmente a fronte di pagamento addizionale.

SEMAT

-SEMAT prevede sei stati di progresso con cui poter valutare il grado con cui i requisiti sono individuati e implementati. -

-Inizialmente il progresso viene catalogato come conceived, cioè gli stakeholders hanno identificato il committente e vedono sufficienti opportunità per far partire un progetto. -Una volta chiariti i macro bisogni e fissati i meccanismi di gestione dei requisiti(configurazione e cambiamento) viene raggiunto lo stato di bounded. -Quando poi i requisiti vengono classificati e quelli fondamentali sono definiti si raggiunge il -grado coherent. - -Al termine di eventuali negoziazioni al raggiumento di un insieme di requisiti che definiscono -un sistema soddisfacente per gli stakeholders acceptable. -
-Procedendo con lo sviluppo, una volta soddisfatti i principali requisiti e giunti ad un punto -adeguato al rilascio e all'uso addressed. -
-Infine quando il prodotto soddisfa abbastanza requisiti da meritare la piena approvazione degli stakeholders si raggiunge il grado fullfilled. + SEMAT prevede sei stati di progresso con cui poter valutare il grado con cui i requisiti sono individuati e + implementati. +

+ Inizialmente il progresso viene catalogato come conceived, cioè gli stakeholders hanno identificato il + committente e vedono sufficienti opportunità per far partire un progetto. + Una volta chiariti i macro bisogni e fissati i meccanismi di gestione dei requisiti(configurazione e cambiamento) + viene raggiunto lo stato di bounded. + Quando poi i requisiti vengono classificati e quelli fondamentali sono definiti si raggiunge il + grado coherent. + + Al termine di eventuali negoziazioni al raggiumento di un insieme di requisiti che definiscono + un sistema soddisfacente per gli stakeholders acceptable. +
+ Procedendo con lo sviluppo, una volta soddisfatti i principali requisiti e giunti ad un punto + adeguato al rilascio e all'uso addressed. +
+ Infine quando il prodotto soddisfa abbastanza requisiti da meritare la piena approvazione degli stakeholders si + raggiunge il grado fullfilled.

Approccio all'analisi

-L'analisi è un'attività di processo di sviluppo che inizia dallo studio dei bisogni e delle fonti per arrivare a classificare -i requisiti modellando concettualmente il sistema tramite use case e assegnando i vari requisiti a parti distinti del sistema. -
-È un'attività che va ripetuta più volte, in base al ciclo di vita adottato, al fine di concordare meglio i requisiti con il proponente. -
-In base alla tipologia di progetto si può procedere all'identificazione dei requisiti in due modi differenti: -nell'approccio funzionale si ha un uso limitato dei linguaggi formali e la specifica di funzioni seguita da una progettazione di tipo -top-down, mentre nell'approccio Orientato agli oggetti -l'analisi usa prevalentemente formalismi grafici con una prima identificazione delle classi e procede ad una progettazione -di tipo bottom-up con attenzione al riuso di componenti prefabbricati e realizzazione di componenti riusabili. -
-
-Il processo di ingegneria dei requisiti raggruppa quattro attività: studio di fattibilità, acquisizione e analisi dei requisiti, -specifica dei requisiti e validazione dei requisiti. + L'analisi è un'attività di processo di sviluppo che inizia dallo studio dei bisogni e delle + fonti per arrivare a classificare i requisiti modellando concettualmente il sistema tramite use case e + assegnando i vari requisiti a parti distinti del sistema. +
+ È un'attività che va ripetuta più volte, in base al ciclo di vita adottato, al fine di concordare meglio i requisiti + con il proponente. +
+ In base alla tipologia di progetto si può procedere all'identificazione dei requisiti in due modi differenti: + nell'approccio funzionale si ha un uso limitato dei linguaggi formali e la specifica di funzioni seguita da + una progettazione di tipo top-down, mentre nell'approccio Orientato agli oggettil'analisi usa prevalentemente + formalismi grafici con una prima identificazione delle classi e procede ad una progettazione di tipo bottom-up con + attenzione al riuso di componenti prefabbricati e realizzazione di componenti riusabili. +
+
+ Il processo di ingegneria dei requisiti raggruppa quattro attività: studio di fattibilità, acquisizione e analisi + dei requisiti, specifica dei requisiti e validazione dei requisiti.

Studio di fattibilità

-È uno studio senza ricerche impegnative ma chiaro che viene svolto inizialmente per valutare i rischi, i costi e i benefici -legati al sistema in esame. Quest'attività produce il documento Studio di fattibilità -che deve descrivere in maniera chiara gli obiettivi del progetto e valutazioni su approcci -alternativi(scelte architetturali, strategie realizzative e operative), è fatto sia in ottica del proponente che -di chi realizza il prodotto. -Deve anche tener conto della fattibilità tecnica e delle scadenze temporali, in relazione alle risorse disponibili. + È uno studio senza ricerche impegnative ma chiaro che viene svolto inizialmente per valutare i rischi, i costi e i + benefici + legati al sistema in esame. Quest'attività produce il documento Studio di fattibilità + che deve descrivere in maniera chiara gli obiettivi del progetto e valutazioni su approcci + alternativi(scelte architetturali, strategie realizzative e operative), è fatto sia in ottica del proponente che + di chi realizza il prodotto. + Deve anche tener conto della fattibilità tecnica e delle scadenze temporali, in relazione alle risorse disponibili.

Acquisizione e analisi dei requisiti

-Una buona individuazione dei requisiti con il proponente -spetta agli analisti tramite tecniche di analisi come: -studio del dominio(fonte di requisiti impliciti), interazione con il cliente(fonte di requisiti espliciti) sottoforma di interviste o di discussione di scenari, -brainstorming o prototipazione(esterna o interna). -
-È importante fare una buona analisi perché da essa dipende la -soddisfazione del cliente e quindi il successo del progetto, -non sempre il cliente sa esplicitare tutti i suoi bisogni. + Una buona individuazione dei requisiti con il proponente spetta agli analisti tramite tecniche di analisi come: + studio del dominio(fonte di requisiti impliciti), interazione con il cliente(fonte di requisiti espliciti) + sottoforma di interviste o di discussione di scenari, brainstorming o prototipazione(esterna o interna). +
+ È importante fare una buona analisi perché da essa dipende la soddisfazione del cliente e quindi il successo del + progetto, non sempre il cliente sa esplicitare tutti i suoi bisogni.

Specifica dei requisiti

-I dati raccolti durante l'analisi vanno raccolti in dei -requisiti specificati e documentati nel documento di Analisi dei requisiti, -in particolare essi devono essere ordinati, classificati e identificati univocamente. -E nella loro totalità devono assicurare di essere necessari e sufficienti. + I dati raccolti durante l'analisi vanno raccolti in dei requisiti specificati e documentati nel documento di + Analisi dei requisiti, in particolare essi devono essere ordinati, classificati e identificati univocamente. + E nella loro totalità devono assicurare di essere necessari e sufficienti. -

+

-I requisiti vanno qui trascritti in un linguaggio formale o grafico -che limiti le ambiguità per i progettisti. -Inoltre lo standard IEEE 830-1998 -individua 8 qualità essenziali: + I requisiti vanno qui trascritti in un linguaggio formale o grafico che limiti le ambiguità per i progettisti. + Inoltre lo standard IEEE 830-1998 individua 8 qualità essenziali:

    -
  • assenza di ambiguità;
    • -
  • correttezza;
    • -
  • completezza;
    • -
  • verificabilità;
    • -
  • consistenza;
    • -
  • modificabilità(automatizzabile);
    • -
  • tracciabilità;
    • -
  • ordinamento per rilevanza.
    • +
  • assenza di ambiguità;
    • +
  • correttezza;
    • +
  • completezza;
    • +
  • verificabilità;
    • +
  • consistenza;
    • +
  • modificabilità(automatizzabile);
    • +
  • tracciabilità;
    • +
  • ordinamento per rilevanza.

Validazione dei requisiti

-Viene assicurato che i requisiti individuati rappresentino il sistema -richiesto dal cliente, rispettando le qualità sopra descritte. -
-È importante quindi assicurarsi che i requisiti abbiano chiarezza espressiva, -chiarezza strutturale(classificazione precisa e giusta separazione tra -funzionali e non) e atomicità. - + Viene assicurato che i requisiti individuati rappresentino il sistema richiesto dal cliente, rispettando le qualità + sopra descritte. +
+ È importante quindi assicurarsi che i requisiti abbiano chiarezza espressiva, chiarezza strutturale(classificazione + precisa e giusta separazione tra funzionali e non) e atomicità.

Tracciamento

-I requisiti vanno raccolti in matrici di tracciamento -che identifichino con una classificazione univoca e sequenziale, basata -su coppie di categorie e numero.
-I requisiti vanno tracciati con le loro fonti e successivamente -con le parti della specifica e parti del sistema, per consentire valutazioni -sull'impatto e sulla fattibilità tecnica nella gestione dei cambiamenti. - + I requisiti vanno raccolti in matrici di tracciamento che identifichino con una classificazione univoca e + sequenziale, + basata su coppie di categorie e numero.
+ I requisiti vanno tracciati con le loro fonti e successivamente con le parti della specifica e parti del sistema, + per consentire valutazioni sull'impatto e sulla fattibilità tecnica nella gestione dei + cambiamenti.

@@ -177,9 +198,10 @@

Tracciamento


- + diff --git a/src/cIntroduzione.html b/src/cIntroduzione.html index 790bbda..22e763d 100644 --- a/src/cIntroduzione.html +++ b/src/cIntroduzione.html @@ -1,134 +1,166 @@

Introduzione

- +

Definizione

-L'ingegneria del software nasce nel 1968, essa non è un ramo dell'informatica bensì una disciplina che cerca di applicare i -principi ingegneristici alla produzione del software, basandosi sull'informatica nello stesso modo in cui l'ingegneria meccanica si basa sulla fisica. + L'ingegneria del software nasce nel 1968, essa non è un ramo dell'informatica bensì una disciplina che cerca di + applicare i principi ingegneristici alla produzione del software, basandosi sull'informatica nello stesso modo in + cui l'ingegneria meccanica si basa sulla fisica. -Una definizione é: + Una definizione é:

-L’approccio sistematico, disciplinato e quantificabile allo sviluppo, l’uso, la manutenzione e il ritiro del software. -
IEEE
+ L’approccio sistematico, disciplinato e quantificabile allo sviluppo, l’uso, la manutenzione e il ritiro del + software. +
IEEE

-SWE pur basandosi su tutti gli ambiti dell'informatica si relaziona anche con altre discipline: + SWE pur basandosi su tutti gli ambiti dell'informatica si relaziona anche con altre discipline:

    -
  • Scienze gestionali e Economia: per gestire tempo, risorse, organizzazioni e persone; -
    • +
  • Scienze gestionali e Economia: per gestire tempo, risorse, organizzazioni e persone;
    • -
  • Ingegneria dei sistemi e elettronica; -
    • +
  • Ingegneria dei sistemi e elettronica;
    • -
  • Psicologia e Sociologia: per le relazioni umane di comprensione e di apprendimento. -
    • +
  • Psicologia e Sociologia: per le relazioni umane di comprensione e di apprendimento. +

-Per perseguire la qualità del prodotto l'ingegneria del software cerca di fornire un approccio sistematico, cioè metodico, -una lista di azioni ripetibili da usare anche come lista di controllo; disciplinato, cioè sottoposto a norme precise che puntano a fornire - best practice, -e infine quantificabile cioè in grado di fornire una stima ragionevole delle risorse necessarie. + Per perseguire la qualità del prodotto l'ingegneria del software cerca di fornire un approccio sistematico, + cioè metodico, una lista di azioni ripetibili da usare anche come lista di controllo; disciplinato, cioè + sottoposto a norme precise che puntano a fornire best practice, + e infine quantificabile cioè in grado di fornire una stima ragionevole delle risorse necessarie.

-L'approccio dell'ingegneria del software per la realizzazione di sistemi software impegnativi che richiedono collaborazione tra persone mira a garantire: -capacità di produrre in grande e in piccolo, -efficacia, -efficienza durante l'intero ciclo di vita del prodotto software. -Questi concetti sono in contrasto tra loro poiché l'efficacia mira a valutare quanto il prodotto soddisfa le attese, spesso per raggiungere la massima efficacia -è necessario l'impiego di molte risorse mentre la massima efficienza è evitare l'uso di risorse. -Ricordiamo che il ciclo di vita del software non ha termine con la consegna al proponente del prodotto, poiché -prevede varie forme di manutenzione: correttiva, adattiva ed evolutiva. -
-La manutenibilità è dunque qualità fondamentale da garantire. + L'approccio dell'ingegneria del software per la realizzazione di sistemi software impegnativi che richiedono + collaborazione tra persone mira a garantire: + capacità di produrre in grande e in piccolo, + efficacia, + efficienza durante l'intero ciclo di vita del prodotto software. + Questi concetti sono in contrasto tra loro poiché l'efficacia mira a valutare quanto il prodotto soddisfa le attese, + spesso per raggiungere la massima efficacia è necessario l'impiego di molte risorse mentre la massima efficienza è + evitare l'uso di risorse. + Ricordiamo che il ciclo di vita del software non ha termine con la consegna al proponente del prodotto, poiché + prevede varie forme di manutenzione: correttiva, adattiva ed evolutiva. +
+ La manutenibilità è dunque qualità fondamentale da garantire.

Principi etici

-L'ingegneria del software segue anche alcuni principi etici: considera la qualità come primo obiettivo, impegnarsi a produrre software di alta qualità, -aiutare il cliente a comprendere i suoi veri bisogni, adottare i processi più adatti al progetto, ridurre la distanza intellettuale tra software e il problema da risolvere, -essere proattivi nel rimuovere gli errori e motivare, formare, far crescere le persone. + L'ingegneria del software segue anche alcuni principi etici: considera la qualità come primo obiettivo, impegnarsi a + produrre software di alta qualità, aiutare il cliente a comprendere i suoi veri bisogni, adottare i processi più + adatti al progetto, ridurre la distanza intellettuale tra software e il problema da risolvere, essere proattivi nel + rimuovere gli errori e motivare, formare, far crescere le persone.

4 P

-L'ingegneria del software coinvolge 4 aspetti essenziali definiti dalle 4P: persone, prodotto, progetto e processo. -

-Persone -
-Coloro che partecipano in un momento durante il ciclo di vita del software, in generale gli - stakeholder. -
-Esse posso ricoprire vari ruoli: + L'ingegneria del software coinvolge 4 aspetti essenziali definiti dalle 4P: persone, prodotto, progetto e processo. +

+ Persone +
+ Coloro che partecipano in un momento durante il ciclo di vita del software, in generale gli + stakeholder. +
+ Esse posso ricoprire vari ruoli:

    -
  • Business management: coloro che fissano gli obiettivi in termini di costi, profitto e priorità strategiche; -
    • +
  • + Business management: coloro che fissano gli obiettivi in termini di costi, profitto e priorità + strategiche; +
    • -
  • Project management: coloro che gestiscono le risorse di progetto, riferendo all'organizzazione e al cliente; -
    • +
  • + Project management: coloro che gestiscono le risorse di progetto, riferendo all'organizzazione e al + cliente; +
    • -
  • Development team: coloro che realizzano effettivamente il prodotto, l'ingegnere del software si colloca qui; -
    • -
  • Customers: coloro che comprano il prodotto software; -
    • +
  • + Development team: coloro che realizzano effettivamente il prodotto, l'ingegnere del software si colloca + qui; +
    • +
  • Customers: coloro che comprano il prodotto software;
    • -
  • End users: coloro che lo utilizzano. -
    • +
  • End users: coloro che lo utilizzano.

-Prodotto
-L'insieme del software e della documentazione. -

-Progetto
-Il progetto sono tutte le attività necessarie alla produzione del prodotto software, ogni progetto è collaborativo e deve essere organizzato e gestito -con una pianificazione vincolante e degli obiettivi precisi dati dalle risorse a disposizione e dalle attese del proponente. -Una buona pianificazione è proattiva nell'attuazione di azioni per prevenire il fallimento del progetto, si parla quindi di approccio -"by construction" più che "by correction". -Un progetto è l'insieme di: + Prodotto
+ L'insieme del software e della documentazione. +

+ Progetto
+ Il progetto sono tutte le attività necessarie alla + produzione del prodotto software, ogni progetto è collaborativo e deve essere organizzato e gestito + con una pianificazione vincolante e degli obiettivi precisi dati dalle risorse a disposizione e dalle attese del + proponente. + Una buona pianificazione è proattiva nell'attuazione di azioni per prevenire il fallimento + del progetto, si parla quindi di approccio "by construction" più che "by correction". Un progetto è l'insieme di:

    -
  • pianificazione;
  • analisi dei requisiti;
    • -
  • progettazione;
    • -
  • realizzazione;
    • -
  • verifica e validazione;
    • -
  • manutenzione.
    • - +
  • pianificazione;
    • +
  • analisi dei requisiti;
    • +
  • progettazione;
    • +
  • realizzazione;
    • +
  • verifica e validazione;
    • +
  • manutenzione.

-

-Processo
-È l'insieme delle attività aggregate per obiettivi comuni, il cui svolgimento è necessario per progredire con il progetto in accordo con il ciclo di vita adottato. -I processi dividono come le attività sono aggregate le une alle altre, il loro ordine, metodologia di attuazione e grado di libertà. +

+ Processo
+ È l'insieme delle attività aggregate per obiettivi comuni, il cui svolgimento è necessario per progredire con il + progetto in accordo con il ciclo di vita adottato. + I processi dividono come le attività sono aggregate le une alle altre, il loro ordine, metodologia di attuazione e + grado di libertà.

Ingegnere vs Programmatore

-Il programmatore è stata una figura professionale dominante negli anni '50-'70, che svolgeva un'attività fortemente creativa e personalizzata al fine di realizzare programmi da solo e secondo la propria responsabilità tecnica. -
-Al contrario un ingegnere del software si occupa della realizzazione di parti di un sistema complesso che possono essere modificate da altri; non può quindi limitarsi solmente alla realizzazione di software funzionante ma deve -essere lungimirante e applicare compromessi tra costi, qualità e risorse. -Egli deve dunque avere in mente il quadro generale del sistema a cui contribuisce. + Il programmatore è stata una figura professionale dominante negli anni '50-'70, che svolgeva un'attività fortemente + creativa e personalizzata al fine di realizzare programmi da solo e secondo la propria responsabilità tecnica. +
+ Al contrario un ingegnere del software si occupa della realizzazione di parti di un sistema complesso che possono + essere modificate da altri; non può quindi limitarsi solamente alla realizzazione di software funzionante ma deve + essere lungimirante e applicare compromessi tra costi, qualità e risorse. + Egli deve dunque avere in mente il quadro generale del sistema a cui contribuisce.

- - - + + diff --git a/src/cIntroduzioneVV.html b/src/cIntroduzioneVV.html index ba69c18..ee272ea 100644 --- a/src/cIntroduzioneVV.html +++ b/src/cIntroduzioneVV.html @@ -2,92 +2,135 @@

Introduzione a Verifica e Validazione

Definizione

-La verifica è un processo che si occupa di fornire evidenza concreta che i risultati ottenuti -come output di una particolare fase del ciclo di vita di sviluppo del software soddisfino i requisiti. -Per fare ciò la verifica viene eseguita durante lo sviluppo prestando attenzione alla consistenza, alla completezza, alla correttezza del software e della documentazione ad esso relativa. -
-La verifica si occupa dunque di accertare che nella fase in esame non si siano introdotti errori e è la base su cui poter passare alla validazione. -
-
-La validazione è un processo per confermare in modo definitivo che le caratteristiche del software siano conformi ai bisogni dell'utente e all'uso previsto, fornendo evidenza obiettiva a seguito di analisi del prodotto che mostri come i requisiti siano implementati dal software in maniera consistente. -La validazione non si applica ad un particolare segmento temporale ma è una conferma finale, -una self-fulfilling prophecy. + La verifica è un processo che si occupa di fornire evidenza concreta che i risultati ottenuti + come output di una particolare fase del ciclo di vita di + sviluppo del software soddisfino i requisiti. + Per fare ciò la verifica viene eseguita durante lo sviluppo prestando attenzione alla consistenza, alla completezza, + alla correttezza del software e della documentazione ad esso relativa. +
+ La verifica si occupa dunque di accertare che nella fase in esame non si siano introdotti errori e è la base su cui + poter passare alla validazione. +
+
+ La validazione è un processo per confermare in modo definitivo che le caratteristiche del software siano + conformi ai bisogni dell'utente e all'uso previsto, fornendo evidenza obiettiva a seguito di analisi del prodotto + che mostri come i requisiti siano implementati dal software in maniera consistente. + La validazione non si applica ad un particolare segmento temporale ma è una conferma finale, + una self-fulfilling prophecy.

Forme di verifica

-La verifica si può condurre tramite analisi statica o analisi dinamica. -
-
-L'analisi statica studia le caratteristiche del codice sorgente, o tal volta del codice oggetto, e della documentazione ad essi associata senza richiedere l'esecuzione del prodotto in alcuna sua parte, in questo modo viene analizzata la conformità alle norme, l'assenza di difetti e la presenza di proprietà positive. -
-Viene applicata ad ogni prodotto di processo tramite metodi di lettura(desk check) per i prodotti semplici, tramite le tecniche inspection e walkthrough, o tramite metodi formali basati sulla prova assistita di qualità la cui controparte dinamica sarebbe troppo onerosa da dimostrare. + La verifica si può condurre tramite analisi statica o analisi dinamica. +
+
+ L'analisi statica studia le caratteristiche del codice sorgente, o tal volta del codice oggetto, e della + documentazione ad essi associata senza richiedere l'esecuzione del prodotto in alcuna sua parte, in questo modo + viene analizzata la conformità alle norme, l'assenza di difetti e la presenza di proprietà positive. +
+ Viene applicata ad ogni prodotto di processo tramite metodi di lettura (desk check) per i prodotti semplici, tramite + le tecniche inspection e walkthrough, o tramite metodi formali basati sulla prova assistita di qualità la cui + controparte dinamica sarebbe troppo onerosa da dimostrare. -
-
-L'analisi dinamica viene effettuata tramite test su delle esecuzioni del programma e serve a supporto sia della verifica che della validazione. -I test vanno definiti in modo da garantirne la ripetibilità, specificando dunque l'ambiente, le specifiche di input e comportamenti attesi e le procedure da eseguire. -
-I test da definire sono quelli di unità, -di integrazione, di sistema, di regressione e di collaudo. -I momenti e l'ordine in cui essi vengono specificati e implementati dipendono dal modello a V.

+
+
+ L'analisi dinamica viene effettuata tramite test su delle esecuzioni del programma e serve a supporto sia della + verifica che della validazione. + I test vanno definiti in modo da garantirne la ripetibilità, specificando dunque l'ambiente, le specifiche di input + e comportamenti attesi e le procedure da eseguire. +
+ I test da definire sono quelli di unità, di integrazione, di sistema, di regressione e di + collaudo. I momenti e l'ordine in cui essi vengono specificati e implementati dipendono dal modello a V. +

Quality assurance

-È un'attività che raccoglie tempestivamente evidenza oggettiva e di qualità, al fine di controllo interno e accertamento esterno al fronte di metriche e obiettivi definiti. -
-La quality assurance si basa sull'ISO/IEC 9126 per le sue sei caratteristiche interne e esterne, mentre la qualità in uso viene lasciata ad una valutazione a posteriori. + È un'attività che raccoglie tempestivamente evidenza oggettiva e di qualità, al fine di + controllo interno e accertamento esterno al fronte di metriche e obiettivi definiti. +
+ La quality assurance si basa sull'ISO/IEC 9126 per le sue sei caratteristiche interne e esterne, mentre la qualità + in uso viene lasciata ad una valutazione a posteriori.

Funzionalità

-Viene perseguita tramite liste di controllo rispetto ai requisiti e deve controllare che il prodotto ne soddisfi le necessità individuate in modo strettamente sufficiente. -Essa controlla anche l'adesione del prodotto alle norme e alle prescrizioni, è una valutazione empirica di accuratezza e viene dimostrata tramite prove precedute da un'attività preliminare di analisi statica. + Viene perseguita tramite liste di controllo rispetto ai requisiti e deve controllare che il prodotto ne soddisfi le + necessità individuate in modo strettamente sufficiente. + Essa controlla anche l'adesione del prodotto alle norme e alle prescrizioni, è una valutazione empirica di + accuratezza e viene dimostrata tramite prove precedute da un'attività preliminare di analisi statica.

Affidabilità

-Viene perseguita tramite liste di controllo rispetto ai requisiti relativi alla robustezza e alla capacità di ripristino e recupero da errori. -Essa controlla anche l'adesione del prodotto alle norme e alle prescrizioni, è una valutazione empirica di accuratezza e viene dimostrata tramite prove precedute da un'attività preliminare di analisi statica. + Viene perseguita tramite liste di controllo rispetto ai requisiti relativi alla robustezza e alla capacità di + ripristino e recupero da errori. + Essa controlla anche l'adesione del prodotto alle norme e alle prescrizioni, è una valutazione empirica di + accuratezza e viene dimostrata tramite prove precedute da un'attività preliminare di analisi statica.

Usabilità

-Viene perseguita tramite liste di controllo rispetto ai manuali d'uso valutando la comprensibilità, l'apprendibilità e l'adesione alle norme e alle prescrizioni. -Nell'usabilità l'analisi statica è complementare a delle prove imprescindibili; può essere valutata tramite questionari sottomessi agli utenti riguardo a facilità e piacevolezza d'uso. + Viene perseguita tramite liste di controllo rispetto ai manuali d'uso valutando la comprensibilità, l'apprendibilità + e l'adesione alle norme e alle prescrizioni. + Nell'usabilità l'analisi statica è complementare a delle prove imprescindibili; può essere valutata tramite + questionari sottomessi agli utenti riguardo a facilità e piacevolezza d'uso.

Efficienza

-Viene perseguita tramite liste di controllo rispetto alle norme di codifica relative all'efficienza in termini di tempo e spazio richiesti dal prodotto. -Tramite analisi statica si possono valutare i margini di miglioramento prestazionale possibili, mentre tramite prove si riesce a dimostrare l'efficienza provata del prodotto che serve a fornire confidenza. + Viene perseguita tramite liste di controllo rispetto alle norme di codifica relative all'efficienza + in termini di tempo e spazio richiesti dal prodotto. + Tramite analisi statica si possono valutare i margini di miglioramento prestazionale possibili, mentre tramite prove + si riesce a dimostrare l'efficienza provata del prodotto che serve a fornire confidenza.

-

Manutenibilità +

Manutenibilità

-Viene perseguita tramite liste di controllo rispetto -a specifiche norme di codifica per analizzabilità e modificabilità e rispetto a delle prove che ne accertino ripetibilità e verificabilità. -Vengono eseguite delle prove di stabilità, ma lo strumento ideale per accertarsi di questa qualità è l'analisi statica. + Viene perseguita tramite liste di controllo rispetto a specifiche norme di codifica per analizzabilità e + modificabilità e rispetto a delle prove che ne accertino ripetibilità e verificabilità. + Vengono eseguite delle prove di stabilità, ma lo strumento ideale per accertarsi di questa qualità è l'analisi + statica.

Portabilità

-Viene perseguita tramite liste di controllo rispetto -a specifiche norme di codifica riguardanti l'adattabilità. -Lo strumento ideale è l'analisi statica ma a complemento vengono effettuate prove riguardanti facilità di installazione e di sostituzione e la compatibilità tra più ambienti. + Viene perseguita tramite liste di controllo rispetto a specifiche norme di codifica riguardanti l'adattabilità. + Lo strumento ideale è l'analisi statica ma a complemento vengono effettuate prove riguardanti facilità di + installazione e di sostituzione e la compatibilità tra più ambienti.

- + diff --git a/src/cMetriche.html b/src/cMetriche.html index 5cae556..193feaa 100644 --- a/src/cMetriche.html +++ b/src/cMetriche.html @@ -1,135 +1,180 @@

Metodi e obiettivi di quantificazione

Definizione

-In un progetto c'è l'esigenza di effettuare delle misure al fine di avere dati affidabili su cui creare dei modelli di miglioramento tramite risultati oggettivi che implicano che la misura deve essere ripetibile, confrontabile e possedere una certa confidenza entro limiti di approssimazione. -
-In particolare una misura è il risultato di una misurazione che è il processo che assegna numeri o simboli ad attributi di entità del mondo reale per descriverli tramite regole definite. -
-L'insieme di regole che fissa le entità da misurare, gli attributi rilevanti, l’unità -di misura, la procedura per assegnare e interpretare i valori si chiama metrica. -Viene definita da IEEE come: + In un progetto c'è l'esigenza di effettuare delle misure al fine di avere dati affidabili su cui creare dei modelli + di miglioramento tramite risultati oggettivi che implicano che la misura deve essere ripetibile, confrontabile + e possedere una certa confidenza entro limiti di approssimazione. +
+ In particolare una misura è il risultato di una misurazione che è il processo che assegna numeri o simboli ad + attributi di entità del mondo reale per descriverli tramite regole definite. +
+ L'insieme di regole che fissa le entità da misurare, gli attributi rilevanti, l’unità di misura, la + procedura per assegnare e interpretare i valori si chiama metrica. + Viene definita da IEEE come:

-La misura quantitativa del grado di possesso di uno specifico -attributo da parte di un sistema, componente, processo -
Glossario IEEE
+ La misura quantitativa del grado di possesso di uno specifico attributo da parte di un sistema, componente, processo +
Glossario IEEE

- -Le metriche identificano degli attributi, interni o esterni, misurabili -determinando indicatori per le caratteristiche non misurabili. -Gli attributi interni sono legati a misurazioni rispetto alle entità(codice sorgente), mentre quelli esterni sono relativi all'ambiente(qualità esterna, di prodotto). -
-Le metriche si configurano dunque come strumenti di valutazione per valutare la qualità di processi e prodotti, effettuare stime, preventivi e consuntivi sui progetti e per capire il consumo di risorse. - -
- -Valori negativi riscontrati nelle metriche non devono portare ad azioni correttive impulsive ma è bene ricordare che ogni correzione deve essere analizzata per massimizzare il rapporto tra benefici e costi tramite gestione dei cambiamenti. - + Le metriche identificano degli attributi, interni o esterni, misurabili determinando indicatori per le + caratteristiche non misurabili. + Gli attributi interni sono legati a misurazioni rispetto alle entità(codice sorgente), mentre quelli esterni sono + relativi all'ambiente(qualità esterna, di prodotto). +
+ Le metriche si configurano dunque come strumenti di valutazione per valutare la qualità di processi e prodotti, + effettuare stime, preventivi e consuntivi sui progetti e per capire il consumo di risorse. + +
+ + Valori negativi riscontrati nelle metriche non devono portare ad azioni correttive impulsive ma è bene ricordare + che ogni correzione deve essere analizzata per massimizzare il rapporto tra benefici e costi tramite gestione dei cambiamenti. +

Obiettivi

-If you cannot measure it, you cannot improve it -
Lord William Thomson Kelvin (1824-1907)
+ If you cannot measure it, you cannot improve it +
Lord William Thomson Kelvin (1824-1907)

-Una metrica ha l'obiettivo far emergere tendenze e attuare azioni migliorative, questo ha senso solo se ciò viene colto tempestivamente, o meglio, in modo proattivo. -
-Il processo di misurazione deve essere disciplinato secondo delle strategie e a supporto di ciò è definito lo standard -ISO/IEC 15939 che fornisce un modello delle misurazioni da produrre e delle relazioni tra esse, descrivendone il processo di misurazione. -Questo standard afferma che i bisogni informativi sono basati su obiettivi, vincoli, rischi e problemi che hanno origine dai processi tecnici e di gestione. + Una metrica ha l'obiettivo far emergere tendenze e attuare azioni migliorative, questo ha senso solo se ciò viene + colto tempestivamente, o meglio, in modo proattivo. +
+ Il processo di misurazione deve essere disciplinato secondo delle strategie e a supporto di ciò è definito lo + standard + ISO/IEC 15939 che fornisce un modello delle misurazioni da produrre e delle relazioni tra esse, descrivendone il + processo di misurazione. + Questo standard afferma che i bisogni informativi sono basati su obiettivi, vincoli, rischi e problemi che hanno + origine dai processi tecnici e di gestione.


-Il modello fornito dallo standard può essere ad esempio istanziato con CMMI determinando la divisione dei bisogni in varie aree: + Il modello fornito dallo standard può essere ad esempio istanziato con CMMI determinando la divisione dei bisogni in + varie aree:

    -
  • gestione dei requisiti;
    • +
  • gestione dei requisiti;
    • + +
  • progettazione e implementazione;
    • -
  • progettazione e implementazione;
    • +
  • verifica e validazione;
    • -
  • verifica e validazione; -
    • +
  • quality assurance;
    • -
  • quality assurance;
    • +
  • gestione della configurazione;
    • -
  • gestione della configurazione; -
    • +
  • gestione di progetto;
    • -
  • gestione di progetto; -
    • +
  • analisi dei rischi e analisi delle decisioni;
    • -
  • analisi dei rischi e analisi delle decisioni;
    • -
  • allenamento.
    • +
  • allenamento.

-In alternativa alle tipologie tecniche di metriche si possono definire delle metriche funzionali, secondo ISO/IEC 14143 che hanno lo scopo di valutare oggettivamente le funzionalità del software, utili come vista esterna per stimare il prezzo di vendita. + In alternativa alle tipologie tecniche di metriche si possono definire delle metriche funzionali, secondo ISO/IEC + 14143 che hanno lo scopo di valutare oggettivamente le funzionalità del software, utili come vista esterna per + stimare il prezzo di vendita.

Le nostre metriche

-

Le seguenti categorie di metriche non hanno origine formale. -Sono state inserite le metriche che abbiamo usato durante lo svolgimento del progetto didattico o che riteniamo di particolare interesse. -
-(Davvero? Mah) +

+ Le seguenti categorie di metriche non hanno origine formale. + Sono state inserite le metriche che abbiamo usato durante lo svolgimento del progetto didattico o che riteniamo di + particolare interesse. +
+ (Davvero? Mah)

Metriche per l'analisi

-Sono metriche utili ad assicurarsi che l'analisi dei requisiti svolta sia consistente nel tempo. -Un esempio di tale metrica può essere il Requirement stability index(RSI) che misura la variazione dei requisiti nel tempo. + Sono metriche utili ad assicurarsi che l'analisi dei requisiti svolta sia consistente nel tempo. + Un esempio di tale metrica può essere il Requirement stability index(RSI) che misura la variazione dei + requisiti nel tempo.

Metriche progettuali(architetturali)

-Sono metriche utili per assicurare una buona architettura software, che rispetti le qualità desiderabili come basso accoppiamento, riusabilità e manutenibilità. -
-Esempi di tale metriche sono: + Sono metriche utili per assicurare una buona architettura software, che rispetti le qualità desiderabili come basso + accoppiamento, riusabilità e manutenibilità. +
+ Esempi di tale metriche sono:

    -
  • Instability: è data da un rapporto tra accoppiamento efferente(fan-out) e accoppiamento afferente(fan-in), tale metrica indica la possibilità di effettuare modifiche ad una componente del package senza influenzarne altri;
    • -
  • Grado di coesione: è quanto sono coese le funzionalità all'interno di una classe o di un modulo, un grado alto di coesione spesso deriva da una componente con fan-in elevato;
    • -
  • Grado di accoppiamento: è quanto un modulo è dipendente da altre componenti del sistema, un grado alto di accoppiamento è sintomo di fan-out elevato.
    • +
  • Instability: è data da un rapporto tra accoppiamento efferente(fan-out) e accoppiamento + afferente(fan-in), tale metrica indica la possibilità di effettuare modifiche ad una componente del package + senza influenzarne altri; +
    • +
  • Grado di coesione: è quanto sono coese le funzionalità all'interno di una classe + o di un modulo, un grado alto di coesione spesso deriva da una componente con fan-in elevato; +
    • +
  • Grado di accoppiamento: è quanto un modulo è dipendente da altre componenti del sistema, un grado alto di + accoppiamento è sintomo di fan-out elevato. +

Metriche software

-Sono metriche per misurare le qualità interne del codice sorgente, sia per quanto riguarda le dimensioni sia per quanto riguarda la complessità. + Sono metriche per misurare le qualità interne del codice sorgente, sia per quanto riguarda le dimensioni sia per + quanto riguarda la complessità.

    -
  • SLOC: è il numero di linee di codice sorgente e serve per misurare la dimensione del prodotto software;
    • -
  • Average Cyclomatic Complexity -: analizza i possibili cammini indipendenti all'interno di un singolo sottoprogramma fornendo un valore che va confrontato a soglie prefissate. Il suo valore corrisponde al numero di casi di test necessari, in media, per verificare ogni possibile esito dei rami decisionali misurando la complessità del flusso di controllo.
    • -
  • Weighted Method -Complexity: misura la somma pesata dei metodi di una classe, dove -il peso di un metodo è dato dalla sua complessità ciclomatica, tale metrica se si attesta su valori bassi garantisce -una buona riusabilità dei metodi; -
    • -
  • Nested Block Depth -: misura il massimo numero di livelli di annidamento -delle strutture di controllo nei metodi;
    • -
  • Copertura -del codice: misura la percentuale di codice coperto da test secondo uno degli approcci descritti nell'analisi dinamica.
    • +
  • + SLOC: è il numero di linee di codice sorgente e serve per misurare la dimensione del prodotto software; +
    • +
  • + Average Cyclomatic Complexity: analizza i possibili cammini indipendenti all'interno di un singolo + sottoprogramma fornendo un valore che va confrontato a soglie prefissate. Il suo valore corrisponde al numero di + casi di test necessari, in media, per verificare ogni possibile esito dei rami decisionali misurando la + complessità del flusso di controllo. +
    • +
  • + Weighted Method Complexity: misura la somma pesata dei metodi di una classe, dove il peso di un metodo è + dato dalla sua complessità ciclomatica, tale metrica se si attesta su valori bassi garantisce una buona + riusabilità dei metodi; +
    • +
  • + Nested Block Depth: misura il massimo numero di livelli di annidamento + delle strutture di controllo nei metodi; +
    • +
  • + Copertura del codice: misura la percentuale di codice coperto da test secondo uno degli approcci + descritti nell'analisi dinamica. +

Metriche per la gestione di progetto

-Sono metriche per misurare la gestione di risorse legate al progetto. + Sono metriche per misurare la gestione di risorse legate al progetto.

    -
  • Budget variance: misura la differenza tra i costi preventivati e quelli fin'ora sostenuti;
    • -
  • Schedule variace: misura la differenza tra il tempo attualmente speso rispetto a quello preventivato;
    • -
  • Lead time: misura il tempo di calendario che intercorre tra l'ordine di un ticket e la sua consegna.
    • +
  • Budget variance: misura la differenza tra i costi preventivati e quelli fin'ora sostenuti;
    • +
  • + Schedule variance: misura la differenza tra il tempo attualmente speso rispetto a quello preventivato; +
    • +
  • Lead time: misura il tempo di calendario che intercorre tra l'ordine di un ticket e la sua consegna.
diff --git a/src/cProcessiSW.html b/src/cProcessiSW.html index 9f41c1f..6107d46 100644 --- a/src/cProcessiSW.html +++ b/src/cProcessiSW.html @@ -1,173 +1,214 @@ -

Processi Software

+

Processi Software

+ +

+ Il concetto di processo è definito cosi: +

-

- Il concetto di processo è definito cosi: -

-
-Un processo è un insieme di attività correlate e coese che trasformano ingressi in uscite secondo regole fissate, consumando risorse nel farlo -
glossario ISO 9000
+ Un processo è un insieme di attività correlate e coese che + trasformano ingressi in uscite secondo regole fissate, consumando risorse nel farlo +
glossario ISO 9000
-

- Le attività si compongono di compiti i quali verranno svolti con alcune tecniche applicate agli strumenti a disposizione, dove per strumenti si intende l'insieme - dei concetti e dei metodi supportati da tecnologie che quindi impongono vincoli nello svolgimento dei compiti. - - Essendo un processo un aggregato di attività coese (ben definite e relazionate), anche esso deve essere reso disciplinato e sistematico al fine di garantirne la qualità. - Per fare ciò esistono attività atte al controllo di processo; a tal proposito tutti i processi devono essere misurati nelle - attività che li caratterizzano, preferibilmente con misurazioni automatizzate. - I processi tra loro vanno relazionati in modo chiaro e distinto, perseguendo la modularità. -

- -

- Al fine di ricercare la qualità del prodotto, l'ingegneria del software mette a disposizione degli standard di processo condivisi tra le aziende di stesso dominio applicativo. - - Partendo da questi standard le aziende specializzano i processi in processi definiti, adattandoli alle specifiche esigenze aziendali, - tali processi sono chiari, stabili e indipendenti dal modello del ciclo di vita adottato, dalle tecnologie usate, dal dominio applicativo e dalla documentazione richiesta. -
- Per ogni progetto vengono istanziati dall'azienda i processi di progetto, che utilizzano le risorse aziendali per raggiungere gli - obiettivi del progetto, definendo dunque una pianificazione dettagliata e adottando chiare scelte di specializzazione riguardo allo scenario di applicazione, - alla definizione di attività e compiti aggiuntivi o specifici e all'organizzazione delle relazioni tra i processi specializzati. -
I fattori secondo i quali si specializza un processo sono: -

-
    -
  • dimensioni del progetto
    • -
  • complessità del progetto -
    • -
  • rischi identificati dal dominio applicativo e dalle tecnologie in uso, la competenza e l'esperienza delle risorse umane e i fattori - dipendenti dal contratto in essere
    • - -
- -

-
La scelta del set di processi da istanziare in un progetto e la loro applicazione e evoluzione spetta all'amministratore di progetto. - -

- -

ISO/IEC 12207

-

- Lo standard ISO/IEC 12207 è il più noto standard di processo per l'ingegneria del software, fornisce una suddivisione dei processi ad alto livello: -i processi primari, i processi di supporto e processi organizzativi. -
- -Fornisce inoltre per ogni processo una descrizione delle attività e dei compiti che lo compongono, fornendo un modello da specializzare ma con specifiche -responsabilità sui processi di cui identifica i prodotti attesi. -

- -

Processi primari

-

- Sono i processi che governano le attività di particolare rilevanza sull'avanzamento del progetto. - Un progetto è ancora attivo se almeno uno di questi processi non è terminato: -

-
    -
  • acquisizione: gestione dei propri sottofornitori; -
    • - -
  • fornitura: gestione del rapporto con il cliente, tra esse figura l'attività di stima della consegna; -
    • +

    + Le attività si compongono di compiti i quali verranno svolti con alcune tecniche applicate agli strumenti a + disposizione, dove per strumenti si intende l'insieme dei concetti e dei metodi supportati da tecnologie che quindi + impongono vincoli nello svolgimento dei compiti. + + Essendo un processo un aggregato di attività coese (ben definite e relazionate), anche esso deve essere reso + disciplinato e sistematico al fine di garantirne la qualità. + Per fare ciò esistono attività atte al controllo di processo; a tal proposito tutti i processi devono essere + misurati nelle attività che li caratterizzano, preferibilmente con misurazioni automatizzate. + I processi tra loro vanno relazionati in modo chiaro e distinto, perseguendo la modularità. +

    + +

    + Al fine di ricercare la qualità del prodotto, l'ingegneria del software mette a disposizione degli standard di + processo condivisi tra le aziende di stesso dominio applicativo. + + Partendo da questi standard le aziende specializzano i processi in processi definiti, adattandoli alle + specifiche esigenze aziendali, tali processi sono chiari, stabili e indipendenti dal modello del ciclo di vita + adottato, dalle tecnologie usate, dal dominio applicativo e dalla documentazione richiesta. +
    + Per ogni progetto vengono istanziati dall'azienda i processi di progetto, che utilizzano le risorse aziendali + per raggiungere gli obiettivi del progetto, definendo dunque una pianificazione dettagliata e adottando chiare + scelte di specializzazione riguardo allo scenario di applicazione, alla definizione di attività e compiti aggiuntivi + o specifici e all'organizzazione delle relazioni tra i processi specializzati. +
    I fattori secondo i quali si specializza un processo sono: +

    +
      +
    • dimensioni del progetto
      • +
    • complessità del progetto
      • +
    • + rischi identificati dal dominio applicativo e dalle tecnologie in uso, la competenza e l'esperienza delle + risorse umane e i fattori + dipendenti dal contratto in essere +
      • -
    • sviluppo: è l'insieme maggiore di attività, non si limita all'implementazione dell'architettura definita ma anche all'analisi, alla progettazione e al testing; -
      • - -
    • gestione operativa: installazione e erogazione dei prodotti e/o - servizi; -
      • +
    -
  • manutenzione: correzione, adattamento e evoluzione del prodotto. -
    • +

    +
    La scelta del set di processi da istanziare in un progetto e la loro applicazione e evoluzione spetta + all'amministratore di progetto. + +

    + +

    ISO/IEC 12207

    +

    + Lo standard ISO/IEC 12207 è il più noto standard di processo per l'ingegneria del software, fornisce una + suddivisione dei processi ad alto livello: + i processi primari, i processi di supporto e processi organizzativi. +
    + + Fornisce inoltre per ogni processo una descrizione delle attività e dei compiti che lo compongono, fornendo un + modello da specializzare ma con specifiche responsabilità sui processi di cui identifica i prodotti attesi. +

    + +

    Processi primari

    +

    + Sono i processi che governano le attività di particolare rilevanza sull'avanzamento del progetto. + Un progetto è ancora attivo se almeno uno di questi processi non è terminato: +

    +
      +
    • + acquisizione: gestione dei propri sottofornitori; +
      • + +
    • + fornitura: gestione del rapporto con il cliente, tra esse figura l'attività di stima della consegna; +
      • + +
    • + sviluppo: è l'insieme maggiore di attività, non si limita all'implementazione dell'architettura definita + ma anche all'analisi, alla progettazione e al testing; +
      • + +
    • + gestione operativa: installazione e erogazione dei prodotti e/o servizi; +
      • + +
    • + manutenzione: correzione, adattamento e evoluzione del prodotto. +
    -
    -

    Processi di supporto

    -

    - Sono i processi che vengono impiegati ed eseguiti da altri processi all'occorrenza e forniscono supporto a chi li esegue, contribuendo quindi al successo e alla qualità del prodotto software. - Si dividono in: -

    -
      -
    • documentazione; -
      • +
      +

      Processi di supporto

      +

      + Sono i processi che vengono impiegati ed eseguiti da altri processi all'occorrenza e forniscono supporto a chi li + esegue, contribuendo quindi al successo e alla qualità del prodotto software. + Si dividono in: +

      +
        +
      • documentazione; +
        • -
      • gestione delle versioni e della configurazione; -
        • +
      • gestione delle versioni e della configurazione; +
        • -
      • accertamento della qualità;
        • +
      • accertamento della qualità;
        • -
      • qualifica: verifica e validazione; -
        • +
      • qualifica: verifica e validazione; +
        • -
      • revisioni congiunte con il cliente: audit(RR e RA, qualificanti); -
        • +
      • revisioni congiunte con il cliente: audit (RR e RA, qualificanti); +
        • -
      • verifiche ispettive interne: joint review(RP e RQ); -
        • +
      • verifiche ispettive interne: joint review (RP e RQ); +
        • -
      • risoluzione dei problemi. -
        • +
      • risoluzione dei problemi. +

      -

      Processi organizzativi

      - -

      - Sono i processi impiegati dall'azienda per garantire e gestire il lavoro collaborativo. - Si dividono in: -

      - -
        -
      • gestione dei processi; -
        • - -
      • gestione delle infrastrutture; -
        • -
      • miglioramento del processo: miglioramento (idealmente continuo) basato sull'esperienza attuale, atto a migliorarne una futura; -
        • -
      • formazione del personale: possibilmente non retrospettiva; -
        • +

        Processi organizzativi

        + +

        + Sono i processi impiegati dall'azienda per garantire e gestire il lavoro collaborativo. + Si dividono in: +

        + +
          +
        • + gestione dei processi; +
          • + +
        • + gestione delle infrastrutture; +
          • +
        • + miglioramento del processo: miglioramento (idealmente continuo) basato sull'esperienza attuale, atto a + migliorarne una futura; +
          • +
        • + formazione del personale: possibilmente non retrospettiva; +
        -

        Ciclo di Deming - PDCA

        -

        - Al fine di garantire la qualità del processo (necessaria per la qualità di prodotto) è necessaria un'organizzazione dei processi che porti al miglioramento continuo. - Ciò è attuabile tramite il PDCA che è un metodo iterativo suddiviso in 4 fasi. -
        - Fissa degli obiettivi di miglioramento assicurando il non decremento della qualità ad ogni iterazione e viene applicato analizzando le attività di processo ripetibili e misurabili. - I miglioramenti si riflettono sull' -efficacia - e sull' - efficienza - del processo. - Le quattro fasi sono: -

        -
          -
        • Plan: definizione degli obiettivi di miglioramento e delle relative strategie da adottare - per raggiungerli, se possibile inizialmente su scala ridotta per poterne valutare gli effetti; -
          • -
        • Do: attuazione di quanto pianificato al punto precedente, con raccolta di dati significativi da poter analizzare nelle fasi successive; - -
          • -
        • Check: verifica dell’esito del processo in seguito all’attuazione delle strategie di miglioramento, con studio dei risultati raccolti durante il Do e confronto di questi ultimi con i risultati attesi nel Plan per stimare l’impatto del miglioramento apportato; - -
          • -
        • Act: attuazione delle strategie che hanno portato miglioramenti, eventualmente - estendendole anche all’infuori dei singoli processi per cui erano state pianificate inizialmente. - Nel caso di differenze significative tra i risultati previsti e quelli effettivi possono essere richieste delle azioni correttive a seguito di un’analisi delle cause. - Nel caso di miglioramenti rispetto agli standard precedenti, il nuovo standard prende il loro posto, diventando la nuova - baseline. -
          • +

          Ciclo di Deming - PDCA

          +

          + Al fine di garantire la qualità del processo (necessaria per la qualità di prodotto) è necessaria un'organizzazione + dei processi che porti al miglioramento continuo. + Ciò è attuabile tramite il PDCA che è un metodo iterativo suddiviso in 4 fasi. +
          + Fissa degli obiettivi di miglioramento assicurando il non decremento della qualità ad ogni iterazione e viene + applicato analizzando le attività di processo ripetibili e misurabili. + I miglioramenti si riflettono sull' + efficacia + e sull' efficienza del processo. + Le quattro fasi sono: +

          +
            +
          • + Plan: definizione degli obiettivi di miglioramento e delle relative strategie da adottare + per raggiungerli, se possibile inizialmente su scala ridotta per poterne valutare gli effetti; +
            • +
          • + Do: attuazione di quanto pianificato al punto precedente, con raccolta di dati significativi da poter + analizzare nelle fasi successive; +
            • +
          • + Check: verifica dell’esito del processo in seguito all’attuazione delle strategie di miglioramento, con + studio dei risultati raccolti durante il Do e confronto di questi ultimi con i risultati attesi nel Plan per + stimare l’impatto del miglioramento apportato; +
            • +
          • + Act: attuazione delle strategie che hanno portato miglioramenti, eventualmente estendendole anche + all’infuori dei singoli processi per cui erano state pianificate inizialmente. + Nel caso di differenze significative tra i risultati previsti e quelli effettivi possono essere richieste delle + azioni correttive a seguito di un’analisi delle cause. + Nel caso di miglioramenti rispetto agli standard precedenti, il nuovo standard prende il loro posto, diventando + la nuova baseline. +
          -

          Ciclo di vita software

          -

          - La scelta del modello di ciclo di vita del software è strettamente legata alla natura, alla funzione e all'ordine dei processi di revisione previsti per verificare lo stato di avanzamento. -
          Il ciclo di vita scelto dipende da molti fattori ma influenza profondamente la specializzazione dei processi di progetto. -

          - +

          Ciclo di vita software

          +

          + La scelta del modello di ciclo di vita del software è strettamente legata alla natura, alla funzione e all'ordine + dei processi di revisione previsti per verificare lo stato di avanzamento.
          + Il ciclo di vita scelto dipende da molti fattori ma influenza profondamente la specializzazione dei processi di + progetto. +

          + - + diff --git a/src/cProgSoftware.html b/src/cProgSoftware.html index 0985f87..cd63222 100644 --- a/src/cProgSoftware.html +++ b/src/cProgSoftware.html @@ -1,188 +1,236 @@

          Progettazione Software

          Definizione

          -Una volta individuato in modo chiaro il problema tramite l'ingegneria dei requisiti(approccio analitico), -il compito di trovare la soluzione per risolvere il problema nel modo più corretto è compito della progettazione software(approccio sintetico). -
          -La progettazione ricerca una soluzione soddisfacente per tutti gli stakeholder, -andando a produrre l'architettura e i suoi modelli - logici senza l'ausilio del codice. -La progettazione ha dunque il compito di assicurare il soddisfacimento delle caratteristiche individuate per il prodotto durante -l'analisi. -
          -
          -L'obiettivo di una buona progettazione software è il soddisfacimento dei requisiti -con un sistema di qualità, ottenibile tramite la definizione di una buona architettura logica del prodotto -che presenti componenti dalle specifiche chiare e coese, che sia realizzabile con risorse e costi fissati e che abbia -una struttura che faciliti cambiamenti futuri(manutenibile). -
          -Per dominare la complessità del sistema conviene scomporlo in componenti via via meno complessi, fermando la decomposizione una volta -arrivati a componenti che abbiano complessità trattabile da un singolo individuo. -
          -
          -Importante è saper riconoscere quando terminare tale scomposizione per non occorrere in orchestrazioni tra componenti -troppo complesse e che farebbero annullare i benefici di tale scomposizione. + Una volta individuato in modo chiaro il problema tramite l'ingegneria dei requisiti (approccio analitico), + il compito di trovare la soluzione per risolvere il problema nel modo più corretto è compito della progettazione + software (approccio sintetico). +
          + La progettazione ricerca una soluzione soddisfacente per tutti gli stakeholder, + andando a produrre l'architettura e i suoi modelli logici senza l'ausilio del codice. + La progettazione ha dunque il compito di assicurare il soddisfacimento delle caratteristiche individuate per il + prodotto durante l'analisi. +
          +
          + L'obiettivo di una buona progettazione software è il soddisfacimento dei requisiti con un sistema di qualità, + ottenibile tramite la definizione di una buona architettura logica del prodotto che presenti componenti dalle + specifiche chiare e coese, che sia realizzabile con risorse e costi fissati e che abbia una struttura che faciliti + cambiamenti futuri (manutenibile). +
          + Per dominare la complessità del sistema conviene scomporlo in componenti via via meno complessi, fermando la + decomposizione una volta arrivati a componenti che abbiano complessità trattabile da un singolo individuo. +
          +
          + Importante è saper riconoscere quando terminare tale scomposizione per non occorrere in orchestrazioni tra + componenti troppo complesse e che farebbero annullare i benefici di tale scomposizione.

          -L'architettura software è l’organizzazione di base di un sistema, espressa dai suoi -componenti, dalle relazioni tra di loro e con l’ambiente, e i principi -che ne guidano il progetto e l’evoluzione -
          ISO/IEC/IEEE 42010:2011, Systems -and software engineering — Architecture description
          + L'architettura software è l’organizzazione di base di un sistema, espressa dai suoi componenti, dalle relazioni tra + di loro e con l’ambiente, e i principi che ne guidano il progetto e l’evoluzione +
          ISO/IEC/IEEE 42010:2011, Systems + and software engineering — Architecture description +

          -Tipicamente l'architettura di un software è un sistema -formato da componenti, che raggruppano delle unità che a loro volta raggruppano -moduli(carico di lavoro da assegnare ad un singolo). -
          -Acronimo di tale suddivisione è SCUM. -
          -Per perseguire coerenza e consistenza nell'architettura è consigliato l'uso di -stili architetturali, -che forniscono una soluzione progettuale di alto livello, specificando poi la progettazione di dettaglio mediante l'uso di design pattern appropriati. -
          -La progettazione di dettaglio si occupa di assegnare le unità a componenti per organizzare il lavoro di programmazione, -producendo della documentazione che possa disciplinare -la programmazione, tracciando i requisiti alle unità -e definendo le configurazioni ammissibili del sistema. -Inoltre vengono definiti gli strumenti per eseguire le prove di unità. + Tipicamente l'architettura di un software è un sistemaformato da componenti, che raggruppano delle + unità + che a loro volta raggruppano moduli(carico di lavoro da assegnare ad un singolo). +
          + Acronimo di tale suddivisione è SCUM. +
          + Per perseguire coerenza e consistenza nell'architettura è consigliato l'uso di + stili architetturali, che forniscono una + soluzione progettuale di alto livello, specificando poi la progettazione di dettaglio mediante l'uso di design + pattern appropriati. +
          + La progettazione di dettaglio si occupa di assegnare le unità a componenti per organizzare il lavoro di + programmazione, producendo della documentazione che possa disciplinare la programmazione, tracciando i requisiti + alle unità e definendo le configurazioni ammissibili del sistema. + Inoltre vengono definiti gli strumenti per eseguire le prove di unità.

          SEMAT

          -SEMAT prevede quattro stati di progresso con cui poter valutare il grado con cui l'architettura è definita e implementata. -
          -Inizialmente il progresso viene catalogato come architecture selected, -dove avviene la selezione delle tecnologie necessarie e delle decisioni architetturali in base ad esse. -
          -Una volta dimostrata agli stakeholders la bontà delle scelte architetturali e decise le principali interfacce e configurazioni di sistema l'architettura si attesta -a demonstrable. -In seguito alla sviluppo dell'architettura scelta, quando il sistema può essere utilizzato dagli utenti e presenta le funzionalità e le prestazioni richieste, -con una quantità di difetti residui accettabile si raggiunge lo stato di usable. -
          -Infine al termine della stesura della documentazione e con l'accettazione degli stakeholders del prodotto si raggiunge lo stato -ready. - + SEMAT prevede quattro stati di progresso con cui poter valutare il grado con cui l'architettura è definita e + implementata. +
          + Inizialmente il progresso viene catalogato come architecture selected, dove avviene la selezione delle + tecnologie necessarie e delle decisioni architetturali in base ad esse. +
          + Una volta dimostrata agli stakeholders la bontà delle scelte architetturali e decise le principali interfacce e + configurazioni di sistema l'architettura si attesta a demonstrable. + In seguito alla sviluppo dell'architettura scelta, quando il sistema può essere utilizzato dagli utenti e presenta + le funzionalità e le prestazioni richieste, con una quantità di difetti residui accettabile si raggiunge lo stato di + usable. +
          + Infine al termine della stesura della documentazione e con l'accettazione degli stakeholders del prodotto si + raggiunge lo statoready.

          - -

          Qualità di architettura

          -Le qualità che generalmente dovrebbe avere una buona architettura dovrebbero essere misurabili, in modo da poter evidenziare cambiamenti -nel tempo tramite misurazioni, esse sono: + Le qualità che generalmente dovrebbe avere una buona architettura dovrebbero essere misurabili, in modo da poter + evidenziare cambiamenti nel tempo tramite misurazioni, esse sono:

            -
          • Sufficienza: cioè un sufficiente grado di soddisfacimento dei requisiti;
            • -
          • Comprensibilità: dovrebbe essere compresa dagli stakeholders;
            • - - -
          • Modularità: buona scomposizione in componenti, parti chiare e distinte tra loro e con compiti non sovrapposti;
            • - -
          • Robustezza: gestione di diverse classi di input(anche non previste);
            • - -
          • Flessibilità: che permetta facile manutenzione sia adattativa che evolutiva;
            • - -
          • Riusabilità: sia pensata anche per il riuso e con il riuso di componenti;
            • - -
          • Efficienza;
            • - -
          • Affidabilità: è altamente probabile che svolga bene il suo compito;
            • - -
          • Disponibilità: la manutenzione che blocca l'intero sistema dovrebbe essere breve o nulla, la manutenzione di una parte di sistema non deve bloccarlo interamente;
            • - -
          • Sicurezza rispetto ai malfunzionamenti: il sistema dispone di un sufficiente grado di ridondanza;
            • - -
          • Sicurezza rispetto a intrusioni: protezione dei dati del sistema;
            • -
          • Semplicità: caratteristica riferita alla complessità dell'architettura;
            • -
          • Incapsulamento: alcune volte nascondere i dettagli implementativi(black box) può portare a benefici come diminuzione di dipendenze e aumento di riuso, a volte accresce anche la manutenibilità;
            • -
          • Coesione: parti associate concorrono agli stessi obiettivi;
            • - -
          • Basso Accoppiamento: parti distinte dipendono - il meno possibile le une dalle altre.
            • +
          • Sufficienza: cioè un sufficiente grado di soddisfacimento dei requisiti;
            • +
          • Comprensibilità: dovrebbe essere compresa dagli stakeholders;
            • + + +
          • + Modularità: buona scomposizione in componenti, parti chiare e distinte tra loro e con compiti non + sovrapposti; +
            • + +
          • Robustezza: gestione di diverse classi di input(anche non previste);
            • + +
          • Flessibilità: che permetta facile manutenzione sia adattativa che evolutiva;
            • + +
          • + Riusabilità: sia pensata anche per il riuso e con + il riuso di componenti; +
            • + +
          • Efficienza; +
            • + +
          • Affidabilità: è altamente probabile che svolga bene il suo compito;
            • + +
          • + Disponibilità: la manutenzione che blocca l'intero sistema dovrebbe essere breve o nulla, la manutenzione + di una parte di sistema non deve bloccarlo interamente; +
            • + +
          • Sicurezza rispetto ai malfunzionamenti: il sistema dispone di un sufficiente grado di ridondanza;
            • + +
          • Sicurezza rispetto a intrusioni: protezione dei dati del sistema;
            • +
          • Semplicità: caratteristica riferita alla complessità dell'architettura;
            • +
          • + Incapsulamento: alcune volte nascondere i dettagli implementativi(black box) può portare a benefici come + diminuzione di dipendenze e aumento di riuso, a volte accresce anche la manutenibilità; +
            • +
          • + Coesione: parti associate concorrono agli stessi obiettivi; +
            • + +
          • + Basso Accoppiamento: parti distinte + dipendono il meno possibile le une dalle altre. +

          -In particolare l'accoppiamento tra le componenti -va minimizzato, per fare ciò spesso si può far interagire tra loro -le componenti tramite interfacce, evitando cosi di fare assunzioni -dall'esterno sull'interno e evitando di condividere frammenti di stesse risorse. -
          -Il grado di accoppiamento è misurabile: -per ogni componente il numero di archi entranti viene detto fan-in ed è indice -di utilità e va quindi massimizzato, mentre il numero di archi uscenti viene - detto fan-out ed indica dipendenza e va quindi minimizzato. - + In particolare l'accoppiamento tra le componenti va minimizzato, per fare ciò spesso si può far interagire tra loro + le componenti tramite interfacce, evitando cosi di fare assunzioni dall'esterno sull'interno e evitando di + condividere frammenti di stesse risorse. +
          + Il grado di accoppiamento è misurabile: + per ogni componente il numero di archi entranti viene detto fan-in ed è indice di utilità e va quindi + massimizzato, mentre il numero di archi uscenti viene detto fan-out ed indica dipendenza e va quindi + minimizzato.

          -

          -Stili di progettazione architetturale + Stili di progettazione architetturale

          -Nell'approcciarsi alla progettazione architetturale si possono seguire tre diversi stili -di progettazione: -lo stile funzionale(top-down) prevede la decomposizione di problemi -partendo dalle funzionalità di alto livello e scendendo poi nel dettaglio, ogni parte del sistema viene poi rifinita fino ad ottenere -una specifica sufficientemente completa da validare il modello. -
          -Nello stile object-oriented(bottom-up) invece vengono prima individuate -le parti del sistema in dettaglio e poi connesse tra loro in modo -da formare componenti più grandi, fino alla realizzazione dell'intero sistema.
          -Questo approccio -privilegia la codifica e una fase di test precoce, che può iniziare -appena il primo modulo è stato specificato. -
          -Uno dei principali vantaggi dell'uso dell'approccio bottom-up -è la riusabilità. -
          -L'approccio più frequentemente seguito è quello intermedio che prende nome di -meet-in-the-middle che permette maggiore flessibilità. + Nell'approcciarsi alla progettazione architetturale si possono seguire tre diversi stili di progettazione: + lo stile funzionale(top-down) prevede la decomposizione di problemi partendo dalle funzionalità di alto livello e + scendendo poi nel dettaglio, ogni parte del sistema viene poi rifinita fino ad ottenere una specifica + sufficientemente completa da validare il modello. +
          + Nello stile object-oriented(bottom-up) invece vengono prima individuate le parti del sistema in dettaglio e poi + connesse tra loro in modo da formare componenti più grandi, fino alla realizzazione dell'intero sistema.
          + Questo approccio privilegia la codifica e una fase di test + precoce, che può iniziare appena il primo modulo è stato specificato. +
          + Uno dei principali vantaggi dell'uso dell'approccio bottom-up è la riusabilità. +
          + L'approccio più frequentemente seguito è quello intermedio che prende nome dimeet-in-the-middle che permette + maggiore flessibilità.

          Strumenti di supporto

          -Alcune scelte di progettazione vengono influenzate dall'uso di particolari framework, che loro volta possono indurre a introdurre -specifici design pattern. -
          -Un framework è un insieme integrato di componenti software prefabbricate(simili ad una libreria) che forniscono una base facilmente -riusabile per una grande varietà di applicazioni in un dato dominio. -Forniscono un approccio bottom-up perché sono costituiti da codice già fatto, quindi già specificato in dettaglio, ma anche un approccio top-down -poiché a volte impongono stili architetturali. -
          -Un design pattern costituisce una soluzione progettuale di riconosciuta bontà ad un problema ricorrente lasciando comunque un certo grado di libertà -di progettazione. -
          -In particolare per la progettazione del sistema esistono dei pattern architetturali, di cui i più comuni sono: + Alcune scelte di progettazione vengono influenzate dall'uso di particolari framework, che loro volta possono indurre + a introdurre specifici design pattern. +
          + Un framework è un insieme integrato di componenti software prefabbricate(simili ad una libreria) che + forniscono una base facilmente riusabile per una grande varietà di applicazioni in un dato dominio. + Forniscono un approccio bottom-up perché sono costituiti da codice già fatto, quindi già specificato in + dettaglio, ma anche un approccio top-down poiché a volte impongono stili architetturali. +
          + Un design pattern costituisce una soluzione progettuale di riconosciuta bontà ad un problema ricorrente + lasciando comunque un certo grado di libertà di progettazione. +
          + In particolare per la progettazione del sistema esistono dei pattern architetturali, di cui i più comuni sono:

            -
          • A livelli: l'architettura viene suddivisa in più livelli con responsabilità distinte e delle interazioni definite. -Di particolare utilizzo è quella a tre livelli che suddivide il livello di presentazione, il livello di logica operativa e quello di dati persistenti. I livelli possono anche essere più numerosi come avviene nella pila OSI e -ciò può portare a molte richieste per comunicare con livelli non adiacenti;
            • +
          • + A livelli: l'architettura viene suddivisa in più livelli con responsabilità distinte e delle interazioni + definite. + Di particolare utilizzo è quella a tre livelli che suddivide il livello di presentazione, il livello di logica + operativa e quello di dati persistenti. I livelli possono anche essere più numerosi come avviene nella pila OSI + e ciò può portare a molte richieste per comunicare con livelli non adiacenti; +
            • -
          • Produttore-consumatore: consiste nella collaborazione a pipeline con utilizzo di una coda;
            • +
          • Produttore-consumatore: consiste nella collaborazione a pipeline con utilizzo di una coda;
            • -
          • Client-server: architettura strutturata a livelli in due macchine distinte che comunicano tramite un protocollo. -Si può strutturare come fat client la comunicazione con più client porta il server a parlare direttamente con l'applicazione -e poiché il client possiede di per sé una parte della logica; mentre si parla di thin client se la comunicazione è più ad alto livello e -si ha quindi una buona portabilità ma un carico maggiore sul server.
            • +
          • + Client-server: architettura strutturata a livelli in due macchine distinte che comunicano tramite un + protocollo. + Si può strutturare come fat client la comunicazione con più client porta il server a parlare direttamente + con l'applicazione e poiché il client possiede di per sé una parte della logica; mentre si parla di + thin client se la comunicazione è più ad alto livello e si ha quindi una buona portabilità ma un carico + maggiore sul server. +
            • -
          • Peer-to-peer: architettura che prevedere la connessione tra varie macchine che comunicano tra loro senza bisogno di un server intermedio.
            • +
          • + Peer-to-peer: architettura che prevedere la connessione tra varie macchine che comunicano tra loro senza + bisogno di un server intermedio. +
          - + diff --git a/src/cQualProc.html b/src/cQualProc.html index 9a0f42a..3e5e19d 100644 --- a/src/cQualProc.html +++ b/src/cQualProc.html @@ -1,129 +1,191 @@

          Qualità di Processo

          -Il controllo della qualità di processo influenza direttamente la qualità del prodotto realizzato. -È molto importante assicurarsi la qualità di processo al fine di associare i prodotti al processo da cui hanno origine sia per assicurarsi che siano stati sottoposti a cicli di verifica sia per garantirne la riproducibilità. -
          - -
          -La valutazione della qualità deve sempre essere critica, possibilmente proattiva(meglio preventiva) e deve puntare al miglioramento continuo. - -
          -L'identificazione di un processo aiuta a controllarlo e quindi valutarne, tramite strumenti di valutazione, la conformità rispetto alle attese( -efficacia), il contenimento dei costi(efficienza) e l'esperienza condivisa che ne deriva. - + Il controllo della qualità di processo influenza direttamente la qualità del prodotto realizzato. + È molto importante assicurarsi la qualità di processo al fine di associare i prodotti al processo da cui hanno + origine sia per assicurarsi che siano stati sottoposti a cicli di verifica sia per garantirne la riproducibilità. +
          + +
          + La valutazione della qualità deve sempre essere critica, possibilmente proattiva(meglio preventiva) e deve puntare + al miglioramento continuo. + +
          + L'identificazione di un processo aiuta a controllarlo e quindi valutarne, tramite strumenti di valutazione, la + conformità rispetto alle attese( + efficacia), il contenimento dei costi(efficienza) e + l'esperienzacondivisa che ne deriva.

          Le norme ISO 9000

          -Le norme ISO 9000 rappresentano il fondamento per i modelli di qualità ma restano neutre rispetto al dominio di applicazione, -infatti la suddivisione prevista nei processi differisce completamente da quella definita in ISO/IEC 12207. - -Per meglio specificare tali fondamenti nei contesti produttivi è stato definito un Sistema Gestione Qualità(SGQ) in ISO 9001, che si occupa di -calare la visione di ISO 9000 nei sistemi produttivi, introducendo dei requisiti ben specifici. -ISO 9001 è quindi anche una certificazione. + Le norme ISO 9000 rappresentano il fondamento per i modelli di qualità ma restano neutre rispetto al dominio di + applicazione, infatti la suddivisione prevista nei processi differisce completamente da quella definita in ISO/IEC + 12207. + Per meglio specificare tali fondamenti nei contesti produttivi è stato definito un + Sistema Gestione Qualità(SGQ) in + ISO 9001, che si occupa di calare la visione di ISO 9000 nei sistemi produttivi, introducendo dei requisiti ben + specifici. + ISO 9001 è quindi anche una certificazione.

          Sistema Gestione Qualità

          -SGQ si configura come funzione aziendale che riferisce direttamente alla Direzione, garantendo il perseguimento della qualità trasversalmente ai settori aziendali. -
          -Per ricercare la qualità nel processo risulta necessaria la stesura di alcuni documenti che implementino lo standard scelto dalla politica per la qualità aziendale(motivazioni delle scelte principali per la qualità), orizzontalmente ispirandosi all'ISO 9000 per creare una strategia aziendale nel manuale di qualità e verticalmente definendo una strategia progettuale nel piano della qualità.

          + SGQ si configura come funzione aziendale che riferisce direttamente alla Direzione, garantendo il perseguimento + della qualità trasversalmente ai settori aziendali. +
          + Per ricercare la qualità nel processo risulta necessaria la stesura di alcuni documenti che implementino lo standard + scelto dalla politica per la qualità aziendale(motivazioni delle scelte principali per la qualità), orizzontalmente + ispirandosi all'ISO 9000 per creare una strategia aziendale nel manuale di qualità e verticalmente definendo + una strategia progettuale nel piano della qualità.

          -Il manuale della qualità definisce il sistema di -gestione della qualità di un’organizzazione -
          ISO 9000
          + Il manuale della qualità definisce il sistema di gestione della qualità di un’organizzazione +
          ISO 9000

          -Il manuale della qualità si integra con le procedure aziendali, fornendo una visione operativa ad alto livello fissando obiettivi di qualità e strategie attuative, proponendo anche delle modalità per il suo miglioramento. + Il manuale della qualità si integra con le procedure + aziendali, fornendo una visione operativa ad alto livello fissando obiettivi di qualità e strategie attuative, + proponendo anche delle modalità per il suo miglioramento.

          -Il documento che definisce gli elementi del SGQ -e le risorse che devono essere applicate in uno -specifico caso (prodotto, processo, progetto) -
          ISO 9000
          + Il documento che definisce gli elementi del SGQ e le risorse che devono essere applicate in uno specifico caso + (prodotto, processo, progetto) +
          ISO 9000

          -Il piano della qualità fornisce una visione strategica -di taglio operativo concretizzando quanto contenuto nel manuale della qualità per il singolo progetto, tenendo conto dei vincoli di risorse ed eventualmente con valenza contrattuale. -
          -Esso deve valutare la conformità rispetto alle norme di progetto, accertare la tracciabilità di soluzioni e requisiti e assicurare una buona pianificazione. -Per fare ciò vengono sfruttati opportuni strumenti di valutazione. + Il piano della qualità fornisce una visione strategica di taglio operativo concretizzando quanto contenuto nel + manuale della qualità per il singolo progetto, tenendo conto dei vincoli di risorse ed eventualmente con valenza + contrattuale. +
          + Esso deve valutare la conformità rispetto alle norme di progetto, accertare la tracciabilità di soluzioni e + requisiti e assicurare una buona pianificazione. + Per fare ciò vengono sfruttati opportuni strumenti di valutazione.

          Strumenti di valutazione

          SPY - Software Process assessment and Improvment

          -È uno strumento per la valutazione oggettiva della maturità dei processi di un'organizzazione basato sulla ricerca del miglioramento continuo. -
          -Il suo difetto principale è che risulta completamente slegato rispetto ai modelli standard per i processi software. + È uno strumento per la valutazione oggettiva della maturità dei processi di un'organizzazione basato sulla ricerca + del miglioramento continuo. +
          + Il suo difetto principale è che risulta completamente slegato rispetto ai modelli standard per i processi software.

          Capability vs Maturity

          -Due caratteristiche significative per la valutazione di un processo sono capability e maturity. -La capability si occupa di un processo considerato singolarmente determinando l'intorno del risultato atteso e raggiungibile da quel processo in termini di efficienza ed efficacia. -Un alto livello di capability garantisce che il processo venga eseguito da tutti in modo -disciplinato, sistematico e quantificabile. -
          -La maturity coinvolge invece un insieme di processi e misura quanto è governato il sistema dei processi ed è il risultato della combinazione del livello di capability dei singoli processi. -La misura della reattività dei processi di un'organizzazione si chiama governance ed essa ha come fine l'innalzamento del livello di maturity. + Due caratteristiche significative per la valutazione di un processo sono capability e maturity. + La capability si occupa di un processo considerato singolarmente determinando l'intorno del risultato atteso e + raggiungibile da quel processo in termini di efficienza ed efficacia. + Un alto livello di capability garantisce che il processo venga eseguito da tutti in modo disciplinato, sistematico + e quantificabile. +
          + La maturity coinvolge invece un insieme di processi e misura quanto è governato il sistema dei processi ed è il + risultato della combinazione del livello di capability dei singoli processi. + La misura della reattività dei processi di un'organizzazione si chiama governance ed essa ha come fine + l'innalzamento del livello di maturity.

          CMMI - Capability Maturity Model with Integration

          -Il punto focale di questo approccio per il miglioramento dei processi è l'integrazione delle funzioni organizzative, prima divise, al fine di fornire linee guida per la definizione di obiettivi, per le loro priorità e per la valutazione dei processi attuali. -
          -Il CMMI è un modello che indica 22 aree di processi aziendali strutturate su 5 livelli ognuna con obiettivi generici e specifici, implementati da una sequenza temporalmente definita di attività rispettivamente generiche e specifiche. -
          -CMMI integra molteplici modelli CMM sviluppati per settori distinti. -I livelli individuati riguardano la maturità dei processi aziendali. + Il punto focale di questo approccio per il miglioramento dei processi è l'integrazione delle funzioni organizzative, + prima divise, al fine di fornire linee guida per la definizione di obiettivi, per le loro priorità e per la + valutazione dei processi attuali. +
          + Il CMMI è un modello che indica 22 aree di processi aziendali strutturate su 5 livelli ognuna con obiettivi generici + e specifici, implementati da una sequenza temporalmente definita di attività rispettivamente + generiche e specifiche. +
          + CMMI integra molteplici modelli CMM sviluppati per settori distinti. + I livelli individuati riguardano la maturità dei processi aziendali.

            -
          • Initial è il livello in cui i processi sono imprevedibili, poco controllati e poco reattivi;
            • -
          • Managed indica che i processi sono stati istanziati per il progetto e spesso sono già reattivi, viene attuata il "DO" di PDCA.
            • -
          • Defined è il livello in cui i processi sono istanziati per l'intera organizzazione e proattivi, in quanto in questo livello viene applicata il "Plan" per pianificare il miglioramento.
            • -
          • Quantitatively managed indica che i processi vengono regolarmente controllati tramite misurazioni, viene applicato il "Plan & Check" per pianificare il miglioramento, controllarne gli esiti e raffinare la pianificazione.
            • -
          • Optimized è il livello in cui ci si focalizza completamente sul miglioramento dei processi, applicando in toto il PDCA.
            • +
          • Initial è il livello in cui i processi sono imprevedibili, poco controllati e poco reattivi;
            • +
          • + Managed indica che i processi sono stati istanziati per il progetto e spesso sono già reattivi, viene + attuata il "DO" di PDCA. +
            • +
          • + Defined è il livello in cui i processi sono istanziati per l'intera organizzazione e proattivi, in quanto + in questo livello viene applicata il "Plan" per pianificare il miglioramento. +
            • +
          • + Quantitatively managed indica che i processi vengono regolarmente controllati tramite misurazioni, viene + applicato il "Plan & Check" per pianificare il miglioramento, controllarne gli esiti e raffinare la + pianificazione. +
            • +
          • + Optimized è il livello in cui ci si focalizza completamente sul miglioramento dei processi, applicando in + toto il PDCA. +

          SPICE - Software Process Improvement Capability dEtermination

          -SPICE(ISO/IEC 15504) è un modello che esclude la dimensione di maturità, andando a cercare una grana più fine di valutazione nella capability dei processi e come migliorarli. -In particolare SPICE fornisce un framework per la definizione di obiettivi e per facilitarne il raggiungimento. -Le aree di processo trattate sono 5: -rapporto cliente-fornitore, ingegneristica, di supporto, gestione e organizzazione. -
          -SPICE individua nove attributi di processo per misurare la capability, suddividendoli in cinque livelli. + SPICE(ISO/IEC 15504) è un modello che esclude la dimensione di maturità, andando a cercare una grana più fine di + valutazione nella capability dei processi e come migliorarli. + In particolare SPICE fornisce un framework per la definizione di obiettivi e per facilitarne il raggiungimento. + Le aree di processo trattate sono 5: rapporto cliente-fornitore, ingegneristica, di supporto, gestione e + organizzazione. +
          + SPICE individua nove attributi di processo per misurare la capability, suddividendoli in cinque livelli.

            -
          • Incomplete process è il livello in cui non vi è nessun tipo di indicatore, indica che un - processo non è implementato oppure è fallito, cioè non ha prodotto nessun risultato.
            • -
          • Performed process è il livello in cui il processo è stato attuato e adempie all’obiettivo - prefissato.
            • -
          • Managed process in questo livello il processo che già adempie ai suoi obiettivi presenta dei prodotti controllati - e mantenuti, attività pianificate e controllate, documentate nello svolgimento.
            • -
          • Established process in questo livello il processo è ora ad un livello tale da garantire la produzione di prodotti adatti.
            • -
          • Predictable process in questo livello il processo viene eseguito con limiti e obiettivi di produzione definiti.
            • -
          • Optimizing process - il processo è continuamente migliorato per soddisfare gli - obiettivi di business attuali e pianificati.
            • +
          • + Incomplete process è il livello in cui non vi è nessun tipo di indicatore, indica che un processo non è + implementato oppure è fallito, cioè non ha prodotto nessun risultato. +
            • +
          • + Performed process è il livello in cui il processo è stato attuato e adempie all’obiettivo prefissato. +
            • +
          • + Managed process in questo livello il processo che già adempie ai suoi obiettivi presenta dei prodotti + controllati e mantenuti, attività pianificate e controllate, documentate nello svolgimento. +
            • +
          • + Established process in questo livello il processo è ora ad un livello tale da garantire la produzione di + prodotti adatti. +
            • +
          • + Predictable process in questo livello il processo viene eseguito con limiti e obiettivi di produzione + definiti. +
            • +
          • + Optimizing process + il processo è continuamente migliorato per soddisfare gli obiettivi di business attuali e pianificati. +

          -Ad ogni attributo di processo può venire associato -un indicatore di completamento tra quattro possibili scelte: non raggiunto, parzialmente raggiunto, in gran parte raggiunto e completamente raggiunto. - + Ad ogni attributo di processo può venire associato un indicatore di completamento tra quattro possibili scelte: + non raggiunto, parzialmente raggiunto, in gran parte raggiunto e completamente raggiunto.

          - + diff --git a/src/cQualSW.html b/src/cQualSW.html index bf50a8d..55412bc 100644 --- a/src/cQualSW.html +++ b/src/cQualSW.html @@ -1,161 +1,179 @@

          Qualità del Software

          Definizione

          -La qualità è sempre legata al concetto di valutazione e va misurata in modo oggettivo e non retrospettivo, -essa rappresenta un indice importante sia per chi realizza il prodotto che la dovrebbe usare come indice per attuare -miglioramenti, sia per chi utilizza il prodotto come indice di garanzia del suo funzionamento ed infine anche per chi lo -valuta. -
          - -Ci sono delle visioni ambivalenti riguardo la qualità del software -che può essere intrinseca se ricerca la conformità rispetto ai requisiti, relativa se valuta la soddisfazione del cliente o quantitativa se attua misurazioni per mezzo di confronti(metriche). -
          -Secondo ISO la qualità è: + La qualità è sempre legata al concetto di valutazione e va misurata in modo oggettivo e non retrospettivo, + essa rappresenta un indice importante sia per chi realizza il prodotto che la dovrebbe usare come indice per attuare + miglioramenti, sia per chi utilizza il prodotto come indice di garanzia del suo funzionamento ed infine anche per + chi lo valuta. +
          + + Ci sono delle visioni ambivalenti riguardo la qualità del software che può essere intrinseca se ricerca la + conformità rispetto ai requisiti, relativa se valuta la soddisfazione del cliente o quantitativa se + attua misurazioni per mezzo di confronti(metriche). +
          + Secondo ISO la qualità è:

          -L'insieme delle caratteristiche di un'entità che -ne determinano la capacità di soddisfare -esigenze espresse e implicite -
          ISO 8402:1994
          - + L'insieme delle caratteristiche di un'entità che ne determinano la capacità di soddisfare esigenze espresse e + implicite +
          ISO 8402:1994
          +

          Sistema di qualità

          -Per perseguire la qualità viene istituto un sistema di qualità che -si applica nell'ambito della gestione aziendale come ways of working(norme di progetto), -influenzando la pianificazione con la definizione di una politica e degli obiettivi, -il controllo e il miglioramento continuo. -Secondo ISO il sistema di qualità è: + Per perseguire la qualità viene istituto un sistema di qualità che si applica nell'ambito della gestione aziendale + come ways of working(norme di progetto), influenzando la pianificazione con la definizione di una politica + e degli obiettivi, il controllo e il miglioramento continuo. Secondo ISO il sistema di qualità è:

          -La struttura organizzativa, le responsabilità, le -procedure, i procedimenti, e le risorse messe -in atto per il perseguimento della qualità -
          ISO 8402:1994 → ISO 9000:2005
          + La struttura organizzativa, le responsabilità, le + procedure, i procedimenti, e le risorse messe in atto per il perseguimento della qualità +
          ISO 8402:1994 → ISO 9000:2005

          -Il primo passo nella creazione di un sistema di qualità è la definizione della pianificazione di qualità. -Il piano di qualità ottenuto fissa a livello orizzontale delle politiche aziendali, -e verticalmente determina gli obiettivi di qualità del singolo progetto, -tramite l'uso di opportuni strumenti e modalità di controllo. -Secondo ISO la pianificazione di qualità è: + Il primo passo nella creazione di un sistema di qualità è la definizione della pianificazione di qualità. + Il piano di qualità ottenuto fissa a livello orizzontale delle politiche aziendali, e verticalmente determina + gli obiettivi di qualità del singolo progetto, tramite l'uso di opportuni strumenti e modalità di controllo. + Secondo ISO la pianificazione di qualità è:

          -Il controllo di qualità è l'insieme delle attività del sistema mirate a -fissare gli obiettivi di qualità, i processi e le -risorse necessarie per conseguirli -
          ISO 9000
          + Il controllo di qualità è l'insieme delle attività del + sistema mirate a fissare gli obiettivi di qualità, i processi e le risorse necessarie per conseguirli +
          ISO 9000

          -Dato un piano di qualità si possono definire le attività atte al controllo di qualità, -che può essere retrospettivo, poco utile, oppure preventivo tramite quality assurance. -Il controllo preventivo si attua tramite comprensione e analisi di dominio, verifiche di attività e processi, validazione dei prodotti. -
          -Serve a raccogliere tempestivamente evidenza oggettiva e di -qualità. + Dato un piano di qualità si possono definire le attività atte al controllo di qualità, che può essere + retrospettivo, poco utile, oppure preventivo tramite quality assurance. + Il controllo preventivo si attua tramite comprensione e analisi di dominio, verifiche di attività e processi, + validazione dei prodotti. +
          + Serve a raccogliere tempestivamente evidenza oggettiva e di qualità.

          -Le attività del sistema qualità pianificate e -attuate al fine che il prodotto soddisfi i -requisiti attesi -
          ISO 9000
          + Le attività del sistema qualità pianificate e attuate al fine che il prodotto soddisfi i requisiti attesi +
          ISO 9000

          Modelli della qualità

          -Uno standard di qualità è una raccolta organica di best practice al fine di evitare ripetizione di errori passati, -su cui viene basata l'ideazione di processi di quality assurance. -
          -L'organizzazione aziendale traspare anche dal modo in cui essa attua gli standard, che possono essere visti -come un elemento di continuità. -D'altra parte eccessivi vincoli derivanti dagli standard possono essere recepiti come bloccanti, soprattutto se attuati manualmente senza strumenti informatici adeguati, infatti se gli standard non hanno controlli di -efficacia - sfociano in eccessi di burocrazia. -
          -Alcuni standard forniscono dei modelli di qualità che definiscono delle caratteristiche rilevanti per il prodotto -e le organizzano secondo una struttura logica, -su cui definire metriche per la valutazione. - -Essi si occupano anche di uniformare la valutazione e la percezione della qualità rispetto alle attese dell'utente, alle necessità della produzione e ai vincoli della direzione. -
          -I modelli più rilevanti sono quello di Boehm e quello definito da ISO IEC 9126:2001. + Uno standard di qualità è una raccolta organica di best + practice al fine di evitare ripetizione di errori passati, su cui viene basata l'ideazione di processi di + quality assurance. +
          + L'organizzazione aziendale traspare anche dal modo in cui essa attua gli standard, che possono essere visti come un + elemento di continuità. + D'altra parte eccessivi vincoli derivanti dagli standard possono essere recepiti come bloccanti, soprattutto se + attuati manualmente senza strumenti informatici adeguati, infatti se gli standard non hanno controlli di + efficacia sfociano in eccessi di burocrazia. +
          + Alcuni standard forniscono dei modelli di qualità che definiscono delle caratteristiche rilevanti per il prodotto + e le organizzano secondo una struttura logica, su cui definire metriche per la valutazione. + + Essi si occupano anche di uniformare la valutazione e la percezione della qualità rispetto alle attese dell'utente, + alle necessità della produzione e ai vincoli della direzione. +
          + I modelli più rilevanti sono quello di Boehm e quello definito da ISO IEC 9126:2001.

          ISO 25000:2005

          -Questo standard ingloba gli standard 9126 e 14598 in un unico standard chiamato SQuaRE: -Software product Quality Requirements and Evaluation, -che parte dalla persecuzione della qualità dei requisiti per definire un modello di qualità -su cui avere una gestione di qualità con misurazioni della qualità che portano ad una corretta valutazione della qualità. - + Questo standard ingloba gli standard 9126 e 14598 in un unico standard chiamato SQuaRE: Software product Quality + Requirements and Evaluation, che parte dalla persecuzione della qualità dei requisiti per definire un modello di + qualità su cui avere una gestione di qualità con misurazioni della qualità che portano ad una corretta valutazione + della qualità.

          ISO IEC 9126

          -Lo standard ISO 9126 fornisce un modello basato su sette caratteristiche per la valutazione della qualità, suddivise -in totale in 31 sotto-caratteristiche. -Esso si basa su tre tipi di visioni: quella esterna che rappresenta il comportamento del software durante la sua esecuzione, -ed è rilevata dai test su obiettivi stabiliti in un contesto tecnico rilevante; quella interna che rappresenta la qualità del codice sorgente e della documentazoine correlata, le caratteristiche di questa influiscono anche sulle altre due visioni; infine quella in uso che rappresenta il punto di vista dell'utente finale sul prodotto software e necessita del raggiungimento preventivo di una buona qualità interna ed esterna. + Lo standard ISO 9126 fornisce un modello basato su sette caratteristiche per la valutazione della qualità, suddivise + in totale in 31 sotto-caratteristiche. + Esso si basa su tre tipi di visioni: quella esterna che rappresenta il comportamento del software durante la + sua esecuzione, + ed è rilevata dai test su obiettivi stabiliti in un contesto tecnico rilevante; quella interna che + rappresenta la qualità del codice sorgente e della documentazione correlata, le caratteristiche di questa + influiscono anche sulle altre due visioni; infine quella in uso che rappresenta il punto di vista dell'utente + finale sul prodotto software e necessita del raggiungimento preventivo di una buona qualità interna ed esterna.

          -È importante notare che qualità esterna è solo la punta dell'iceberg rispetto alla qualità interna che comprende tutte le scelte di progettazione, codifica e verifica. -
          -Le caratteristiche associate alla qualità interna ed esterna sono: + È importante notare che qualità esterna è solo la punta dell'iceberg rispetto alla qualità interna che comprende + tutte le scelte di progettazione, codifica e verifica. +
          + Le caratteristiche associate alla qualità interna ed esterna sono:

            -
          • Funzionalità: la capacità del prodotto software di fornire funzioni che soddisfino -le esigenze stabilite; -
            • -
          • Affidabilità: la capacità del prodotto software di mantenere un certo livello di -prestazioni; -
            • - -
          • Efficienza: la capacità del prodotto software di fornire adeguate prestazioni in -relazione alle risorse utilizzate; -
            • - -
          • Usabilità: la capacità del prodotto software di essere compreso e apprezzato -dall’utente; -
            • - -
          • Manutenibilità: la capacità del prodotto software di essere modificato, migliorato -o corretto facilmente nel tempo; -
            • - -
          • Portabilità: la capacità del prodotto software di essere trasportato da un ambiente -di lavoro ad un altro.
            • +
          • + Funzionalità: la capacità del prodotto software di fornire funzioni che soddisfino le esigenze stabilite; +
            • +
          • Affidabilità: la capacità del prodotto software di mantenere un certo livello di prestazioni;
            • + +
          • + Efficienza: la capacità del prodotto software di fornire adeguate prestazioni in + relazione alle risorse utilizzate; +
            • + +
          • + Usabilità: la capacità del prodotto software di essere compreso e apprezzato + dall’utente; +
            • + +
          • + Manutenibilità: la capacità del prodotto + software di essere modificato, migliorato o corretto facilmente nel tempo; +
            • + +
          • + Portabilità: la capacità del prodotto software di essere trasportato da un ambiente di lavoro ad un altro. +

          -Infine l'ultima caratteristica riguarda la qualità in uso che è relativa alla percezione dell'utente finale sul prodotto e su quanto questo lo aiuti nelle sue esigenze senza risvolti spiacevoli in corso di utilizzo. - + Infine l'ultima caratteristica riguarda la qualità in uso che è relativa alla percezione dell'utente finale + sul prodotto e su quanto questo lo aiuti nelle sue esigenze senza risvolti spiacevoli in corso di utilizzo.

          - +

          ISO IEC 14598

          -Lo standard ISO 14598 fornisce linee guida per l'associazione di una misurazione quantitativa(metrica) ad una data sotto-caratteristica individuata nello standard ISO 9126. -Una metrica è una misurazione correlata ad un sistema software, a un processo o alla documentazione che permetta la quantificazione e può essere utilizzata per predirre e controllare l'andamento. -
          -L'assunzione su cui si basa è che le proprietà e gli attributi del software possono essere misurati e che -esista un'effettiva relazione tra ciò che misuriamo e ciò che vogliamo conoscere, nonostante solamente gli attributi interni siano misurabili ma spesso quelli esterni siano di maggiore interesse. -Individuare tale relazione in modo formale e valido può essere particolarmente difficoltoso. + Lo standard ISO 14598 fornisce linee guida per l'associazione di una misurazione quantitativa(metrica) ad una data + sotto-caratteristica individuata nello standard ISO 9126. + Una metrica è una misurazione correlata ad un sistema software, a un processo o alla documentazione che permetta la + quantificazione e può essere utilizzata per predirre e controllare l'andamento. +
          + L'assunzione su cui si basa è che le proprietà e gli attributi del software possono essere misurati e che esista + un'effettiva relazione tra ciò che misuriamo e ciò che vogliamo conoscere, nonostante solamente gli attributi + interni siano misurabili ma spesso quelli esterni siano di maggiore interesse. + Individuare tale relazione in modo formale e valido può essere particolarmente difficoltoso.

          -Se ISO/IEC 9126 definisce un modello della qualità del software, lo standard -14598 descrive il processo di valutazione della qualità del software. -
          Giorgio Giuffrè
          + Se ISO/IEC 9126 definisce un modello della qualità del software, lo standard 14598 descrive il processo di + valutazione della qualità del software. +
          Giorgio Giuffrè


          - + diff --git a/src/glossary.json b/src/glossary.json index 4cf7b97..bf77626 100644 --- a/src/glossary.json +++ b/src/glossary.json @@ -6,7 +6,7 @@ }, { "word":"Efficacia", - "definition":"Grado di conformità del prodotto rispetto alle norme vigenti e agli obiettivi prefissati. Per perseguire una buona efficacia è necessario impiegare sufficienti risorse. La strategia con la quale il fornitore garantisce la conformità viene fissato nel Piano di Qualifica." + "definition":"Grado di conformità del prodotto rispetto alle norme vigenti e agli obiettivi prefissati. Per perseguire una buona efficacia è necessario impiegare sufficienti risorse. La strategia con la quale il fornitore garantisce la conformità viene fissata nel Piano di Qualifica." }, { "word":"Efficienza", @@ -34,7 +34,7 @@ }, { "word":"Integrazione continua", - "definition":"È una pratica che consiste nell'allineare frequentemente lo stato dell'ambiente di lavoro condiviso, controllando che le modifiche apportate non vadano ad intaccare la baseline tramite la definizione di test automatici eseguiti ad ogni commit(Jenkins)." + "definition":"È una pratica che consiste nell'allineare frequentemente lo stato dell'ambiente di lavoro condiviso, controllando che le modifiche apportate non vadano ad intaccare la baseline tramite la definizione di test automatici eseguiti ad ogni commit (Jenkins)." }, { "word":"Milestone", @@ -66,7 +66,7 @@ }, { "word":"Unità", - "definition":"È un insieme di uno o più moduli(componenti elementari) individuati nella definizione di un'architettura software come più piccola parte su cui effettuare test. Un'unità si occupa di soddisfare uno o più requisiti(meglio pochi)." + "definition":"È un insieme di uno o più moduli (componenti elementari) individuati nella definizione di un'architettura software come più piccola parte su cui effettuare test. Un'unità si occupa di soddisfare uno o più requisiti(meglio pochi)." }, { "word":"Versionamento", @@ -82,7 +82,7 @@ }, { "word":"Riuso", - "definition":"Assemblaggio di parti già presistenti, buone e verificate(secondo una best practice). Il riuso può essere occasionale se un semplice copia e incolla di scarso impatto ma è a basso costo, oppure sistematico se si progetta il software in modo tale che le sue componenti siano adattabili, questo comporta un costo iniziale maggiore ma ha maggiore impatto. Progettare per riuso è difficile perché richiede molta lungimiranza e non sempre è immediato identificare situazioni in cui riusare componenti." + "definition":"Assemblaggio di parti già presistenti, buone e verificate (secondo una best practice). Il riuso può essere occasionale se un semplice copia e incolla di scarso impatto ma è a basso costo, oppure sistematico se si progetta il software in modo tale che le sue componenti siano adattabili, questo comporta un costo iniziale maggiore ma ha maggiore impatto. Progettare per riuso è difficile perché richiede molta lungimiranza e non sempre è immediato identificare situazioni in cui riusare componenti." }, { "word":"Best Practice",