- Historia
- luominen
- Vaihtoehto vesiputoukselle
- Spiraalimallin ominaisuudet
- Riskienhallinta
- Kierteen kuvaus
- yleinen
- Joustava
- metamodel
- Tasot
- Määritä tavoitteet, vaihtoehdot ja rajoitukset
- Riskien arviointi
- Kehittäminen ja testaus
- Seuraavan jakson suunnittelu
- esimerkki
- Etu
- Syklinen rakenne
- Riskienhallinta
- Asiakkaiden osallistuminen ja palaute
- Ihanteellinen suuriin projekteihin
- haitat
- Kallis
- Melko monimutkainen
- Ajanhallinta
- Monta vaihetta
- Viitteet
Kierre malli on arkkityypin sovelluksen kehitysprosessissa. Se perustuu hypoteesiin, jonka mukaan ohjelmistokehitys on iteratiivinen jakso, joka toistetaan, kunnes asetetut tavoitteet saavutetaan. Sillä on kyky käsitellä suuri joukko riskejä, joita voi syntyä minkä tahansa ohjelmiston kehittämisessä.
Se on yksi tärkeimmistä malleista riskienhallinnan tukemiseksi. Kuten nimensä päättelee, tämä malli esitetään spiraalimaisena, jossa mallin eri vaiheet jakautuvat eri sykleihin. Syklien lukumäärää mallissa ei ole kiinteä ja se voi vaihdella projektikohtaisesti.

Analyysi, arviointi, suunnittelu ja kehittäminen. Ohjelmistokehityksen spiraalilähde: Beao commons.wikimedia.org
Historia
luominen
Kierremalli määritteli amerikkalainen matemaatikko ja ohjelmistotekniikan professori Barry Boehm. Esitettyään vuonna 1986 konseptinsa monimutkaisten sovellusten kehittämiseksi, hän julkaisi mallinsa vuonna 1988 kattavammassa muodossa artikkelissaan "Spiraalimalli ohjelmistojen kehittämiseen ja parantamiseen".
Osa tämän vuoden 1988 julkaisusta kuvaa graafisesti spiraalimallia, osoittaen kokonaisvaltaisesti, miltä ohjelmistokehitysprosessi näyttää spiraalimaisesti ja jota syklit tukevat.
Boehm tunnetaan lukuisista panoksistaan ohjelmistosuunnitteluun, kuten rakentava kustannusmalli (COCOMO), ohjelmistoprosessin spiraalimalli, G-teoria (win-win) -lähestymistapa vaatimusten määrittämiselle ja hallinnalle. ohjelmistosta.
Vaihtoehto vesiputoukselle
Boehm kuvasi julkaisussaan spiraalimallia mahdollisena vaihtoehtona aikaisemmin vakiintuneelle vesiputomallille, joka myös toimi hänen harjoituksensa pohjana.
Kierremalli ei ollut ensimmäinen, jossa keskusteltiin syklisestä kehityksestä, mutta se oli ensimmäinen malli, joka selitti, miksi iterointi on tärkeää. Alun perin suunnitelman mukaan se on suunnattu suurille, monimutkaisille hankkeille, joiden iteraatiot ovat tyypillisesti 6 kuukaudesta 2 vuoteen.
Tämä malli ei oleta, että ohjelmistokehitystehtävät suunnitellaan lineaarisesti, toisin kuin vesiputousmalli, vaan näkee ne pikemminkin iteratiivisina tehtävinä.
Tämä suhdannemalli vaikutti malliperusteiseen ohjelmistosuunnitteluarkkitehtuuriin (MBASE) ja äärimmäiseen ohjelmointiin.
Spiraalimallin ominaisuudet
Riskienhallinta
Mikä erottaa tämän mallin huomattavasti muista ohjelmistoprosessimalleista, on se, että siinä tunnistetaan selkeästi riskit. Siten se vähentää huomattavasti suurten ohjelmistoprojektien epäonnistumista arvioimalla toistuvasti riskejä ja todentamalla kehitteillä oleva tuote joka kerta.
Tämä tietokonemalli sisältää komponentteja melkein jokaisesta muusta ohjelmiston elinkaaren mallista, kuten vesiputousmallista, prototyyppimallista, iteratiivisesta mallista, evoluutiomallista jne.
Tämän vuoksi se pystyy käsittelemään melkein kaikenlaisia riskejä, joita muut mallit eivät yleensä käsittele. Koska malleja on niin paljon, tämä malli on kuitenkin paljon monimutkaisempi kuin muut ohjelmistokehitysmallit.
Kierteen kuvaus
Jokainen kierre kierros edustaa kokonaista sykliä, jonka läpi neljä neljännestä aina kulkee, edustaen mallin neljää vaihetta.
Kun spiraalin koko kasvaa, tapahtuu myös edistystä. Siksi vaiheita ei suoriteta vain kerran, vaan useita kertoja, spiraalimaisesti.
Vaikka tämä suhdannetoisto saa projektin lähestymään hitaasti asetettuja tavoitteita, kehitysprosessin epäonnistumisen riski minimoidaan voimakkaasti.
yleinen
Nämä neljä vaihetta toteuttavat vain syklin perustavoitteet, mutta niiden ei tarvitse olla ilmenevä kussakin jaksossa.
Kunkin jakson järjestystä ei myöskään määritetä tiukasti. Siksi malli voidaan yhdistää milloin tahansa muihin malleihin.
Joustava
Se on melko joustava, koska se suorittaa tavoitteiden määrittely-, riskianalyysi-, kehitys- ja suunnitteluprosessit erikseen jokaisessa projektin vaiheessa.
metamodel
Sitä pidetään metamallissa, koska se sisältää muut mallit. Esimerkiksi, jos spiraali olisi yksi jakso, se edustaisi vesiputousmallia, koska se sisältää tämän klassisen mallin asteittaisen lähestymistavan.
Hän käyttää myös prototyyppimallin lähestymistapaa, koska jokaisen syklin alussa hän kokoaa prototyypin riskien hallitsemiseksi.
Lisäksi se on yhteensopiva evoluutiomallin kanssa, koska spiraalin iteraatioita voidaan pitää evoluutiotasoina, joiden kautta lopullinen järjestelmä rakennetaan.
Tasot
Määritä tavoitteet, vaihtoehdot ja rajoitukset
Järjestelmävaatimukset on määritelty niin yksityiskohtaisesti kuin mahdollista, mukaan lukien suorituskyky, laitteisto- / ohjelmistorajapinnat, avaimen indikaattorit jne. ja mitkä tavoitteet tulisi liittää nykyiseen kehityssykliin, otetaan huomioon.
Lisäksi tutkitaan erilaisia vaihtoehtoja sen toteuttamiselle, kuten rakentaa vs. ostaa, käyttää uudelleen olemassa olevia komponentteja tai ulkoistaa jne.
Samoin määritetään rajoitukset, kuten kustannukset, aikataulu ja rajapinnat, ajan kulutus jne.
Riskien arviointi
Kaikkia ehdotettuja vaihtoehtoja arvioidaan. Tavoitteet ja rajoitukset toimivat määrittelevinä referensseinä parhaan ratkaisun valitsemiseksi.
Lisäksi tunnistetaan riskit, jotka voivat haitata projektin onnistumista, kuten kokemuksen puute, uusi tekniikka, tiukka aikataulu, puutteelliset prosessit jne., Toteuttamalla kannattavimmat strategiat pienimmällä riskillä.
Lopuksi käytetään menetelmiä, kuten prototyyppien määritystä, simulaatioita, analyyttisiä malleja ja käyttäjäkyselyjä.
Kehittäminen ja testaus
Kaikki tarvittava kehittäminen suoritetaan tekniikkaa ja valittua ratkaisua käyttämällä. Jokaisella iteraatiolla luodaan parempi versio sovelluksesta.
Varsinainen koodi kirjoitetaan ja testataan useita kertoja, kunnes haluttu tulos on saavutettu, mikä toimii sitten perustana tuleville kehitysvaiheille.
Seuraavan jakson suunnittelu
Yhden jakson päätyttyä alkaa suunnitella seuraavaa. Suunnittelu voisi olla jatkoa hankkeelle normaalisti, jos syklin tavoite saavutettaisiin, seuraavan tavoitteen määritelmän perusteella.
Voisi olla myös muiden ratkaisujen löytämistä, jos edellinen kehitysvaihe osoittautui vialliseksi. Nykyinen strategia voitaisiin korvata yhdellä aiemmin määritellyistä vaihtoehdoista tai uudella. Tällä aloitettaisiin uusi yritys saavuttaa annettu tavoite.
esimerkki
Yhdysvaltain armeija hyväksyi spiraalimallin tulevaisuuden taistelujärjestelmien (SCF) nykyaikaistamisohjelman kehittämiseen ja päivittämiseen.
Virallisesti vuonna 2003 käynnistetyt SCF: t suunniteltiin varustamaan joukot ajoneuvoilla, jotka oli kytketty reaaliajassa poikkeuksellisen nopeaan ja joustavaan taistelukenttien verkkoon.
Hanke jaettiin neljään kehitysspiraaliin, joiden molemmat olivat noin kaksi vuotta. Spiral 1: n oli määrä alkaa vuonna 2008 ja se toimittaa prototyyppejä käyttöä ja arviointia varten.
Kierre 1: n valmistumisen jälkeen spiraalin 2 oli määrä alkaa vuonna 2010. Lopputuotteen kehitys oli tarkoitus toimittaa vuonna 2015.
Boeing ilmoitti elokuussa 2005 hankkeen ensimmäisen merkittävän virstanpylvään, joka oli järjestelmien toiminnallinen peruskorjaus, loppuun saattamisesta. Boeing ja Science Applications International Corporation olivat hankkeen johtajia.
Lokakuussa 2005 Pentagon suositteli kuitenkin hankkeen lykkäämistä Irakin sodan aiheuttamien suurten kustannusvaikutusten ja hirmumyrsky Katrinan avun vuoksi.
Hanke peruutettiin vuonna 2009 budjettileikkausten syntymisen jälkeen, ilman että se pystyisi todistamaan spiraalimallin etuja tässä tehtävässä
Etu
Syklinen rakenne
Tämän tyyppisestä rakenteesta johtuen ohjelmiston suunnittelun ja teknisten vaatimusten väliset ongelmat poistetaan hiljaisesti määräaikaistarkastusten ansiosta.
Riskienhallinta
Riskit analysoidaan jokaisessa tuotteen vaiheessa ennen jatkamista. Tämä auttaa voittamaan tai lieventämään mahdollisia riskejä.
Kaikille työntekijöille on hyötyä riskianalyysin suuresta merkityksestä tässä mallissa, mikä mahdollisesti edustaa heidän suurinta etuaan muihin prosessimalleihin nähden.
Säännöllinen riskinarviointi on arvokasta käytettäessä uusia teknisiä ympäristöjä, joihin yleensä liittyy tietty riskipotentiaali empiiristen arvojen puuttuessa.
Asiakkaiden osallistuminen ja palaute
Asiakkaat ovat mukana projektin jokaisessa vaiheessa, kunnes projekti on valmis. Siksi voidaan hankkia erilaisia palautteita projektin seuraavan version parantamiseksi.
Myös palautetta voidaan saada milloin tahansa spiraalinmuotoisen etenemisen takia. Siten asiakkaat ja käyttäjät voidaan integroida alusta alkaen kehitysprosessiin.
Ihanteellinen suuriin projekteihin
Se on erityisen suosittu ja näkyvä suurissa ja monimutkaisissa hankkeissa, joissa budjetin hallinta on etusijalla asiakkaille ja kehittäjille. Sinulla on suurin mahdollinen hallinto ohjelmistoprojektin kustannuksiin, resursseihin ja laatuun.
haitat
Kallis
Se voi olla melko kallis, koska se vaatii korkeatasoista asiantuntemusta riskianalyyseihin. Lisäksi hankkeiden kehittäminen vie paljon aikaa, mikä voi lisätä yleiskustannuksia.
Melko monimutkainen
Vaatii erittäin aktiivinen ja monimutkainen hankkeen ennakkojohtaminen, jossa kutakin sykliä valvotaan jatkuvasti ja huolellisesti ja dokumentoidaan.
Se on suhteellisen monimutkainen kuin muut mallit, koska on monia jaksoja, joista jokainen käy läpi eri vaiheet, mikä lisää dokumentointiprosessin vaivaa.
Tiedot riskianalyysistä ja hallinnasta, jota usein ei ole saatavana, on välttämätöntä.
Ajanhallinta
Aikaa on vaikea hallita, koska syklien lukumäärää ei tunneta. Lisäksi kehitysprosessi voi viivästyä milloin tahansa, jos tärkeät päätökset on tehtävä yhden syklin sisällä tai lisätoimenpiteillä seuraavaa jaksoa suunniteltaessa.
Monta vaihetta
Monien vaiheiden suorittaminen ohjelmistokehityksessä ei ole aina suotuisaa, koska testauksen monipuolisuudesta huolimatta ohjelman keskeneräiset osat voivat päästä valmiiseen järjestelmään.
Seurauksena on aina vaara, että käsitteellinen virhe tai epäjohdonmukaisuus vaikuttaa lopputuotteeseen.
Viitteet
- Victor Font Jr (2019). Kierremalli. SDLC: n lopullinen opas. Ostettu: ultimatesdlc.com.
- Ionos (2019). Spiraalimalli: riskiohjattu ohjelmistokehitysprosessimalli. Ostettu: ionos.com.
- Techuz (2018). Mikä on spiraalimalli? Yksinkertainen selitys spiraaliohjelmistokehityksen elinkaaresta (SDLC). Ostettu: techuz.com.
- Yhden luukun testaus (2020). Kierremalli. Otettu: onestoptesting.com.
- Geeks Geeksille (2020). Ohjelmistosuunnittelu - spiraalimalli. Ostettu: geeksforgeeks.org.
- Chandu (2019). Spiraalimalli ohjelmistosuunnittelussa. Otettu: medium.com.
